- WG-UMA - mailman.kantarainitiative.org

UMA Relationship Manager - draft spec text (aka UMA Wallet)
by Alec L 13 Aug '20

13 Aug '20

Please find some updated spec text below. Changes are mainly to: intro, policy api, AS metadata, add (empty) introspection section, add spec-is wrapper/formatting Perhaps should be pushed to the UMA GitHub (as Eve has been hinting at!) Cheers, - Alec Alec Laws 647 822 1529 alec(a)identos.ca # UMA Relationship Manager (aka Wallet) | | | |:---|:---| |Version:|0.1| |Document Date:|2020-07-30| |Editors:|Alec Laws| |Contributors:|| |Produced by:| |Status| | |Abstract| | |Suggested Citation| | #### Notice IPR Option: Non-Assertion Covenant Copyright: The content of this document is copyright of Kantara Initiative, Inc.© 2020 Kantara Initiative, Inc. ## 1. Introduction This document extends [UMA Fedz] in order to specify the management and control interfaces through an UMA Relationship Manager Client. This new client type defines how an Resource Owner may connect to Resource Servers, put those resources under protection and finally create and manage policy at an AS over those registered resources. This role is a Client application that may be accessible to the end-user through various user-agents (eg Browser, native app) This new client type provides the end-user a consistent consent management interface that may be used across multiple ASs, where the RO is able to choose an independent policy management service, or tightly coupled to a single AS. In some profiles, this extensions enables the AS to operate with a minimum of collected personal data. The UMA Wallet operates in two distinct modes, for the RO and the RqP. The UMA Wallet performs three major flows with other systems: 1. RO puts resources under protection 2. RO creates policy 3. RqP performs claims gathering, ### 1.1 Notational Conventions ### 1.2 Abstract Flow ``` +------------------+ +------------------+ | resource | | requesting | +---------- | owner | | party | | +------------------+ +------------ -----+ | | delegation | | +------------------+ | | | | +-----manage ---------- Wallet | | | +------+-----------+ | | | +-----------+ | | | | claims | | | | | gathering | | | | | API(OIDC)| | | protect +-----------+ | | | ^ | | | | | | | | | v v | | +-----------+ protection +-----------+ | | | manange | API access | policy | | | | API | token (PAT) | API | | + +-----------+ +-----------+ | +------------+ +----------+---------------+--+ | | |protection| | | resource | | API | authorization | | server |<-----prot---| (needs | server | | | | PAT) | | +------------+ +----------+------------------+ ``` This specification uses all of the terms and concepts in [UMAGrant] and [UMA Fedz]. This figure introduces the following new concepts: - UMA Wallet - Policy API The API presented by the AS to the Wallet. This API is OAuth(UMA?) protected - Manage API The API presented by the RS to the Wallet. This API is OAuth(OIDC?) protected ### 1.3 HTTP Usage, API Security, and Identity Context ## 2 Authorization Server Metadata This specification makes use of the authorization server discovery document structure and endpoint defined in [UMAGrant]. The relationship manager uses this discovery document to discover the endpoints it needs. In addition to the metadata defined in that specification and [UMA Fedz], this specification defines the following metadata for inclusion in the discovery document: policy_endpoint REQUIRED The endpoint URI at which the relationship manager modifies policy on the user's behalf The Authorization Server should indicates it's support of this profile by including the URI to the specification in the uma_profiles_supported metadata array ## 3 Manage Endpoint The management API allows the wallet to manage resources on behalf of the authenticated resource owner. The manage API allows the RO to register credentials (public keys... or otherwise) the RS will trust policy signed by. The policy is delivered by the AS to to RS in the RPT or through introspection. The manage API may be extended to allows the wallet - to read available resources, - direct the RS to register resources at a specific AS, and see ASs/registered resources - dynamic registration of an RO specific client ### 3.1 Create Credential Example ``` POST /credential Authorization: Bearer something { oauth dyn client reg with a embedded jwk } { a DIDDocument... } ``` ## 4 Policy API note: this API is very similar to the permission endpoint, expect the payload includes an RS sub, additional policy condition, and is signed by a RO-RS credential The API available at the policy_endpoint enables the relationship manager the modify policy over the RO's protected resources. These policies define the claims gathering requirements for an RqP to gain access to the resource, and should also indicate the intended purpose/use for resource access. Management of the policy beings on successful creation and ends on successful revocation. The relationship manager uses a RESTful API at the authorization server's policy endpoint tto create, read, update, and delete policy descriptions, along with retrieving lists of such descriptions. note: I think it's also useful to allow the RO to read a list of registered resources, I don't think woudl live under the policy_endpoint, it's essentially like the GET API from the resource_registration_endpoint with additional infomration about the RS? note: through the ` "user_access_policy_uri":"http://as.example.com/rs/222/resource/KX3A-39WE/policy"` the RS could also let the relationship manager know (though manage API) what path to use at the AS to modify policy for this resource?? This restricts Figure TDB illustrates the policy API operations, with requests and success responses shown. ``` FIGURE TDB ``` ### 4.1 Policy Description A policy is a JSON document, that describes the a policy sufficiently for the authorization server to make a decision for a resource request. A policy document MAY be provided as a signed JWT to ensure it's integrity to the RS during enforcement. A policy description has the following parameters resource_id REQUIRED The resource id registered at the AS that this policy applies to resource_scopes REQUIRED The approved scopes if the claims requirements are met claims REQUIRED An array of claims/attributes that must be presented by the RqP in order to access this resource under this policy optional/extension/discussion: sub The subject known by the RS for this RO (useful for general resource definitions) resource_server (again, useful for general resource definitions) client_id The client application that may be used to access this resource intent The purpose/intention of resource use the RqP must accept For example... ``` { resoruce_id: "KX3A-39WE", "resource_scopes": [ "read-public", "post-updates", ], claims: [ ??? ] } ``` --- updated to this point ### 4.1 Policy Description The policy is a JWT signed by a RO credential known to the RS that owns the resource_id Example Payload ``` { "sub": "a RO chosen sub to identify to the RS" "resource_scopes":[ "view", ], "resource_id": "resource_id", ...extension/optional "client_id": "resource_server": "req'd for res def profile" "other_conditions" "" } ``` ## 5 Claims Gathering (OIDC) THe claims gathering API allows the AS to delegate RqP authenticate and claim collection to the Wallet. The wallet allows the RqP to respond to a registered RO policy for the requested resource. ## 5 Introspection In some cases, policy should be conveyed through the AS back the RS for independent verification ## Security Considerations ## Privacy Considerations ## Acknowledgments ## References --- ## Authors' Addresses

