- WG-UMA - mailman.kantarainitiative.org

Draft minutes of UMA telecon 2018-11-02
by Eve Maler 02 Nov '18

02 Nov '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-02 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2018-10-18 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18> Deferred. Discuss extensions added to implementations or desired in more depth Pushing claims from the RS to the AS during the permission request: Keycloak does this <https://www.keycloak.org/docs/latest/authorization_services/index.html#_ser…> (using the actual UMA claim_token parameter). The use case is for when the "RS is the RO". The Keycloak likes the UMA permission ticket model because it "separates the RS from the client" and enables a human user to set sharing preferences, so this is why Pedro calls it "not the typical UMA use case". What does the RS know that the client can't provide? What is an example of the claims it passes? The RS might want to send the company that the user belongs to, or any run-time information related to the current request for the resource. A classic example: If the client is talking to the RS via MTLS, you can send the CLN of the client cert or the cert itself. Then you can ensure the permission ticket is given only to the client that deserves it. The RS can push any information to the AS for evaluation that could free the RS from doing that job. In the past, we've also talked about the client's apparent IP address when it shows up at the RS; this is one input signal that the RS could convey to the AS as part of eventual policy evaluation, which could be combined with a similar signal that the AS could detect when the (same?) client shows up at the token endpoint. The source of claims could be anything. Keycloak provides a Claims Information Point <https://www.keycloak.org/docs/latest/authorization_services/index.html#_enf…> that could serve as a source. The client isn't allowed to push claims to the RS at the point of requesting a resource, though of course whatever was part of the API call the client made could be used by the RS as "fodder" in pushing information ("claims") to the AS in the permission request. Another use case could be for when you need a specific fine-grained value constraint, akin to what Open Banking needs in order to arrange for a payment of exactly 60 pounds (rather than enabling authorization of "payment scope" generically for some app). If you're stuck using only the OpenID Connect spec as already written, then this is why OB hunted around and leveraged the request object. Peter notes that fine-grained authorization (scopes?) would be of interest. The primary use case is a document (may not be verified by third parties) for which temporary access needs to be granted to third parties. Customs/border control needs access for a span one hour prior ↔ one hour after my arrival. This is the "expiring entitlements" use case. They're using consent receipts in a manner not originally intended, involving negotiation. He's engaging with the CIS WG on this, such that the receipts can reflect the resource owner is the offerer of access. See this blog post <https://idimmusings.com/2018/10/31/kantara-initiative-work-groups-on-data-s…> and this mind map <https://share.mindmanager.com/#publish/Dy37bDd3dLe-sNUuxjHMDffKegAzJCB9wByD…>. (The two WGs were hoping to do joint work on this – maybe we can get back to that in 2019. The UMA business model should be able to support this.) Pedro notes that Keycloak supports claim tokens that are ID tokens, and also bearer access tokens. The HIE of One/Trustee implementation supports uPort claim tokens. It seems there is some support for bringing some of these topics to IETF, which means engaging in a more sustained way there. Let's discuss more next time. 180 degrees use case / decoupled use case discussion Deferred. Attendees As of 18 Oct 2018, quorum is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Peter 3. Sal 4. Andi 5. Maciej 6. Eve 7. Mike Non-voting participants: - Alec - George - Nancy - Pedro - Thomas - Colin - Bjorn Regrets: - Cigdem *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

A reminder: we meet tomorrow, not today
by Eve Maler 01 Nov '18

01 Nov '18

Agenda coming (sorry about the delay — I’m on the road — but dial-in info is the same as usual, as listed on our home page and calendar). We’ll discuss the various extensions and extension desiderata being seen in implementations. Eve Maler (sent from my iPad) | cell +1 425 345 6756

2 2

Agenda for UMA telecon 2018-11-02 (Friday meeting!) (we are in "summertime skew"!)
by Eve Maler 01 Nov '18

01 Nov '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-11-02 *NOTE:* The EU has changed clocks but US hasn't! So this time will be "off" if you are in the UK or Europe but "normal" if you are in the US. I'm sorry about that. Please check the calendar link if you are in any doubt. Date and Time - *Thursdays 9am PT – special day this week FRIDAY (same time as usual)* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2018-10-18 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18> - Discuss extensions added to implementations or desired in more depth - Discuss Keycloak extension re claims added to permission request with Pedro - 180 degrees use case / decoupled use case discussion - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

"180 degrees" use cases
by Eve Maler 24 Oct '18

24 Oct '18

Nancy shared with me her "180 degrees" use cases writeup for distribution; it's attached. This connects to our discussion of last week <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18> . (Just a reminder that we're not meeting tomorrow because of IIW, and that our meeting next week, normally scheduled for Thursday, has been shifted <https://kantarainitiative.org/confluence/display/uma/Calendar> to Friday Nov 2. If anyone wants to be added to the calendar invite on a one-time or ongoing basis, or to the Skype chat group, let me know.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New article from Justin on post-OAuth2
by Eve Maler 24 Oct '18

24 Oct '18

https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade This is an important read. Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

2 2

RqP presenting W3C Verifiable Credentials to an UMA Authorization Server
by Adrian Gropper 21 Oct '18

21 Oct '18

I'm cross posting this for the obvious reason and will try to act as relay if a discussion ensues. On today’s UMA standards call, the following came up: 180 degrees use case / decoupled use case discussion Nancy has written up some "180 degrees" use cases, which she'll share more widely soon. These got Eve thinking. We briefly discussed use cases where the requesting party needs to trust the resource owner before taking some action (potentially against resources shared), e.g. a loan officer needing to trust that the putative resource owner is who they say they are so that the (e.g.) personal attributes (resource) shared can be trusted to be associated with that resource owner "bearer". This way, the loan officer can approve a loan (which might be a second resource that the same resource owner could later share with others). The current UMA model allows the RO and their AS to match RqP claims (not just a plain authenticated identity) against policy, and the RO can be decoupled (asynchronous) from that process. The client that the RqP uses is explicitly accounted for in the protocol, and UMA has a framework for this matching and for the RO's delegation / access granting to the RqP. But it only accounts for the client that the RO uses to interact with the RS and AS through the OAuth authorization endpoint (resulting in a PAT), and otherwise the client handling on the RO side is implicit. The notion of the RqP needing to trust the RO and the RO needing to grant resource access to the RqP seems similar to the "decoupled" use cases, where a CSR or bank teller needs to know that Alice is really Alice before getting access to her account. What would make sense for ensuring that the RqP could come to trust the RO "binding"? Alec will describe some work they've done along these lines in our next meeting. For the UMA folks, check out Figure 2 at https://www.w3.org/TR/verifiable-claims-data-model/ to get oriented. For the VC folks, check out https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0… by way of orientation. Our HIE of One Trustee implementation would not be practical without _both_ UMA authorization and self-sovereign identifier standards. Federation in healthcare is not deployed widely enough to serve a patient-centric health record application. I hope this email inspires our group’s to harmonize or at least to produce a brief paper describing why or why not. Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

3 7

Draft minutes of UMA telecon 2018-10-18
by Eve Maler 18 Oct '18

