September 2021 - WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2021-09-30
by Alec Laws 29 Sep '21

29 Sep '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-30 UMA telecon 2021-09-30Date and Time - *Primary-week Thursdays 06:30am PT; Secondary-week Thursdays 10:00am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2021-09-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09> , UMA telecon 2021-09-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16> , UMA telecon 2021-09-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-23> - Document Development - Delegation and Guardianship - AOB Happy to discuss any other candidate topics! Best, - Alec

1 0

Draft minutes of UMA telecon 2021-09-16
by Alec Laws 28 Sep '21

28 Sep '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16 MinutesRoll call Quorum was NOT reached. Approve minutes - Approve minutes of UMA telecon 2021-09-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09> Deferred Correlated Authorization https://github.com/uma-email/poc Today in UMA can push the token, addition is binding the ticket to the pushed token There's nothing bad about this claim token profile, not sure what the specific use-case or outcome it tries to create What is the motivation for needing the correlation? Is there a specific outcome the correlation creates over 'ticket challenge-less' claims pushing? - not allowing RpQ token reuse. Is this beneficial? is it tied to the first use of that token and require re-issuance if the AS needs_info - non-interactive RqP id assertion OAuth vs UMA content Since this a common information request, could we create some good standard content/position? EIC Points: OAuth - Tokens issued to a Resource Owner at a Client - Communication between Resource Server and Authorization Server is out of scope - this necessarily 'narrows' the ecosystem, since the RS and AS need to agree ahead of time on authorization details - usually RS/AS are in the same domain (eg TLD)* Is this something that OAuth says or is it what people naturally implement?* There are OAuth extensions that drive to UMA-like outcomes, such as Token Exchange <https://www.rfc-editor.org/rfc/rfc8693.html> which allows a Client to get a token representing another party. Or GNAP which takes a bunch of UMA + OAuth features and derives a new authorization protocol. Typically considered as 1 RS and 1 AS, with many RPs/clients UMA - Tokens issued to a Requesting Party at a Client - Defines API between RS and AS for: resource registration, permission ticket creation and introspection - There can be "many of everything" not just Clients ← this is a "hard" concept for people to grasp at times People ofter struggle with the 'nicknamed tokens', understanding they are access token which specific scopes/purposes. PCT has often been a hard one to understand, not widely implemented today because of this? UMA Outcomes: - RO to RqP delegation, - decouple consent(policy settings, consent as pre-condition for any tokens/grants) from transaction(token issuance), can happen ahead of time or just in time - AS Discovery and RO selected AS, - Request and grant for specific fine-grained resources, doesn't look at an entire RS as the resource but allows arbitrarily small resource registration UMA is very flexible and comprehensive, which creates it's own set of interoperability challenges. Requires interop/ecosystem profiles which immediately undercut the UMA goal of wide-ecosystem. - Even client registration at the AS is challenging. UMA implies that it's dynamic since 'any client can be used', however this isn't in wide practice today (most clients today are pre-registered) - culmination of different barriers (technical, common practice, understanding) that make UMA difficult to use in practice Trust Registry helps with decentralization and creating a more informed AS. More granularity around the purpose, state for authorization and checking for changes (new role for PCT?) Captures, AS endpoint, purpose, scope of permissions. There will be many of them, ideally not too many for each RS. How do they interact? Regional/local collaboration, and then combining regional networks with congruent code of practices to create a wider ecosystem. Topic for future weeks: outcome of user stories discussion, PDP architecture includes the concept, TOIP/SSI are starting to define this ecosystem function Topic for future weeks: ANCR records update, Privacy as Expected. AOB https://www.ontario.ca/page/consultation-policy-framework-ontarios-digital-… Feel free to submit comments to Ontario about the DI strategy Alec will be away next week Attendees As of October 26, 2020, quorum <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is 5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve) Voting: 1. Alec 2. Sal Non-voting participants: 1. Zhen 2. Ian Regrets: 1. Eve <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16>

2 4

Agenda for UMA telecon 2021-09-16
by Alec Laws 15 Sep '21

15 Sep '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16 UMA telecon 2021-09-16Date and Time - *Primary-week Thursdays 6:30am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/485071053 <https://www.google.com/url?q=https://global.gotomeeting.com/join/485071053&…> - United States: +1 (224) 501-3316, Access Code: 485-071-053 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2021-09-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09> - Correlated Authorization - OAuth vs UMA content - AOB

1 0

Correlated Authorization
by Igor Zboran 15 Sep '21

15 Sep '21

Hi all, I have been thinking for a long time how to convey information about the user from an identity provider to an authorization server, especially across security domain boundaries. This is difficult to implement because OAuth2, OIDC and UMA are single-authority protocols. That's why I tried to extend the UMA protocol to a dual-authority protocol. Please find a short draft proposal here: https://github.com/uma-email/poc I would be very interested to know if this is the right way to do it and what you think about this idea. Disclaimer: Although I present the idea of the correlated authorization as a new protocol, if adopted and refined by the working group, it could be referred to as the UMA wide ecosystem. Regards -Igor

1 0

Draft minutes of UMA telecon 2021-09-09
by Alec Laws 09 Sep '21

09 Sep '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2021-06-10 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-10> , UMA telecon 2021-06-17 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-17> , UMA telecon 2021-06-24 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-06-24> , UMA telecon 2021-07-01 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-01> , UMA telecon 2021-07-08 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-08> , UMA telecon 2021-07-15 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-15> , UMA telecon 2021-07-22 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-22> , UMA telecon 2021-07-29 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-07-29> , UMA telecon 2021-08-05 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-05> , UMA telecon 2021-08-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-12> , UMA telecon 2021-08-19 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-19> , UMA telecon 2021-08-26 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-26> , UMA telecon 2021-09-02 <https://kantarainitiative.org/confluence/display/uma/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/ <http://fhirserver.com/fhir-api>random-registered-uuid → <http://fhirserver.com/fhir-api> - fhirserver.com/fhir-api <http://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. 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_Famil… Will start a confluence page to start moving the minuted cases to Then it 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 <http://kantarainitiative.org/confluence/display/uma/Participant+Roster> 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

1 0

Agenda for UMA telecon 2021-09-09
by Alec Laws 09 Sep '21

09 Sep '21

1 0

Agenda for UMA telecon 2021-09-02
by Alec Laws 01 Sep '21

01 Sep '21

1 0