1 1

Agenda for UMA telecon 2020-08-13
by Eve Maler 13 Aug '20

13 Aug '20

We are on our “alternate-week” schedule, meeting at 10am PT. Calendar with details is here: https://kantarainitiative.org/confluence/display/uma/Calendar We’re still working on the Relationship Manager profile. Let’s try to push ahead on spec text if we can. Let’s also do a quick roundup of healthcare/ONC goings-on and how we can contribute. (Sorry for the informal agenda. I’ll have a proper meeting/minutes doc for us eventually!) Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Cascading and Self-Sovereign Authorization Servers
by Adrian Gropper 06 Aug '20

06 Aug '20

All, It was suggested we define these two terms before using them in the group. Allow me to start since I brought them up, but please feel free to suggest alternate definitions. *Cascading AS* is an AS operated on behalf of an entity other than the RO herself. The RO is presumed to have chosen her AS and may have also consented to being assigned another AS as well. It's unclear which of the ASs is the cascading one or if both of them are. The term cascading AS originates from efforts to differentiate an AS that is operated by the RS as in OAuth. The difference between an OAuth AS and a cascading AS is unclear. The reason to introduce a cascading AS seems to be to limit the choices of AS to those acceptable to the RS or a federation of RSs. If there's to be another AS as well (the cascade) then the question becomes: do the RO and the RqP interact with one or both of the ASs in the cascade. It seems like we have a 2x2 matrix of choices. It would be good to understand the intent before going further. A *self-sovereign AS*, like a self-sovereign identifier (SSI), is controlled by only one entity, typically an individual, without any reliance on a federation or centralized authority. There are two benefits to operating one's own AS: (a) As a RO, you don't need to share your policies with anyone else, just the result of applying the policies to a particular request. (b) As the processor for RqP requests, you are minimizing the leakage of information about who is interested in your resources and why. Leaked information about policies or request patterns is of great value to aggregators that can process this information into inferences that are then sold as surveillance capitalism. - Adrian