18 Oct '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18 MinutesRoll call Quorum was reached. Approve minutes - Approve minutes of UMA telecon 2018-09-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20>, UMA telecon 2018-10-04 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-04>, UMA telecon 2018-10-11 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-11>: APPROVED. Prabath demo of new WSO2 implementation of UMA2 (View the recording <https://kantarainitiative.org/confluence/download/attachments/104598460/201…> of this meeting from this point onward.) WSO2 Identity Server 5.7.0 was released last week. They had implemented UMA1 but that didn't really take off. They have implemented dynamic client registration, the resource registration API/endpoint, the permission endpoint, the token introspection endpoint, the token endpoint, and resource access policies implemented in XACML (internal to the engine). On the roadmap for 5.9.0 (Q1/Q2) is interactive claims gathering, SAML as a claim token (just ID token now), the UMA metadata endpoint, updates to the user portal to give an end-user UI (right now their customers build their own UI; the updates would include end-user analytics for resource access by RqPs), notifications on approved RPTs, and integration with the WSO2 API Manager RS gateway. The demo use case involves Kaiser as an RS, a Medicare client app, Tom as an RO, and John as an RqP. John logs in using OIDC. Some feedback from WSO2: Steps 7-9 in blue (the C-to-RS-first and permission ticket) are considered onerous. Keycloak also did something similar in an extension of theirs, though in their case it seemed the motivation was more about colocated AS/RS/RO (an "enterprise RO"). WSO2 anticipates this would be the most common case, but they're planning for other cases like patient/doctor, where they would typically have multiple Identity Servers in the control plane in multiple trust domains. *AI:* Prabath: Document the service-to-service use cases where C-to-AS-first UMA would make sense. E.g., a Kubernetes environment, potentially microservices chaining, etc. Schedule change-up In addition to not meeting next week due to IIW, let's move our next meeting from Thu Nov 1 to Fri Nov 2, same bat time. We will discuss the C-to-AS-first pattern. We will try and get an Identos demo of sorts, and a discussion of all the "C-to-AS-first" solutions/extensions out there, along with use cases for the solution. *AI:* Eve: Change the calendar and try to get Pedro to join the call as well. 180 degrees use case / decoupled use case discussion Nancy has written up some "180 degrees" use cases, which she'll share more widely soon. These got Eve thinking. We briefly discussed use cases where the requesting party needs to trust the resource owner before taking some action (potentially against resources shared), e.g. a loan officer needing to trust that the putative resource owner is who they say they are so that the (e.g.) personal attributes (resource) shared can be trusted to be associated with that resource owner "bearer". This way, the loan officer can approve a loan (which might be a second resource that the same resource owner could later share with others). The current UMA model allows the RO and their AS to match RqP claims (not just a plain authenticated identity) against policy, and the RO can be decoupled (asynchronous) from that process. The client that the RqP uses is explicitly accounted for in the protocol, and UMA has a framework for this matching and for the RO's delegation / access granting to the RqP. But it only accounts for the client that the RO uses to interact with the RS and AS through the OAuth authorization endpoint (resulting in a PAT), and otherwise the client handling on the RO side is implicit. The notion of the RqP needing to trust the RO and the RO needing to grant resource access to the RqP seems similar to the "decoupled" use cases, where a CSR or bank teller needs to know that Alice is really Alice before getting access to her account. What would make sense for ensuring that the RqP could come to trust the RO "binding"? Alec will describe some work they've done along these lines in our next meeting. Update on PIPC Deferred. Continue on Adrian's notification use cases Notification came up in WSO2's work, which may be relevant to both Adrian's use cases and the needs for notification/polling seen in the decoupled use cases. To be pursued more shortly. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Andi 4. Maciej 5. Eve Non-voting participants: - Alec - Identos - Using UMA a lot to solve patient-facing services; read the spec many times [image: (smile)] – has many pilots going in Canada and responding to lots of RFPs, including Ministry of Government Services - within six months will have a public version - Bjorn - Peter - Prabath - David - Dewni Regrets: - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Great new article on UMA and the Pensions Dashboard
by Eve Maler 18 Oct '18

18 Oct '18

https://www.professionaladviser.com/professional-adviser/feature/3063383/pe… This may possibly be the best explainer I've seen. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Agenda for UMA telecon 2018-10-18 (calls starts/ends a half-hour later than usual)
by Eve Maler 17 Oct '18

17 Oct '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-18 Date and Time - *Thursdays 9am PT – special time this week 9:30-10:30am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2018-09-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20>, UMA telecon 2018-10-04 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-04>, UMA telecon 2018-10-11 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-11> - Prabath demo of new WSO2 implementation of UMA2 - 180 degrees use case / decoupled use case discussion - Update on PIPC - Continue on Adrian's notification use cases - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-10-11
by Eve Maler 12 Oct '18

