- WG-UMA - mailman.kantarainitiative.org

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

UMA Wallet User Stories
by Alec L 08 Jul '20

08 Jul '20

Hi, some user stories for discussion Cheers, - Alec — As a RO, I want to manage my resources independently of each individual RS (UMA core prop) As an AS, I want to decouple the consent management UX from the authorization services, As a RO, I need a personally controlled user-agent (UMA Wallet) to manage my key material, in order to maintain personal-agency in ecosystems As a RO, I want to authorize a "UMA Wallet" to manage RS resources, so that I have a single view into my available RS's and Resources As a RS, I need Alice to authenticate in order to determine which resources she can manage, in order to ensure appropriate management access As a RS, I need Alice to establish credentials (pub key), so that I can trust externally asserted policy was issued with Alice AS a RS, I need to trust delegations signed by Alice's key, so that Alice can allow Bob (other keys...) or <<claims gathering condition>> to access her resources As a RS, I may delegate resource management user experience, so that I can focus of my core service to the RO As an RS, I need to know which AS(s) Alice wants to use, in order to delegate access control (uma core) As an AS, I want to delegate RqP identification to a UMA Wallet, so that - a RqP can choose their private key and consent management provider - I can avoid directly holding or seeing a users personal details As an AS, I want to allow the user to choose their consent management provider, so that I can

1 0

Agenda for UMA telecon 2020-07-09
by Eve Maler 08 Jul '20

08 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09>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-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> - New profiles - Resource definition profile - Wallet profile - Chairing coverage for next week - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

02 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-02 MinutesRoll call Quorum was not 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> Deferred. Identiverse authorization panel Eve and George are on an authorization panel to be aired on July 14, 10am MT. Here's the description for looking it up: Next-Gen Authorization Throwdown: It's Not Your Grandfather's OAuth Speakers: Daniel Fett, George Fletcher, Eve Maler, Justin Richer, Jake Feasel OAuth has seen several iterations over the last decade as the expert community has worked to solve difficult security, authorization, delegation, and consent challenges on behalf of both enterprises and end-users. We're now in "interesting times" as OAuth 2.0 is being stretched – some might argue to a breaking point – to cover new use cases. How should we enable fine-grained authorization? How similar should our handling of consent and authorization be? Can enterprise authorization and cross-domain authorization use the same model efficiently? Where do authentication inputs end and authorization decisions begin? And what about Alice? Join our panel of experts to hear their differing perspectives on OAuth innovation and how its next wave(s) of iteration must proceed for success Wallet profile We're continuing to analyze the swimlane that Alec sent out in email <https://groups.google.com/g/kantara-initiative-uma-wg/c/g9ajr1z9ZXQ>. The wallet client and the first alt box satisfies the part that is normally out of scope in UMA FedAuthz. Line 9, with resource owner credentials, posts private keys and gets a list of pseudonymous subjects that can be used for policy writing later. Remember that in this context the RqP that appears there is really the RO. So the RO is at their wallet. They are redirected to their RS, where they authenticate. The wallet gets an access token. The wallet thus functions as an OAuth client. Identos thought about making this a pure OAuth client but didn't go that far. RO policy is lines 11-14. Similar to the wallet-RO relationship, the wallet is a client to the AS, and the wallet uses lines 11-12 to register a public key. The RO is registered with an OAuth client-type relationship. In lines 13-14 it's really the RO using all of that key material and subjects and resource IDs to create policy at the AS. That could stay out of scope, but the AS is offering some kind of policy API. So these make the "manage" and "control" lines in the spiral-is diagram above into defined interfaces. What was the user agent that created the policies in the wallet? How was the wallet informed about what choices to offer the RO? In the Identos case, the AS has no interface, but it has a list of RS's and the resources available to that person through the resource definitions. This is the "out of scope but asynchronous policy management" part. Adrian notes that this is a terminology issue. Wallets hold private keys and hold credentials, and disclose them as appropriate. He doesn't see them as presenting policy interfaces. So can we pick a name that isn't anything they use, perhaps including "wallet" and "agent", and move on for now – and maybe inform that community of what we do on a periodic basis in case it contains good ideas? Maybe "UMA wallet" will be sufficient to distinguish it. Eve suggests "policy pocket". [image: (smile)] There are three delegation scenarios, the first two being new. 1. The RS offers delegation directly, a la the Google Docs Share button capability, after line 9. The use case here is a hospital custodian use case – the RO is the patient and they delegate to their doctor and the doctor authenticates as themselves. 2. The second place delegation can happen is directly from Alice to Bob, wallet to wallet. This is more of an impersonation case. An AS or RS couldn't audit or trace that this happened. The simplest way for this to work is to transfer a private key, and that's why Alec mentions impersonation, though some constraints could be imposed on the capabilities of the RqP (recipient of the key). But there are other possibilities, and that's where you could get into DIDs and VCs. It's then governed by the agent-to-agent world and its possibilities and constraints. 3. The third place this can happen, not marked on the diagram, is the stuff after line 14, is policy-based asynchronous access. That's the existing UMA-based delegation model. Next steps for everyone, with Alec starting it: Start a "user stories" email thread. A user story is in the form "As a <<role>>, I want <<outcome>>, so that I can <<benefit>>." Here are the really old user stories for UMA1 <https://kantarainitiative.org/confluence/display/uma/User+Stories>. Webinar work (if any discussion needed) Deferred. Conformance test suite project (if discussion needed) Deferred. Attendees As of 23 Jun 2020, quorum is 5 of 9. (Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Peter 3. Sal 4. Eve Non-voting participants: - Stephen - George - Gaurav (15 years in identity management, lots of products – heard about UMA and is aware of all the challenges – would like to help shape solutions) - Alec - Adrian - Bjorn - Colin - Anik *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2020-07-02
by Eve Maler 01 Jul '20

01 Jul '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-02 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-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> - Wallet profile - Webinar work (if any discussion needed) - Conformance test suite project (if discussion needed) - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Highly Recommended: SOIP Review is a must for our groups
by Adrian Gropper 29 Jun '20

29 Jun '20

and a model of how (Kantara) UMA and (OpenID) HEART will coexist with SSI. https://youtu.be/ruF1s9jF6_w - Adrian

1 0

UMA WG "off-week" meeting Doodle poll
by Eve Maler 28 Jun '20

28 Jun '20

https://doodle.com/poll/nv52yaryhet377en We're in an off-week now. Next week is our on-week. The week of Monday, June 29 is the first off-week in which I'm suggesting we *start* meeting, and I have also used that as our sample week for the poll. Please respond as soon as you can, and we'll figure out the best slot by the time our on-week meeting time rolls around. If you have any questions, let me know in this thread. Thanks! *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 3

Fwd: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
by Adrian Gropper 26 Jun '20

26 Jun '20

---------- Forwarded message --------- From: Wayne Chang <wyc(a)fastmail.fm> Date: Fri, Jun 26, 2020 at 12:18 PM Subject: Fwd: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) To: W3C Credentials CG <public-credentials(a)w3.org> jfyi ----- Original message ----- From: The IESG <iesg-secretary(a)ietf.org> To: IETF-Announce <ietf-announce(a)ietf.org> Cc: txauth(a)ietf.org Subject: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) Date: Friday, June 26, 2020 12:09 PM A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg(a)ietf.org) by 2020-07-06. Grant Negotiation and Authorization Protocol (gnap) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Yaron Sheffer <yaronf.ietf(a)gmail.com> Leif Johansson <leifj(a)sunet.se> Assigned Area Director: Roman Danyliw <rdd(a)cert.org> Security Area Directors: Benjamin Kaduk <kaduk(a)mit.edu> Roman Danyliw <rdd(a)cert.org> Mailing list: Address: txauth(a)ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/txauth Archive: https://mailarchive.ietf.org/arch/browse/txauth/ Group page: https://datatracker.ietf.org/group/gnap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ This group is chartered to develop a fine-grained delegation protocol for authorization and API access, as well as requesting and providing user identifiers and claims. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user’s browser, from the delegation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0, which is initiated by the client redirecting the user’s browser). The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process. The client and Authorization Server (AS) will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels. The group will define interoperability for this protocol between different parties, including - client and authorization server; - client and resource server; and - authorization server and resource server. The group will seek to minimize assumptions about the form of client applications, allowing for: - Fine-grained specification of access - Approval of AS attestation to identifiers and other identity claims - Approval of access to multiple resources and APIs in a single interaction - Support for multiple access tokens in a single request and response - Support for directed, audience-restricted access tokens - Separation between the party authorizing access and the party operating the client requesting access The group will define extension points for this protocol to allow for flexibility in areas including: - Cryptographic agility for keys, message signatures, and proof of possession - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process Additionally, the group will provide mechanisms for management of the protocol lifecycle including: - Discovery of the authorization server - Revocation of active tokens - Mechanisms for the AS and RS to communicate the access granted by an access token Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures - Conveyance mechanisms for identifiers and assertions - Guidelines for use of protocol extension points - (if needed) Guidelines on migration paths, implementation, and operations Where possible, the group will seek to make use of tools to guide and inform the standardization process including formal analysis, architecture documents, and use case documents. These artifacts will not be considered as working group milestones or deliverables. The working group will cooperate and coordinate with other IETF WGs such as OAUTH, and work with external organizations, such as the OpenID Foundation, as appropriate. Milestones: Jul 2021 - Core delegation protocol in WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, detached HTTP signatures, to WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, embedded HTTP signature, to WGLC Dec 2021 - Guidelines for use of protocol extension points to WGLC Feb 2022 - Guidelines on migration paths, implementation, and operations to WGLC -- Txauth mailing list Txauth(a)ietf.org https://www.ietf.org/mailman/listinfo/txauth

1 0