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

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

Draft minutes of UMA telecon 2020-06-25
by Eve Maler 26 Jun '20

26 Jun '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-25 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> Deferred. Off-week meeting scheduling The winning time slot is alternate Thursdays (starting Jul 2) at 10am PT/12 noon CT/1pm ET etc. Eve will get the calendar stuff going. She will invite all of the voting participants and all of the additional participants who said they can make it at that time. Let Eve know if you'd additionally like an invitation vs. just subscribing to the calendar. Conformance test suite project This is a more formal project now, with a written proposal from Colin and a funding model. The project is happy to accept donations of resources of all sorts. Kantara webinar: looking for UMA participant Alec, Adrian, and Mike are willing to take part. Alec spoke first so he gets to determine the shape of our participation. [image: (smile)] Eve will put them in touch with Colin. New profiles - Resource definition profile status - Wallet profile We worked from the flows and diagrams in Alec's recent email <https://groups.google.com/g/kantara-initiative-uma-wg/c/g9ajr1z9ZXQ>. Alec has now added both Alice and Bob into the "new spiral" diagram. The RO delegates RS management to the wallet. The RqP now has a flow where they can release resources to the AS. The client is redirecting the RqP to the AS. Depending on how the delegation is managed, authorization can happen at the AS or at the wallet. Adrian asks: Because in his world (HIE of One) the wallet isn't necessarily online, what are the implications? The wallet in this control plane view needs to be online to write policy. So why have "choose wallet" as a dotted line and why not make this the default? Because their AS doesn't even have or need any claims gathering. This is Alec's challenge in generalizing what they've done to cover more use cases. We'll have to test the general-case design a bit. The setup text has some detail. It says "user" because it means either RO or RqP. The overlap with SSI is that there is personal key management. There are "furious conversations" currently about what it means to have an SDS wallet. Alice could have four choices for a wallet: 1. Wallet on smartphone, well secured 2. Custodial wallet, held by someone else with multi-signature capabilities 3. Cloud wallet of her own, built into an AS 4. No wallet, just a feature phone Thomas suggests describing control-pairs – "who controls what" – in each pair. (The "alt" boxes in the diagram are asynchronous setup stuff that either the RO or RqP could go through.) 1. AS starts claims gathering. ... 6. The wallet acts as a client to the RS. 9. The RqP themselves, not the wallet, logs in at the RS using a personal public key that they can sign JWTs with. They put resources under protection here. Thomas notes that the wallet becomes the control point for all the RS's and all the AS's. If someone wants to go offline for some period, they could potentially delegate a particular RS-AS pair for some resource to someone else to enable someone else to control it for them. This is very much akin to the business-legal "relationship management" model work we've done, with scenarios like having a data subject delegate control to one or more resource rights administrators. The responsibilities of the "community AS" are to keep the policies privacy-protected, and of the "personal AS" (which the wallet)... Attendees As of 23 Jun 2020, quorum is 5 of 9. (Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Thomas 3. Eve 4. Maciej 5. Mike Non-voting participants: - Alec - Anik - Adrian - Scott - Carlos - George - Tim *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Wallet extension, concept/flow
by Alec L 25 Jun '20

25 Jun '20

Hi all, Tried to show the concept + flows for the Wallet/SSI extensions - Alec ps, don’t think I can attach images. The diagrams are plantuml, can paste them into a site to render the image (ex https://www.planttext.com/) --- ## Wallet General concept: An AS can maintain the RS/Client decoupled pattern from first profile, but without see RO/RqP identity data or being able to track service use. (The AS doesn't support claims pushing/a pct, purely transactional) The AS delegates authentication and authorization/policy management to a user selected Wallet. The Wallet role allows a user to interoperate between using a RS (sources of data/issuer) in an UMA API world, or a direct VC presentation world. The verifier may still be decoupled from the issuer through trust in the AS Note, haven't really considered this half of the profile without general resource definitions ``` @startuml component "Authorization\nServer" as np component "Client" as consumer component "Resource\nServer (Issuer)" as provider component "Wallet" as wallet component "Verifier" as v wallet <-> np : Control np <-> consumer: UMA provider --> np : UMA\nintrospection provider --> wallet : issue provider --> consumer : Resource wallet --> v: present np <.. v: trust @enduml ``` ### Description of Flow: On claims gathering, the AS will forward the authorization request to a RqP selected wallet provider using OIDC The Wallet 'underwrites' a dynamic client registration for a RO/RqP. Any RO/RqP can have many clients at the AS The Wallet presents the authorization policy management ux to the User The Wallet collects connections to RS's and resources for the User (leads to issued VCs), and establishes resource owner credentials The Wallet creates User policy with the resource owner credentials, and writes it to the AS The Wallet responds the AS OIDC request with a token including the policy The AS issues an RPT based on the policy The RS uses the client credentials and policy to determine Users access ``` @startuml skinparam shadowing false autonumber actor "Requesting\nParty" as C participant "Authorization\nServer" as NP participant Wallet as W participant "Resource Server" as RS C -> NP: UMA: Claims Gathering (ticket [,wallet]) NP --> C: list of wallet C -> NP: select wallet NP -> W: OIDC Request (ticket/request details) C <--> W: Authenticate alt RqP Needs RS Connection W -> RS: OIDC Request C <--> RS: authenticate, authorize wallet for resource mngment RS --> W: access token, userinfo W <--> RS: resource owner credentials end C -> W: Approve permissions W -> W: Create policy using resource owner credentials W -> NP: record policy with User Token W --> NP: 302 Authorize Result IDToken{policy[]} NP --> C: 302 client, ticket C -> NP: /token (ticket) NP --> C: RPT C -> RS: /resource (RPT) RS <--> AS: introspection (RPT) RS -> RS: determine RO using client credentials RS -> C: RO resource @enduml ``` Alec Laws

1 1

Agenda for UMA telecon 2020-06-25
by Eve Maler 24 Jun '20

24 Jun '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-25 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&…> - 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> - Off-week meeting scheduling - Conformance test suite project - New profiles - Resource definition profile - Wallet profile - AOB *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Draft minutes of UMA telecon 2020-06-11
by Eve Maler 22 Jun '20

22 Jun '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-06-11 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> , 2020-04-30 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-30> , 2020-05-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-05-14> , 2020-05-28 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-05-28> MOTION: Sal moves: 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> , 2020-04-30 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-30> , 2020-05-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-05-14> , 2020-05-28 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-05-28>. APPROVED by acclamation. Profiling work - Resource definition profile spec status Alec has been looking at PAR for some inspiration and considering the access token vs. ticket question. Eve offered encouragement to publish a "drafty" draft with holes in it. People can suggest how to fill them in. Examples of old revs of IETF RFCs will show "TODO" items and such. Colin points to a Kantara Word template for specs <https://kantarainitiative.org/confluence/download/attachments/43876532/Repo…>, and can send a Markdown version to Alec as well. - Wallet profile Let's walk through the wallet-sequence.png diagram that is attached to the 2020-05-28 minutes. This puts UMA FedAuthz in scope a little bit. The Wallet is a new client type that is about, roughly, policy administration. It's a *third* client type, aside from the UMA Client and the UMA Resource Service, that both Alice and Bob would have one of. This diagram shows Bob using his Wallet. Eve showed our Legal Role Definitions slides <https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS…> and the spaghetti diagram, where the RqP has an interest in "permitting" the RO's AS to know their claims and "delegating" the authority to seek access to the client that they use. We recommend putting the RqP and the wallet next to each other in the diagram because the wallet is the RqP's choice. Alec has been advocating that the AS be a kind of community resource that both an RqP and a (potentially different, distinct) RO might share. Previously Alec had called the wallet component a "personal AS" and also an "agent". It turns out that using "personal AS" isn't as helpful as we thought because it seems to imply that the RqP role needs (or can specially benefit from) a different AS than the one that the RO uses. But Adrian's (and Alec's) advocacy for a sort of community AS shows that there is no special benefit here. Note that there might be a "Bob wallet" and an "Alice wallet" in any one deployment picture. This profile is intended to mitigate the privacy consideration risk that is identified in UMA Grant Sec 6.2 <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#rqp-…>, "Requesting Party Information at the Authorization Server". Alec saw that consideration and decided not to implement PCTs. That consideration is basically saying, "Do the right thing in the case of having to deal with IAM personal data risks." The alternative that this profile is intended to make possible is that the AS is able to persist only what an SSI verifier would need to persist in the case of handling VCs. Is that anything at all, or nothing? eIDAS has been listing, and Anil John has been working on, "universal verifiers". What does that mean? Conformance testing project update Eve was unfortunately too slammed to make progress on this! Scheduling and chairing help Should we consider going to a weekly schedule to make faster progress? Eve could use some help with running meetings. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Peter 2. Sal 3. Thomas 4. Maciej 5. Eve 6. Mike Non-voting participants: - George - Adrian - Anik - Alec - Nancy - Lisa - Colin *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Considering moving back to weekly, and possibly alternating times
by Eve Maler 17 Jun '20

17 Jun '20

We moved to a biweekly (fortnightly) schedule when our technical docket calmed down, but it has picked back up of late, and there's plenty to do. I asked last week, right at the end of the call, if there is interest in going back to a weekly schedule, and I discussed with Alec his interest in this. Any others? Assuming we do this, would it be practical to alternate meeting times? Alec mentioned that he's got a partial conflict on our current "off-weeks", so we should think hard about this. (We're currently in an "off-week" and next week is our "on-week".) *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 2

Agenda for UMA telecon 2020-06-11
by Eve Maler 11 Jun '20

11 Jun '20

...if we have the right folks available, let’s walk through the swimlane of the wallet profile and get the same detailed understanding of it that we now have of the resource definition profile. Let’s also get an update on profile spec’ing status. Sorry for the casual agenda style. :) Looking forward to talking tomorrow! Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0