UMA telecon 2021-09-09
UMA telecon 2021-09-09
Date and Time
Alternate-week Thursdays 10:00am PT
Screenshare and dial-in: https://global.gotomeeting.com/join/485071053
United States: +1 (224) 501-3316, Access Code: 485-071-053
See UMA calendar for additional details: http://kantara.atlassian.net/wiki/display/uma/Calendar
Agenda
Approve minutes of UMA telecon 2021-06-10, UMA telecon 2021-06-17, UMA telecon 2021-06-24, UMA telecon 2021-07-01, UMA telecon 2021-07-08, UMA telecon 2021-07-15, UMA telecon 2021-07-22, UMA telecon 2021-07-29, UMA telecon 2021-08-05, UMA telecon 2021-08-12, UMA telecon 2021-08-19, UMA telecon 2021-08-26, UMA telecon 2021-09-02
Relationship Manager - user stories / Discovery
Minimal Interop Profile - Next Steps
AOB
Minutes
Roll call
Quorum was reached.
Approve minutes
Approve minutes of UMA telecon 2021-06-10, UMA telecon 2021-06-17, UMA telecon 2021-06-24, UMA telecon 2021-07-01, UMA telecon 2021-07-08, UMA telecon 2021-07-15, UMA telecon 2021-07-22, UMA telecon 2021-07-29, UMA telecon 2021-08-05, UMA telecon 2021-08-12, UMA telecon 2021-08-19, UMA telecon 2021-08-26, UMA telecon 2021-09-02
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)
fhirserver.com/random-registered-uuid →
fhirserver.com/fhir-api/encounter/my-specific-encoutner
fhirserver.com/fhir-api/observation/my-specific-obsercation1,
fhirserver.com/fhir-api/observation/my-specific-obsercation2,
fhirserver.com/fhir-api/patient/patient-id
Can we raise some non-FHIR examples of complicated APIs?
RS requests a permission ticket with all the specific registered resource ids @ the AS.
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
A lot of the APIs discussed are single/groups of documents eg a photo or directory of.
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
in FHIR there are many resource types (eg Encounter, Patient, Observation, MedicationRequest),
let's say a RS registers all resource separately
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)
However the client can't handle all the different object types, eg is can understand Observations but not Medications
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
The AS however CAN use any context about the RqP or Client when making it's access decision
In the RM draft...
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)
Today the client must go to the RS first with a specific resource url to be issued a permission ticket
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
AS first flow, where the client discovers the specific RS that RqP is granted to
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
a RqP using a client that can show Observations
the RqP tells the client "the observations I want to see are protected at this AS"
the client creates it's own permission ticket at that AS for an Observation resource
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
The AS tells the Client the URLs to the granted Observations
OIDC + distributed claims could achieve this
both the client and RqP don't know the
The RS cares that RO is okay that the Client/RqP can access the resources
As an ASO, I want to pre-register Clients, in order to assess their appropriateness, capability and complete non-technical activities
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:
Steve
Eve
Alec
Sal
Thomas
Non-voting participants:
Scott
Regrets: