April 2020 - WG-UMA - mailman.kantarainitiative.org

Resource Definitions/AS-first flows
by Alec Laws 30 Apr '20

30 Apr '20

Hi all, Thanks for letting me share some of the extension thinking we’ve been going through at IDENTOS Hopefully the content below adequately describes the first of our changes (RS-first flows) to continue the conversation. Goes through some of the motivation, conceptually how it works,, and calls out items that are particularly different or have challenges being UMA compliant. As many of you noted, in many ways this is a concept of a directory or trust-framework above specific AS/RS/Clients or the actual RO/RqP (intentionally excluding Alice/Bob) Cheers! - Alec Ps More to come on privacy extension, the community vs personal authorization server and SSI alignment # AS first flows/ RS discovery / Resource Server API Interoperability General idea is that many RSs support a very similar API, eg FHIR/OpenBanking/Gitlab, so a Client _should_ be able to use any of those RS, as directed by the RqP. However, the 'very similar' part makes this difficult in practice. Ex two RSs could be FHIR R4, with a different vocabulary set such that the client can't actually use the APIs interchangeably. We believe this is important as a user should have choice throughout the stack, currently choice exists at the Client and AS. Clients must know of/directly integrate to the RS, capping which RSs can be used with the client integration efforts. Current State: UMA moves OAuth towards 'wide-ecosystems' by enabling AS interoperability. A RS can be protected by many AS, and an AS can protect many RS. From the Client's perspective, it only needs to know the RS it wants to access, and can "discover" the AS. ## How it works: ### Setup/Registration: 1. The AS defines general "resource definitions", This is an API standard reference with well defined scopes. - FHIR (scopes: sens/*, conf/*, patient, observation, ...) - FHIR - Patient - FHIR - Immunization - Userinfo - (scopes: first_name, email, birthdate, ...) 2a. Clients are registered with the AS for specific resource definitions - Client A can request a FHIR - Patient - Client B can request Userinfo (first_name), FHIR - Immunization, FHIR - Patient - Client C can request Userinfo (first_name, last_name) 2b. Clients are registered with "capability tickets" (static UMA permission tickets?) for different resource request sets - This could also be achieved in a more uma standard/dynamic manner where the client uses the Fedz Permission API with the general resource definitions - Client B can have a few tickets - "client-ticket-userinfo" -> Userinfo - "client-ticket-immunization" -> FHIR - Immunization - "client-ticket-patient" -> FHIR - Patient - "client-ticket-all" -> FHIR - Patient AND FHIR - Immunization AND Userinfo definitions 3. Resource Servers are registered with the AS for specific resource definitions and the endpoints where they are located - ex - RS X can provide Userinfo (first_name, last_name) - RS Y can provide FHIR - Immunization, FHIR - Patient - RS Z can provide All resources and scopes - The RS has a RO-independant PAT (RS=RO?) in order to introspect ### Client AS-first flow: 1. A RqP appears at Client A, the client needs access to a FHIR - Patient to provide some service 2. Client AS redirects to the AS claims_gathering with "client-ticket-patient" 3. The RqP authenticates (somehow) and can see RSs they can access: RS Y and RS Z - RO/RqP authentication and Alice-Bob delegation are out of scope, handled internally at the AS 4. The RqP selects the FHIR - Patient from RS Y 5. The AS redirects to the Client with a new permission ticket 6. The Client exchanges the ticket for a RPT, the token comes with a "resource_location=RS Y/Patient" - This could also use the token ‘aud’, however, that requires JWT and that the client inspect the token 7. The Client makes the request to RS Y with the RPT 8. The RS introspects the RPT to determine both resource and scopes it's valid for, and also which user/access it's for - The introspection was made with the general RS PAT. The response must include some other information about the specific Resource to access (in this example the specific Patient record) - This step has overlap with our other 'extension' around separating community from personal AS - Currently, when the RS is put under protection the RS/AS decide on a user subject. The AS returns that subject with the introspection so the RS can make internal determination about what specific data to return - Another alternative, when the RS is put under protection is it may register a user specific version of the general resource. During step 4 the RqP can select that specific resource. 9. The RS returns the resource to the client, or can perform the UMA WWW-Authenticate as usual ## Other Considerations: - The client ticket can(?) have multiple resources, and _could_ end up needing the client to receive multiple RPTs? - If we enforce RS-restricted tokens - difficulty here in the format of the token endpoint… current support a normal token endpoint for RS-first and also a “packed” response that returns the multiple tokens if needed - this likely should be a different grant_type - There is some notional alignment with OAuth resource indicators or PAR, haven't looked too deeply Alec Laws 647 822 1529 alec(a)identos.ca <mailto:alec@identos.ca>

