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

PKCE + Interactive Claims Gathering
by Alec L 27 Aug '20

27 Aug '20

Hi, We’ve had some requests to add PKCE [1] to the interactive claims gathering flow [2], eg example for public clients. Technically, there is little challenge to directly apply the PKCE code challenge/verifier, with the assumption that the authorization code is equivalent to the uma ticket Has anyone done this? Any additional considerations? Thanks, - Alec Alec Laws 647 822 1529 alec(a)identos.ca [1] PKCE: https://tools.ietf.org/html/rfc7636 <https://tools.ietf.org/html/rfc7636> [2] https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#clai… <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#clai…>

2 4

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

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

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

UMA Wallet first draft spec text
by Alec L 10 Jul '20

10 Jul '20

Hi, please find a first go at ’spec text’ for UMA wallet below Cheers, - Alec — # UMA Wallet ## 1. Introduction This document extends [UMA Fedz] in order to specify the management and control interfaces through the UMA Wallet. The UMA Wallet provides the end-user the consent management interface. It may be used across multiple ASs, where the user(RO/RqP) 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 | | requestinng | +---------- | owner | | party | | +------------------+ +------------ -----+ | | delegation | | +------------------+ | | | | +-----manage ---------- Wallet | | | +------+-----------+ | | | +-----------+ | | | | claims | | | | | gathering | | | | | API(OIDC)| | | | +-----------+ | | | ^ | | | | | | | | | 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 protected - Manage API The API presented by the RS to the Wallet. This API is OAuth protected ### 1.3 HTTP Usage, API Security, and Identity Context ## 2 Authorization Server Metadata ## 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, - register many identifiers against a public key ### 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 policy API allows the wallet to create policy at the AS on behalf of the resource owner. The policy API may allow the wallet to read available resources or policy types The wallet uses a RESTful API at the authorization server's policy endpoint to create, read, update, and delete policy, along with retrieving lists of such descriptions. ### 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.

3 6

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

09 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2020-06-11 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-11> , 2020-06-25 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-25> , 2020-07-02 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-02> MOTION: Andi moves: Approve minutes of UMA telecon 2020-06-11 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-11> , 2020-06-25 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-25> , 2020-07-02 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-02> . APPROVED by acclamation. New profiles - Resource definition profile status - Wallet profile Continuing with the flows and diagrams in Alec's recent email <https://groups.google.com/g/kantara-initiative-uma-wg/c/g9ajr1z9ZXQ> and spec text in his other recent email <https://groups.google.com/g/kantara-initiative-uma-wg/c/q2LoR7rjZhE> and his user stories in his other recent email <https://groups.google.com/g/kantara-initiative-uma-wg/c/f0g98sr22Rw>... *User stories:* "Decoupling the consent management UX from the authorization services" is the user story intending to support the wallet. Adrian suggests not using RS, RO, etc. because they are jargon that the rest of the world won't understand. He prefers PDP, PEP, etc. because these have been formally defined in RFCs. What about PAP for consent management/wallet functions? In the past, we have discussed how the XACML-type senses of PDP and PEP don't correspond exactly to AS and RS in the UMA sense because they don't fit neatly into the P*P categories. (It would be a good idea to number the user stories!) In their current implementation, there is a kind of pass-through of signed policies of Alice's in the token, so that the RS can ensure that they are the RO's even if the AS can't see them. In VC-talk, the AS is passing through VCs without verifying them and the RS is the verifier. If what is conveyed to the RS is a true policy, e.g. "Bob can access this resource with these scopes", then this is a privacy violation because it can do traffic analysis of information about Bob over time. We briefly discussed the clause in Sec 1.4 of UMA FedAuthz <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0…> nicknamed the "Adrian clause": "However, the resource server MAY apply additional authorization controls beyond those imposed by the authorization server. For example, even if an RPT provides sufficient permissions for a particular case, the resource server can choose to bar access based on its own criteria." Eve notes: There is a kind of ambiguity in the use of "RO" in the user stories in that it is (mostly?) about the use case of UMA-protected resources used for the purpose of satisfying the policy of some other RO. So the RO in this case is also someone else's RqP. This is akin to our original "UMA Trusted Claims" concept, illustrated here <https://kantarainitiative.org/confluence/display/uma/UMA+User+Experience>. Maybe RqP-as-RO? Also, watch out for the use of the word "consent". Patrick asks: Are we talking about a self-minted access grant, or a self-minted claim? If I grant access to you with no constraints, should the answer ever be no, or could the AS ever say no? The spec text includes a diagram with "delegation" in it, between RO and RqP. This extension is mostly RO-focused. Michael asks: What's in your wallet? [image: (smile)] Alec answers... It's a private-key management for Alice. It's credentials established by the AS to control an AS account, for PAT-type stuff. It's also an independent place where she can maintain a parallel record of the policy she's written. The functions are: Putting resources under management; write policy over those resources; and (?). In a way, a wallet is pretty much like an AS, but just closer to Alice. This is akin to the cascading AS concept. It can be a client type, or it can be an "cloud AS" with all the AS capabilities: a service endpoint that is always on. Nancy notes: It's an important time for healthcare. Please get engaged. She'll send info to the list. Eve and Maciej can't make next week's call. Alec is kindly willing to run it. Chairing coverage for next week tbs Attendees As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike) 1. Michael Amanfi (product architect of EmpowerID – workflow engine development) 2. Domenico 3. Sal 4. Andi 5. Maciej 6. Eve 7. Mike Non-voting participants: - Alec - Adrian - Patrick Parker (CEO of EmpowerID – works a lot on product design – big on authz! – his Identiverse talk is coming next Thursday) - Colin - Nancy *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0