2 3

Agenda for UMA telecon 2020-08-06
by Eve Maler 05 Aug '20

05 Aug '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-06 Date 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 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> , 2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> , 2020-07-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23> , 2020-07-30 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30> - PKCE + ICG considerations - Per Alec's email <https://groups.google.com/g/kantara-initiative-uma-wg/c/t72iQgd2qEU> - Relationship Manager profile - Taking into account/defining terminology, e.g. whether we should define "self-sovereign" and/or "cascading" AS's as part of the topology choices, per Adrian's thread <https://groups.google.com/g/kantara-initiative-uma-wg/c/PbbLJZpekqc> - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Nordics Healthcare
by Colin Wallis Kantara 03 Aug '20

03 Aug '20

Folks Following the UMA webinar, and a comment raised there about KANTA (the Finnish Healthcare spec that looks like handcrafted OAuth on a first glance) Jan Leindals reached out to me. Jan's Diabetes organisation is the recipient of funding from Kantara Europe's NGI_Trust consortium. I have encouraged him to connect with you all here. Kind regards Colin ................................................................................................. Thank you for a very interesting discussion in US/CAN which is also relevant in a Nordic context. The reference to Finland was about the PHR data repository, Kanta Services and not UMA. However, I found this paper though, https://www.kanta.fi/documents/20143/91486/PHR+authorization.pdf/9fdb48d0-a… In the Danish healthcare system the PHR data repository is a missing link. In Denmark the citizen do not get data rights to their health data (EHR) in the public domain – it is fully controlled by the government by using new national [digital identity] standard, in progress: https://en.digst.dk/media/14836/english_fremtidens-infrastruktur-for-digita… However, it is very immature how this will be implemented into the local EHR systems. This system consist of many sub-systems that is being integrated into the EHR system and no standard for UMA – each subsystem make their own standards. For diabetes the healthcare system has a gap to control of the use of data from medical devices where multiple vendors have their own services. They are typically hardware inventors and their service lack use of identity and permission control. I promote that the PHR from medical device data and other personal behavior data will be implemented as a new data repository where the citizen have all the data rights and it open for innovation for all actors and new standards for identity and permission control. To solve the gap for in Denmark, I am very interested to know more about the UMA protocol and if a standard implementation of UMA can be integrated into the Tidepool ecosystem [part of Jan's project funded by NGI-Trust] as a showcase for diabetes as a use case of UMA in the Danish Healthcare system. Some discussion papers in Denmark/Nordic that might have your interest: http://www.hl7.fi/wp-content/uploads/Nordic-Reference-Architecture-for-Pers… http://nordichealth2030.org.linux14.dandomainserver.dk/wp-content/uploads/2… https://www.nordicinnovation.org/2019/nordic-health-2030-magazine http://www.digitalhealthrevolution.fi/uploads/2/4/1/5/24155377/person_centr… Best, Jan

2 1

Draft minutes of UMA telecon 2020-07-30
by Eve Maler 30 Jul '20

30 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30 MinutesRoll call Quorum was not reached. Approve minutes - Approve minutes of UMA telecon 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> , 2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> , 2020-07-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23> Deferred. Around the horn: industry activities Access Now has been holding its RightsCon conference <https://www.rightscon.org/program/>. Tim spoke, and briefly mentioned UMA. It has relevance for the group's work. We could potentially speak on specific use cases in future in a formal fashion. Adrian has some updates on MyData activities <https://mydata.org/2020/07/29/press-release-mydata-operator-2020-status-awa…>. Sixteen vendors were accredited/anointed as "MyData operators" in its first round of such activities. This process is relevant to UMA in that it does not require standards. UMA implementations and interactive claims gathering New UMA implementation work: Scott mentions a new containerized UMA environment from ForgeRock known as frdp-containers-uma <http://repository that provides a Ready-2-Run environment for testing the User-Managed Access (UMA) Reference Implementation>, a "repository that provides a Ready-2-Run environment for testing the User-Managed Access (UMA) Reference Implementation". Michael will add an entry for the EmpowerID implementation of UMA to the Implementations page <https://kantarainitiative.org/confluence/display/uma/UMA+Implementations>. We are looking for information about implementations that support UMA interactive claims gathering. We now know of three: - Gluu - Identos FPX - EmpowerID Perhaps there is specific relevance to verifiable credentials in interactive claims gathering (as is SIOP; see the recent meetup <https://www.youtube.com/watch?v=ruF1s9jF6_w&feature=youtu.be>). But then also of pushed claims? UMA Grant doesn't define any canonical claim token formats; Sec 3.3.1 <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#uma-…> suggests one in an example but it's non-normative. Could a VC-friendly format be defined in a profile? Absolutely. Airside Mobile had gone in a profiling direction like this at some point but now have a JSON-LD-ish implementation. What about using PKCE with ICG? Alec will send his question to the list. AI: Eve and Maciej: Look into structuring the Implementations page more, using our old questionnaire. Turn it into a Google form or similar? Wallet → Relationship Manager profile This name might not stick for long, but it's mostly converted over in the new spec text <https://groups.google.com/g/kantara-initiative-uma-wg/c/vcB9S3mksn8>. This thing is a real client, to be used through whatever user agent is defined. There is a "policy API" that the AS presents, and a "manage API" that the RS presents. So far it's suggested that these be OAuth-protected. Should the policy API be UMA protected? Should the manage API be OIDC protected? Where we defined the UMA protection API in UMA FedAuthz, we said in Sec 1.3 <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0…> that OAuth is required for security protection of that API, but if identity context is required, OIDC is RECOMMENDED to get an ID token. That's one solution. Alec already has a placeholder for that kind of language just below. Is it necessary for us to prescribe a lot about user experience in the fashion of what Open Banking <https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guide…> has done? They have jurisdictional regulations and an industry context guiding them, and we have neither. This spec has no intention of standardizing anything about the interaction of an individual with the wallet/RM; rather, its purpose is to record policy through the policy API. (Etc.) Is the form of the policy extensible, or is it fully specified? The intent is for it to be the former. It could be a little similar to our claim_token_format approach, e.g. Attendees As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike) 1. Michael 2. Domenico 3. Peter 4. Gaurav 5. Eve Non-voting participants: - Tim - Adrian - Alec - Scott - Lisa - Alexander Mense *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-07-30
by Eve Maler 29 Jul '20

29 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30 Date and Time - *Alternate-week Thursdays 10am 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 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> , 2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> , 2020-07-23 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23> - Wallet profile - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2020-07-23
by Eve Maler 23 Jul '20