12 Oct '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-11 MinutesRoll call Quorum was not reached. Shift Oct 18 WG call a half-hour later? Let's shift the call, and plan to record the demo, at least. *AI:* Eve: Move the Oct 18 call a half-hour later, and cancel the Oct 25 call due to IIW. (DONE) Preparing for IIW George is attending IIW and is giving his UMA 101 talk. Eve will provide the UMA2 masterclass slides from Identiverse in case those are helpful. Also see the Legal Role slide deck for the Origo Pensions Dashboard (step 1 and step 2) use case, which is advanced POC stage now, and they're looking to deploy pretty soon. *AI:* Eve: Send Identiverse UMA2 masterclass slides to George. (DONE) As a reminder, the masterclass slide PDF and video are linked from the UMA wiki home page <https://kantarainitiative.org/confluence/display/uma/Home>. Adrian and Bjorn are also attending. Adrian will be showing the latest version of his patient-centered health record work, which is built around UMA. They have been making progress at Emory Healthcare in Atlanta. Medicare also exposes an OAuth-protected endpoint based on FHIR. The discussion has been around the privacy and security implications of just registering a client app as OAuth-enabled, not UMA-enabled. This implementation is also using uPort credentials and OIDC. The UMA AS can handle requesting party identities (claims to satisfy policy conditions) of either sort. One requires standing up an OIDC IdP and the other doesn't. Will enough UMA2 implementers be at IIW that a session to discuss matrix interop testing done to date and plans for the future make sense? Food for thought. Approve minutes Approve minutes of UMA telecon 2018-09-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20> and UMA telecon 2018-10-04 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-04>: Deferred. Update on PIPC/captive insurance discussions Healthcare and "insure-tech" both would potentially benefit from UMA as a framework for PIPC. The Vermont AG is interested in applications and solutions to concretize the law. The new docs we've been talking about today would be useful for a meeting with him, so he's in the audience. Eve is free for such meetings in the next couple of weeks. Update on interop testing activities Would Trustee (the new name for HIE of One) like to take part in the pairwise interop testing? For starters, Adrian or Michael could get in touch with Mike Schwartz or Will Lowe at Gluu. Or if there is a wiki page with instructions, that may be best. The next thing we need is a canonical set of tests. Consider publishing a draft business model tech doc Could we just produce the slides as a PDF or something? It certainly seems possible to do that, but maybe "additional words" would be helpful for the right audiences to understand. And a simpler version for newbies would probably be helpful, breaking things down – maybe a single worked example. Then we could add a new report with the multiple use cases, building on the draft technical spec as a basis. Conveying benefits is always the top challenge in these materials. And it seems there are many subtle disincentives in various healthcare ecosystems that discourage adoption. One advantage in the healthcare sector is the presence of an open API, FHIR. Increasingly, financial services is gaining a similar advantage with open APIs. Discuss Adrian's notification use cases Deferred. Continuing... More to say about the following use cases? *2 - Alice (RO) needs to be notified by the RS that the Client presented to the RS is deemed inadequate for automated registration and Alice herself, not Alice’s AS, must acknowledge the warning by the RS in order for the Client access to proceed. (This is the current interpretation of HIPAA for patient-directed exchange)* This notification type has strong timeliness requirements. *3 - Alice (RO) needs to be notified by the AS that a RqP has presented with a query for registered resources. (This is where someone other than Alice invites the RqP to access her resources without specifying a particular resource).* See 38:00 in the Google TechTalk video <https://www.youtube.com/watch?v=91RUONg6po4> for a demo of this from way back. We have additional implementations, probably with a variety of approaches: API endpoints, web hooks, etc. We may want to compare approaches and see if there's any motivation to standardize for interop. *4 - An RS or an RqP wants to notify Alice of something but they only have the service endpoint of Alice’s AS. (Alice is using the AS as a blind drop the way she might use a dating app)* Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Maciej 3. Eve Non-voting participants: - David - Bjorn - George - Nancy - Adrian Regrets: - Andi - Cigdem *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0