3 3

Draft minutes of UMA telecon 2020-04-30
by Eve Maler 30 Apr '20

30 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-30 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-03-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12> , 2020-03-26 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-26> , 2020-04-02 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-02> , 2020-04-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-23> Deferred. Resource definitions profiling use cases (Alec) Eve had an AI to find our old ecosystem/co-location of parties work. Our oldest writeup is gone, but the new version is on slides 14 and 15 of our Legal Role Definitions deck <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…>. Slide 15 in particular shows how a wide ecosystem can be "narrowed" when different Operators are co-located in a single entity. Adrian notes that MyData came out with its Operators paper <https://mydata.org/operators/> yesterday. It's not technology-specific but is surely relevant here as well. He also points to this governance paper <https://www.anewgovernance.org/>. The relevance of "ecosystem shape and size" is that the resource definitions profile we might define could apply to ecosystems not of the widest possible size but of potentially limited size or shape. In other words, the profile could make assumptions about co-location of certain services. Jim provides this writeup on fiduciaries <http://www.opentrustfabric.org/File/EU_JUST/Present/OTF-FiduciaryArchitectu…> . The goal in ACE for its AS-first flow is to achieve disconnection opportunities for the RS, which is not the purpose of the resource definition profile – but it would probably be a good idea to consider compatible profiling for the two sets of use cases (resource definition and constrained environments) so they could be used at the same time. Alec has put details about the use cases he provided below as a comment to this page. The first use case Alec mentions is where the AS enables IdP discovery, where UserInfo is the resource of interest. The AS effectively defines the boundaries of the community. The AS need not be colocated with the actual IdPs. Each IdP is an UMA RS that can register which particular attributes (as, say, UserInfo scopes) it supports. This was the original use case for which the profile was developed. The FHIR Repo Interop use case is the one we've been talking about a lot, where the FHIR open API is used in specific detail in various ways by different RS's (clinics). What they're seeing is that a traditional OAuth RS is able to start offloading responsibility onto an UMA AS. A provincial identity management program (IdP), in order to scale out and support thousands of services, can sufficiently "trust" the AS to make the agreement with each RP (UMA client) using this profile. Adrian asks: Who checks the credentials of the RqP, and who checks the credentials of the client of the RqP? It could be the AS in both cases. Adrian notes that the doctor is currently captive to the EHR system. He wants to make it possible for the doctor to have a choice in applications and to have a secure element for holding their private key (which they need for e-prescribing). This value to the "requesting side" is apart from the privacy-respecting value. This could even be valuable to a big company with ten different IdPs or other RS's internally, using the same (proprietary) API. So we think there is definitely horizontal/broad relevance to working on this profile Please continue reviewing the use cases in the comments below and discussing on the list. Interop meeting update Deferred (but Eve notes that she, Colin, Alec, and Mike met and made some progress towards a plan for putting together conformance testing, and we invite anyone else interested to raise a hand). Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Andi 4. Eve 5. Mike Non-voting participants: - Alec - Cigdem - Jim – back in California, working with GA4GH - Scott - Adrian - Colin - Tim The theme here is instead of all RPs needing to know about specific IDP/RSs, the the RP and RS are decoupled through an Authorization Server, allowing the SP to discover which RS to call after user authorization. This requires all RSs to support a standard API, claims_gathering and JWT tokens ## Use Case: IDP discovery, userinfo as a resource Scenario: There are many similar IDPs which may provide standard profile data to a RP, through /userinfo endpoint There are many RPs that would trust any of those IDPs to provide profile data from a user Using RS Discovery, an Authorization Server can manage the IDPs (as RSs) and _all_ RPs Outcome: Reduce integration to only the AS for IDPs(asRS) and RPs - IDPs/RPs can still participate with many AS - user profile data isn't known to AS Notes: Possible, but not nessecary, that the IDPs are an IDP to the AS. User login to the AS through one of the IDP Similar solutions - yes.com which offers bank/idp discovery as a directory/dynamic-ish client registration to the specific IDP - gov.uk verify Alternate Scenario: Even with a single IDP, that IDP can delegates RP onboarding to one or more AS ## Use Case: FHIR Repo Interop There are several clinics which collect healthcare data and offer a simple portal to their patients. Many of the patients request to share their data with other applications. Instead of each clinic curating and vetting all application, they can delegate this to an Authorization Server There are several [healthcare systems] that all support a [FHIR r4] API ## Use Case: Prevent Multiple Required Logins/Resources An RPs requires a user to login to multiple IDPs to authorize an action (for legal/whatever reasons) OR an RP requires data from multiple RSs in order to provide a service The AS can issue multiple access_tokens to the RP... and the RP can make API calls to both RSs with the appropriate constrained token ## Use Case: Data across FHIR Repos A blend of the previous two use cases There are many FHIR systems in a region. Each system maintains a specific subset of a patient record. For example there is an immunization repository and lab results repository There are 3 example RPs, RP A needs only immunization, RP B needs only lab results and RP C needs both. Using resource discovery each RP is registered with a ticket specific to the scope of their needs. In the last case, RP C can make one authorization request and may be granted access to both FHIR repositories *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Regrets
by George Fletcher 30 Apr '20