23 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> , 2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> Deferred. New profiles - Resource definition profile status - Wallet profile We should be driving towards revised spec text, ideally putting it into GitHub. Last week, folks concentrated on the ASCII "spiral" diagram and draft spec text. Alec has a new draft diagram to try on us. In the original UMA diagram, "manage" and "control" are out of scope. Alec is proposing that we bring these functions in scope. He states this explicitly by saying that he's specifying the "management and control interfaces". In UMA1 we used to call this Phase 1 vs. Phase 2. Now we think of this as the grant mechanism and the federated authorization mechanism, which is modular and optional with respect to grant. Is the wallet extension/profile modular and optional with respect to federated authorization? Alec illustrated it with a concentric Venn. Since "wallet" is such a fraught term, calling it something else, ideally descriptive, could help us get beyond the challenge that it means something really specific elsewhere. What about "relationship manager"? That goes back to our roots. Eve asks everyone to think about what could be a good name that would serve us, for now, in a spec. Maybe something around the fact that we are finally standardizing the user side of the management and control interface (ironic that we are finally doing something about deeply standardizing "user management of access", eh?). The cascading authorization server <https://confluence.hl7.org/download/attachments/66931686/Cascaded_Authoriza…> notion, which Pauldron implemented, bears some similarity to this idea. It has a "principal AS" within a specific domain, and a secondary AS that is RO-controlled. However, that original notion was intended to explicitly empower (in a sense) the AS against the RO's wishes, rather than to privacy-enhance the AS to protect the RO. FHIR meetup For those interested in HealthCare, Nancy provides this three-hour video from the FHIR meetup: [see wiki] She suggests checking out at least the first half-hour. It is important to understand the perspective of the HL7 security group as they will be moving this along in Healthcare as the recognized experts. She also points to this FHIR chat <https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy> (anyone can get a login). Nancy recommends that UMA's perspective be represented here. HEART came up, a little bit. Justin presented. Our webinar content could usefully be presented here. Here is info on the video structure (original here <https://docs.google.com/spreadsheets/d/15za6DXk0Cnn97CYWrZRw-1l14Hw3juKmG8b…> ): Overview of fine-grained authorization approaches in FHIR Josh Mandel 15min Slides here <https://docs.google.com/presentation/d/1ZGh-ls0VpRBpT_-Ei7rCd4D0HQv4rc-5k_l…> Access control in aidbox Nikolai Ryzhikov 15min Slides here <https://github.com/niquola/devdays-us-2020-slides/blob/gh-pages/README.md> XYZ Justin Richer 15min Slides here <https://www.dropbox.com/s/dr459qyy3t4l5yw/FHIR%20Days%20-%20XYZ.pdf?dl=0> An ABAC Architecture Approach Matthew Tyler 15min Yes, can't share yet Classification and Locality Chris Grenz 15min Slides here <https://docs.google.com/presentation/d/1dkznJa0KNPs299NDK73-QuuIIplqtzHJRJE…> FHIR Data Segmentation for Privacy IG Kathleen Connor 15min http://hl7.org/fhir/uv/security-label-ds4p/2020May/ Parameterized compartments Michael Hansen 15min Slides here <https://1drv.ms/p/s!AuADpL-pKlsYoQjmFJx2h9fDGk06?e=dWM6pC> *AI:* Nancy: Find out how we get onto the agenda of the next HL7 meetup or the next appropriate gathering. Adrian also suggests reaching out to Josh. Nancy suggests also John Moehrke, Kathleen, and Graham. We will, in the meantime, figure out the right content to present. Webinar report Alec reports pretty good attendance and some really good questions afterwards. Colin thought the content flowed well and was pitched just right. It was at the right technical level and had a relaxed tone. Nancy attended and thought it was great too. People can find the recording <https://kantarainitiative.org/download/uma-21st-century-health-information-…> on the Kantara site's Resources area (Adrian says Safari is a better browser than Firefox due to a bug that's being worked on). The FHIR folks could handle more technical detail than was provided. Attendees As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike) 1. Michael 2. Domenico 3. Sal 4. Thomas 5. Maciej 6. Eve Non-voting participants: - Colin - Alec - Nancy - George - Adrian - Anik - Lisa - Patrick - Bjorn *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 3

Agenda for UMA telecon 2020-07-23
by Eve Maler 22 Jul '20

22 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23 Date 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 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> , 2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> - Webinar report - New profiles - Resource definition profile - Wallet profile - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-07-16
by Alec L 15 Jul '20

15 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16> Date and Time Alternate-week Thursdays 10am 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 <http://kantarainitiative.org/confluence/display/uma/Calendar> Agenda Approve minutes of UMA telecon 2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09> New profiles Resource definition profile Wallet profile AOB Alec Laws 647 822 1529 alec(a)identos.ca

1 0