- WG-UMA - mailman.kantarainitiative.org

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

Draft minutes of UMA telecon 2021-08-26
by Alec Laws 26 Aug '21

26 Aug '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-26 MinutesRoll call Quorum was NOT 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> Deferred Minimal Interop Profile Let's get to some test cases/requirements? PAT is fairly impl specific, could be given to the Mock RS test suite - auth code flow - can become first point of non-interop Goal: make sure that AS's are interoperable , eg one AS can be 'swappable' with other ASs. Understanding of 'extras'/vendor specific values that degrade that interop. As an RS the more ASs I can support define the 'wide' ecosystem I can support Scope of test - 1 AS under test - 1 Mock RS test suite - 2+ ROs - clear success cases (including error conditions) - response testing for unexpected values returned → WARN - Minimum Viable ONLY Input to Mock RS Test Suites - name of 'rreguri' endpoint at the AS - multiple PATs to represent the RO context - at least 2 - value for _id, ie what key will the AS return - resource descriptions keys supports - Only required content is resource_scopes - Optional to push other keys (type, desc, name, icon_uri) - create support for user_access_policy_uri - use of introspection - optional support for exp, iat, nbf (maybe too much since this is OAuth introspection scope) 1. resource registration 1. Error cases 1. PAT less requests 2. get/put/delete, requests without known id 3. leaking between PATs 2. Create resource description: POST rreguri/ - should always work, returns new id - performs 5+ times for each PAT 3. Read resource description: GET rreguri/_id 1. ready all created 2. should always work for returned ids 4. Update resource description: PUT rreguri/_id - should always work, return same id 5. Delete resource description: DELETE rreguri/_id 1. should always work 2. removed from list after deleted 3. future: effect on RPTs/tickets 6. List resource descriptions: GET rreguri/ 1. only returns created resources for this PAT 2. likely interjected between other cases, ensure state is reported accurately 2. permission ticket creation 1. all scopes for single resource 2. multiple resources, all scopes 3. single resource, subset of scopes 4. multiple resource, subset of scopes 5. error cases 1. wrong resource for PAT 2. wrong scopes for resource id 6. future, 1. AS overriding resource/scope sets 3. introspection (optional) 1. keep in mind, introspection is an OAuth defined item, want to limit to UMA defined functionality to remain minimal viable 2. RPT issued with all resources from permission ticket 3. RPT used with correct PAT 4. active:true, must have the 'permissions' array 5. how to test active:false response? 1. would require manual intervention at the AS? 6. error cases 1. wrong PAT for RPT 7. (future) AS imposed changes based on policy The test suite could be 'random' ie for scope generation? Real application, UMA protect userinfo (OIDC scopes) Relationship Manager - user stories / *Discovery* 1. As a Client, I want to be able to declare types I understand, in order to successfully use complex APIs 2. 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) 3. As an ASO, I want to pre-register Clients, in order to assess their appropriateness, capability and complete non-technical activities 4. As a Client, I want to pre-register with ASs, in order to a) test my UX and technical integrations b) declare my capabilities UMA in Wikipedia Have started an open document with the current english content. Everyone is welcome to suggest and edit and we can review next week https://docs.google.com/document/d/1TbD4ODQOdQkLwHjlpjTQ4lbEPMbky67O8Clrzxe… 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. Eve 2. Alec 3. Steve Non-voting participants: 1. Scott 2. Anik

1 0

Agenda for UMA telecon 2021-08-26
by Alec Laws 26 Aug '21

26 Aug '21

1 0

Draft minutes of UMA telecon 2021-08-19
by Alec Laws 19 Aug '21

19 Aug '21

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-08-19 MinutesRoll call Quorum was NOT 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> Deferred UMA in Wikipedia Have started an open document with the current english content. Everyone is welcome to suggest and edit and we can review next week https://docs.google.com/document/d/1TbD4ODQOdQkLwHjlpjTQ4lbEPMbky67O8Clrzxe… Relationship Manager - user stories 1. As a Client, I want to be able to declare types I understand, in order to successfully use complex APIs 2. 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) 3. As an ASO, I want to pre-register Clients, in order to assess their appropriateness, capability and complete non-technical activities 4. 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 Goal: What parts of the spec will be test? Should we separate Grant from Fedz? What is takes around the UMA AS 1. Mock RS (well known resources/scopes) 2. Mock Client (well known requests) 3. Mock IDP (well known RO/RqP) Fedz: - Mock RS test client - PAT creation - RS client credentials - RO authorization → auth code flow - 1 resource registration - set of resources, scopes, - 2 permission ticket creation - 3 introspection Grant: - Mock Client test client - Client Credentials → static/ well defined - RPT endpoint - claims pushing, multiple rounds of pushing? - error - claims pushing or gathering - request submitted - PCT - claims gathering endpoint Policy: - RqP has the rights via identity - Other requirements, agree to ad-hoc TOS - specific acr/scopes in claims token from FR AS: https://github.com/ForgeRock/frdp-uma-resource-server/wiki - claims pushing (IDToken) - no - PCT - not quite - request_submitted is supported, creates a pending req for RO, not using ticket/interval though - redirect_user / interactive claims gathering, gets a claims token through an auth_code flow IDENTOS AS: - interactive claims gathering - RSasRO, RO has client credentials with AS - no - request_submitted - PCT - claims pushing *Discovery* Per RS-directed - the RO can tell the RS that some resources are public/discoverable (their existence not their content...) - RO is able to share that discovery URL to the RqP, - doesn't mean the RqP can access all → could UMA protect discovery/webfinger, and get back the specific "stuff" that RqP can access - this is instead of sharing many specific URLs - RO has abstracted URLs for specific resources, this is separate from discovery? File names... in medical case the resources don't have 'names', A LOT of info falls under simple types. Eg sleep records vs infectious disease, should the RqP be able to discover the existence of both types even if they can only access the sleep records. AS-directed (or discovery service-directed) - An RqP goes to the AS and asks for all the resources granted to the RqP - the AS has the resource and the policy about which RqPs can access - can the RqP learn about the resource URLs (across many RSs) it can access - Similar to Pension Dashboard case, discover and register all pensions with a single AS. RqP (user or financial advisor) go to the AS to find the locations and authZ to access - Identos use-case, - the Client understands specific types of resources (eg xrays) - send the RqP to the to the AS to - i) know who the RqP is and (eg the Primary Care Physician) - ii) which resources that RqP have that match the type (all their patients xrays) - iii) choose which of those to share with the client (a specific patients for a specific encounter) Two discovery endpoints 1. protected discovery → managed by AS 1. (or indapendant discovery service?) 2. OIDC distributed claims (endpoint, token) that the RP can get claims from there 3. the AS doesn't know the endpoint in UMA today 2. public discovery → managed by RS 1. in FR impl, the RS proxies Client requests to the AS, to reduce who the client needs to talk to and could provide the more wholesome discovery 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. Thomas 2. Alec Non-voting participants: 1. George 2. Scott Regrets: 1. Steve

1 0

Agenda for UMA telecon 2021-08-13
by Alec Laws 18 Aug '21

18 Aug '21

1 0

Agenda for UMA telecon 2021-08-12
by Alec Laws 11 Aug '21

11 Aug '21

1 0