30 Apr '20

IIW conflict today

1 0

Agenda for UMA telecon 2020-04-30
by Eve Maler 29 Apr '20

29 Apr '20

(I've confirmed that the correct GoToMeeting number is now listed everywhere.) https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-30 Date and Time - *Alternate 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&…> - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Approve minutes of UMA telecon 2020-03-12 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-12> , 2020-03-26 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-03-26> , 2020-04-02 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-02> , 2020-04-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-23> - Resource definitions profiling use cases (Alec) - Interop meeting update *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Apologies for including the wrong GTM link on the agendas
by Eve Maler 23 Apr '20

23 Apr '20

*Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Draft minutes of UMA telecon 2020-04-23
by Eve Maler 23 Apr '20

23 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-23 MinutesRoll call Quorum was reached. Approve minutes Deferred. Meet next week? Yes, let's meet next week. IIW is creating session times across the globe so people in different locations can join. IDENTOS extensions Alec's questions for the "resource definitions profile" are: What are the next steps? He hasn't prepared anything today for the "wallet profile" (they consider it as potentially an SSI wallet, doesn't have to be, but it's an OAuth client type that can evolve). The first step in determining fully if/how we want to take up the first profile is: What are the use cases we want to solve? The increasing "horizontalization" of use cases, where vertical sector use cases mix together (as in payments and health care), might encourage us to take up a profile in this area so that it can help open APIs in different sectors work. Eve showed a map of global open banking (lowercase) efforts. Alec noted that some people refer to "client-directed banking" to avoid talking about any specific jurisdiction's effort. *AI:* Alec: Propose different use cases he has seen, including in open banking. How important is it to include delegation use cases (requiring UMA) in open banking/client-directed banking from the get-go? We've had these discussions, and there has been little motivation. Typically the motivation has been to solve security and very minimal consent use cases as a base layer, and that's been the focus for the last three years. Who here is involved in open banking efforts? Mike, Eve, Alec, George keeps one eye on it. *AI:* Eve: Find and share our old UMA ecosystem design patterns document. The language around consent vs. delegation/directed sharing/(something) is coming up more and more. Eve tried for a long time to connect UMA to traditional (opt-in/opt-out) consent. "Consent directives" in healthcare is the only line that can be drawn between (e.g. proactive) asynchronous sharing and "consent". It's possible to implement traditional consent flows, a la OAuth authorize/deny, with UMA, but you get more value out of the UMA version if you are (e.g.) loosely coupling the AS and RS. UMA enables licensing on the RO's terms. We haven't defined the terms. Lisa points to the licensing spec work of IEEE P7012 <https://1drv.ms/w/s!AhLg8xmL6FALhJwvLl7Rn-Aanz1NEA?e=Gitl2W>. Mark suggests we check out a great eConsent video by Meg Doer <https://sagebionetworks.org/tools_resources/ohrp-econsent-webinar/>. Thomas notes that the word “consent” needs to be qualified, just like "trust". Intro Mike worked with Michal, who prepared the demo for Identiverse 2018 that Mike showed. Michal could be available to build a test suite. Gluu is willing to host it. Here are the top-level requirements: - Test harness in an OIDC test harness style - Hosted - Produces "red light/green light" types of answers for particular test assertions - Could be considered unofficially to be testing "self-service conformance", until we decide it's official - Tests AS interop at first, then eventually RS interop, then client interop Nancy suggests doing a connectathon. Some comments on that approach: It can tend to be expensive to participate, and the challenge is that the API chosen is specific to the industry. Colin has some ideas for building funding ("up" or "down"). Mike believes the test harness shouldn't be as bad as OIDC since there are fewer conformance profiles and options in UMA. Eve is a bit concerned about the fact that UMA sort of incorporates OAuth in a sense, but maybe we can carve out and "not do" pure OAuth testing, or alternatively entice others into covering that part. *AI:* Colin, Alec, Mike, and Eve to meet some time prior to next week's UMA WG call to do UMA interop wrangling. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Thomas 4. Maciej 5. Eve 6. Mike Non-voting participants: - Anik - Adrian - Scott - George - Lisa - Alec - Mark - Tim - Colin *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-04-23 (moved from Apr 16)
by Eve Maler 23 Apr '20

23 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-23 Date and Time - *Alternate Thursdays 6:30am PT (this meeting was moved from Apr 16)* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Should we meet next week? It's virtual IIW - IDENTOS extensions - Interop *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Need to cancel tomorrow's call; may move it to next Thursday
by Eve Maler 15 Apr '20

15 Apr '20

Apologies for the late notice, but I have some conflicts that have cropped up with tomorrow's WG call. In order to preserve our ability to meet as best as possible, does anyone have a big problem if I schedule us for next Thursday at the "usual time"? *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2020-04-02 (ad hoc)
by Eve Maler 02 Apr '20

02 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-02 MinutesWhich week to meet George points out that the "OpenID A/B" (OpenID Connect) meeting overlaps the latter half of this meeting if we meet last/next week vs. this week/2 weeks from now etc. No one attending today has a problem. Eve will investigate with others and voting participants who are not currently present and reschedule if no problem. (*UPDATE:* Sufficient positive responses established, so Eve will switch weeks in the calendar. We will start meeting Apr 16, Apr 30, etc. instead of continuing with Apr 9, Apr 23, etc.) Online notarization Tim raises the topic of the current worldwide situation and the fact that online notarization has suddenly become more important. Is this similar to remote proofing? These technologies have certainly existed for quite some time, and have been integrated to IAM stacks. But it got more notice in Okta's keynote this week, which mentioned use cases like employee onboarding. IT budgets seem overall negatively impacted in the current environment, though this is not evenly spread out. UMA and delegation use cases generally depend on identity solutions being in place, so that makes them relatively "sophisticated". On the other hand, telehealth and health data sharing are under more pressure now. IDENTOS extensions Alec provided a sequence diagram and we worked through it. To download, see the attachments <https://kantarainitiative.org/confluence/pages/viewpageattachments.action?p…> to this page. The resource IDs are static. The "RS PAT" is not RO-specific. The capability ticket is static. If you want to see a patient record with an immunization, you get a capability ticket that's sort of like a permission ticket but it doesn't change. This maps to terms of use. When a RqP authorizes the client to access resources and scopes, they review the ToS. This is Alice-to-Alice sharing right now. So the effect is Alice reviewing ToS for accessing her own stuff. What is in this ToS? It's the client's ToS for usage by the RqP, whoever it is (could be Bob in future). The client uploaded this to the AS for safekeeping, effectively. So the AS presents the ToS to the RqP on the client's behalf. Thus, instead of the possibility of the RqP having an independent relationship possible with that client outside of UMA and that AS, the RqP is assumed to use the same AS as the RO does, so it's a narrow ecosystem assumption. (See slide 36 in the UMA Legal role definitions <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> for the "RqP-CO-ASO relationship train tracks" for how it could be built up in the widest possible ecosystem.) Security-wise, is it okay for the capability ticket to be static? It's like requesting a scope, so it's okay for it to be static. So yes, it's safe. George describes the critical characteristics: If it's just an identifier, it's okay to be static. If it's a "binding agent" across multiple flows, then it needs to be rotate. Is the capability ticket similar at all to OAuth resource indicators (now RFC 8707 <https://www.rfc-editor.org/rfc/rfc8707.html>)? It's more general, but the analogy does apply. The client would use the resource definition in the URI instead of the resource server. What happens if the API gets versioned? Is there a CRUD API or something? The capability API has something like the resource registration API. IDENTOS has implemented a dynamic version along with their static version, but they're not currently using it. The *first flow* in the diagram is "standard UMA", RS first. The RS can still request a permission ticket, only using static resource IDs. The last leg is always a token endpoint call with either form of claims collection. The *second flow* is the static capability ticket flow. The client goes to the AS first and then goes straight to interactive claims gathering. The RqP (currently the same person as the RO) is then at the AS after the redirect and can authenticate etc. The *third flow* is a hybrid where the client, *not* using the static capability ticket, uses the permission endpoint as if it was the RS. This is perhaps a bit like OAuth Pushed Authorization Requests (PAR <https://tools.ietf.org/html/draft-ietf-oauth-par>). Are there any security implications to this? The client is similar to an RS in that they have registered what they can do. Since a PAT is now no longer RO-specific, the client can go ahead and use their client credentials as a "PAT-equivalent". The AS can distinguish them from an RS because they have registered as a client. After the three flow options, saying (say) that they're looking for a patient record, now the RS still has to be told which patient's resource to give out. So in introspection, the AS provides subject information explicitly in its response, along with the granted resource IDs and scopes. Or George notes that an encrypted access token could contain that information. The RPT is still used. (Last week Alec noted that it was in this step, providing the subject, that there is some potential overlap with the other extension they have defined. See his email to the list <https://kantarainitiative.org/pipermail/wg-uma/2020-March/005943.html> and the description of "step 8" for more detail.) Thank you to Alec and IDENTOS for contributing this for the WG's consideration! The "narrow ecosystem" this use case serves does seem pretty common (shared AS between the RO and RqP, oftentimes the RO == the RqP, the design patterns of the resource need interop due to open APIs or other reasons). Other questions and comments we didn't have a chance to address yet, maybe in future: - George: Could you use Dynamic Client Registration of the mobile app to help with this? That would make the client_id specific to each mobile app instance - Sal: trusted platform environment might also come into play We seem to have interest in considering work on this as a WG. More to come. Interop Deferred, but some people are working on this as a separate thread. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Sal 3. Eve 4. Mike Non-voting participants: - Cigdem - Scott - Alec - Tim - George - Colin *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-04-02 (ad hoc)
by Eve Maler 01 Apr '20

01 Apr '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-02 Date and Time - *Alternate Thursdays 6:30am PT (this ad hoc meeting was added in the series specially)* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - IDENTOS extensions - Interop *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0