UMA telecon 2021-09-09

Owned by Alec Laws
Last updated: Sep 09, 2021
3 min read

UMA telecon 2021-09-09

Date and Time

Agenda

Minutes

Roll call

Quorum was reached.

Approve minutes

Eve moves to accept the minutes. Sal second. Motion Passes


Relationship Manager - last user stories 


fhirserver.com/fhir-api → registeres resource, scopes = ( patient/Observation.*, patient/MedicationRequest.read, ... )

fhirserver.com/fhir-api/Observation, scopes ( read, write )

fhirserver.com/fhir-api/Observation/<specific observation id> , scopes (read, write)

Can we raise some non-FHIR examples of complicated APIs?


RS requests a permission ticket with all the specific registered resource ids @ the AS. 


  1. As a Client, I want to be able to declare types I understand, in order to successfully use complex APIs or reduce the granted access 
    1. A lot of the APIs discussed are single/groups of documents eg a photo or directory of. 
    2. Identos registers clients with associated API types, so that that client isn't granted access to APIs that it won't be able to use
    3. in FHIR there are many resource types (eg Encounter, Patient, Observation, MedicationRequest), 
      1. let's say a RS registers all resource separately 
      2. When a RS sees a Encounter URL, it creates a ticket with the encounter and all the related resources  (in this case it's asking for more than the single Encounter)
      3. However the client can't handle all the different object types, eg is can understand Observations but not Medications
    4. Today UMA doesn't do a lot of policy based on the client, it's usually discussed as based on RO policy towards the RqP
    5. The AS however CAN use any context about the RqP or Client when making it's access decision
    6. In the RM draft... 


  1. As an RS, I want to defer permission ticket creation, in order to a) not have to understand the Client b) not make authZ decisions (tell me don’t make me think)
    1. Today the client must go to the RS first with a specific resource url to be issued a permission ticket
    2. Instead the client could 'create it's own ticket' using the AS permission ticket API, except instead of using specific resource ids, it can use AS publicized resource id or resource types
    3. AS first flow, where the client discovers the specific RS that RqP is granted to
      1. Alice registers her Observation with the AS, and granted Bob access to it. Claire registered her Observation with with AS, and granted Bob access to it
      2. a RqP using a client that can show Observations
      3. the RqP tells the client "the observations I want to see are protected at this AS"
      4. the client creates it's own permission ticket at that AS for an Observation resource
      5. The AS takes the RqP through interactive claims gathering to determine i) what Observations are available to Bob and ii) which Observations Bob wants the client to see
      6. The AS tells the Client the URLs to the granted Observations 
    4. OIDC + distributed claims could achieve this
    5. both the client and RqP don't know the 
    6. The RS cares that RO is okay that the Client/RqP can access the resources
  2. As an ASO, I want to pre-register Clients, in order to assess their appropriateness, capability and complete non-technical activities
  3. As a Client, I want to pre-register with ASs, in order to a) test my UX and technical integrations b) declare my capabilities

Minimal Interop Profile  - Next Steps


Start formalizing the test cases, something like https://trustedcomputinggroup.org/wp-content/uploads/TCG_Storage_Opal_Family_Test_Cases_v1_00_r1_00_pub.pdf 

Will start a confluence page to start moving the minuted cases to

Then would be in a good place to start the build here. Previously we had looked for some funding to get a developer to create the test suites


Attendees

As of October 26, 2020, quorum is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)

Voting:

  1. Steve
  2. Eve
  3. Alec
  4. Sal
  5. Thomas

Non-voting participants:

  • Scott

Regrets: