- WG-UMA - mailman.kantarainitiative.org

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

Draft minutes of UMA telecon 2020-05-28
by Eve Maler 28 May '20

28 May '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-05-28 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> Deferred. If someone has a question on the spec What should they do? They can ask on Twitter, if they're on Twitter. That's what we suggest on the FAQ <http://tinyurl.com/umafaq>. Eve has answered a number of questions there. They can also ask on GitHub. It's a standard category. In the past we added README, LICENSING, and CONTRIBUTION pages to be sure people are aware of the IPR implications of things like pull requests. We should be encouraging people to become participants if they want to get active in actually discussing the specs. Profiling work - Resource description profile status See Alec's flows and nascent profiling text. The resource registration API in his case isn't much used because of the "static" method of resource registration. The profile would probably want to spend a little time discussing static vs. dynamic registration (or however we want to describe this). In his use cases, it's mostly static, but maybe in more general usage, dynamic could end up being used more often. The text suggests that the type field is either required, or the RS has to POST against the AS-broadcasted type. Types come from "semantic APIs", meaning open APIs or their enterprise-standardized equivalent. An example might be FHIR R4. In other words, AS's don't standardize them themselves but they serve as a kind of community repository for them. The addition of resource_location is the key change here. It drives how the AS can tell the client where to go at the RS. It's suggested to be optional, because maybe all three parties "know" (are provisioned with the knowledge) beforehand, but this is the in-band way of doing it. Adrian has submitted a use case <https://github.com/agropper/secure-data-store/blob/master/COVID-19_Health_R…> and sequence diagram related to this type of scenario to the DIF Secure Data Storage group <https://identity.foundation/working-groups/secure-data-storage.html>, which is trying to achieve something similar. This profile's concept of the ticket is that it is a "capability ticket", and it's believed that it doesn't have to be rotated for security; it can be reused. This makes it not like a nonce but more like an access token. It's literally a capability, in other words. Should an access token actually be used instead? Hmm. It would need something like "profile" scope. - Wallet profile options See the two attachments to these minutes. The wallet-component.png attachment <https://kantarainitiative.org/confluence/download/attachments/129565246/wal…> shows a kind of blending of SSI and UMA worlds in our "spiral". The wallet-sequence.png attachment <https://kantarainitiative.org/confluence/download/attachments/129565246/wal…> shows a swimlane. But there are some questions. Where are Alice and Bob? What is the verifier role – is it used in the typical case? Adrian's use case document linked above starts to illustrate a similar blending. The intersection point is where each actor gets to choose (and change, if they want) their AS. We have, in the past, looked at "cascading authorization servers" (see issue #260 <https://github.com/KantaraInitiative/wg-uma/issues/260>, proposed by the VA – though it wasn't strictly intended to empower patients). This profile is intended to enable more choice. Adrian's use case has a notion of a trusted community server that can be overridden by the personal AS. Conformance testing project update Involved folks should plan to meet next week, our off-week from the biweekly WG meeting. AdvCIS update Sal will share with the group about UMA Soup. [image: (smile)] Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Sal 2. Domenico 3. Maciej 4. Eve 5. Mike Non-voting participants: - Scott - Andi - Alec - Adrian - Tim - Anik *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Resource Definitions profile
by Alec L 28 May '20

28 May '20

Hi, To start on the Resource Definitions profile, I've listed changes against the UMA specs. Cheers, - Alec --- # UMA Resource Definitions ## 1. Introduction This document specifies a profile of UMA Grant and UMA Fedz in order to support Resource Server discovery through AS first flows Client flows. This is enabled by general resource definitions by the Authorization Server. # Profile UMA Grant ### 1.3 Abstract Flow ``` participant "client" as client participant "authorization server" as as client -> as: Permission ticket request (PAT) as --> client: response with permission ticket ... client -> as: RPT request with permission ticket as -> as: authz assessment as --> client: Response with RPT and resource_location client -> rs: resource_location with RPT rs --> client: Protected resource ``` #### 1.3.1 Authorization Process "interactive claims gathering with an end-user requesting party" - allows the RqP to dynamically select the RS to fulfill "claims pushing" - only works if the RqP had previously setup some policy with the AS ## 2. Authorization Server Metadata uma_profiles_supported REQUIRED Include the uri to this profile #### 3.3.5 Authorization Server Response to Client on Authorization Success This endpoint can stay unchanged given - the client requested one resource or - the client requested multiple resources The authorization server MUST add the following parameters to its response: resource_location REQUIRED The uri registered by the RS during it's resource declaration OR the - another option is the RPT is a JWT and the `aud` is the resource_location? *EXTENSION TERRITORY:* If the client requested multiple resources, ideally the user can fulfill each one with a different specific RS AND the client can still be issued RS-constrained RPTs Options: - issue a PCT and let the client requests constrained access token by including a resource indicator in the request - pack the access token JWT with constrained RPTs. Allows token endpoint to conform, but additional client processing of the response (already happening for the resource_location) # Profile UMA Fedz This profile allows the AS to maintain general resource definitions that: - an RS subscribes to fulfill - an Client requests permission to ### 1.3 HTTP Usage, API Security, and Identity Context - RS has a PAT through client credentials, not associated with any user. The RS can declare supported general resources this way ### 3.2.1 Create Resource Description - type is REQUIRED and must match one of the AS resources OR - the RS POST against the AS resource path `as_rreg/_id` The RS MAY include an additional parameter: resource_location OPTIONAL The path at the RS that supports this resource type #### 3.2.5 List Resource Descriptions alt: - without the PAT, the AS returns it's resource ids - AS has a second path for it's general resource types - types are defined at an external service ## 4. Permission Endpoint The permission endpoint is opened to the client to call directly. The client has a PAT using client credentials, same as the RS - could also introduce a new scope uma_client, uma_permission ### 4.1 Resource Server (*Client*) Request to Permission Endpoint The client uses the resource_id's and resource_scopes listed at the AS's open resource endpoint ### 4.2 Authorization Server Response to Resource Server (*Client*) on Permission Request Success The ticket MAY be reused by the client. Maybe not necessary, but convenient? ### 4.3 Authorization Server Response to Resource Server (*Client*) on Permission Request Failure In addition to existing error_code, the AS may prevent specific clients from access to existing resources and scope - request_denied?

1 0

Agenda for UMA telecon 2020-05-28
by Eve Maler 27 May '20

27 May '20

1 0

Draft minutes of UMA telecon 2020-05-14
by Eve Maler 14 May '20

14 May '20

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-05-14 MinutesRoll call Quorum was not 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> Deferred. Profiling (and turning it into projects) We're ready in the case of the resource description profile, at least, to start truly writing a spec profile in the WG. The preference among people in the group is to use markdown (vs. what we used to use, XML) to write this stuff in. OIDF uses markdown and a tool <https://github.com/mmarkdown/mmark> that automatically converts it to RFC format – possibly customized to get OIDF formatting. Let's try and use that tool – possibly (further?) customized to get Kantara formatting. Alec is willing to be the editor. (Here are other tools <https://www.rfc-editor.org/pubprocess/tools/> and more advice <https://github.com/danyork/writing-internet-drafts-in-markdown>.) It would be valuable for us to produce additional specs that may contain non-normative text as well. While this is broader than profiling, it would expose existing valuable content in a form that would widen its audience. Examples include the resource description profile use cases we discussed last week <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-04-30>, the UMA Implementer's Guide <https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gu…> material (which is akin to OIDC implementer's guide material though not identical), and even our voluminous UMA use case <https://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+…> and case study <https://kantarainitiative.org/confluence/display/uma/Case+Studies>material on our wiki. With regards to the consent management work currently going on, there is a GDPR receipt profile that is underway on the consent receipt in the consent and notice project group, Andrew is also working on a framework for ISO. And at OpenConsent Joss is on the Advisory Board and they are tracking MyData. On the SSI front Mark L is working with others on a distributed ledger consent specification, which came out of the Hyperledger effort. Do we also have an opportunity to write a claim profile, or similar, to ensure interoperability of getting a requesting party claim in the form of a verifiable credential? Adrian has talked about the need to pass a "request triplet". His HIE of One Trustee implementation integrates uPort identities from the "Bob" side. IDENTOS also uses UMA to fill some of the holes in the SSI technical protocols where human trust comes in. It can bridge all the diverse technical implementations. What's the best way for us to try and write such a profile? Inspect the code, quiz Michael Chen...? That project is currently working to put together a new fork and better documentation. We could achieve a lot of value by writing a profile where a VC functions as an authorization token. It is sort of a powerful kind of "PAR" (pushed authorization request) and we might even be able to go AS-first. UMA represents a viable solution to "dashboards" and MyData operators. So if we can provide legitimate specs illustrating solutions that integrate well with other pieces of the ecosystem, we anticipate it will be adopted. Conformance testing project update We are currently gathering offers of financial and development resource donations towards this effort, which would result in a test harness for self-certified conformance somewhat similar to others we're familiar with. It would test AS conformance first. The intent is to secure a dedicated consulting resource so we can do this development timely. Attendees As of 17 Feb 2020, quorum is 5 of 8. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike) 1. Domenico 2. Eve 3. Sal 4. Mike Non-voting participants: - Alec - George - Stephen Payne (solution architect for ForgeRock, focusing on healthcare in west, central, Rocky Mtn) - Colin - Anik - Lisa - Adrian - Tim Regrets: - Nancy - Scott *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Agenda for UMA telecon 2020-05-14
by Eve Maler 14 May '20

14 May '20

Hey everybody, we do have a WG call tomorrow: we’ll discuss profiles and do a conformance test project update. I’ve been on PTO today; apologies for this informal agenda. Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0