October 2018 - WG-UMA - mailman.kantarainitiative.org

"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

PPR Information Governance Label
by Adrian Gropper 12 Oct '18

12 Oct '18

A standardized label for apps and services that seek to use personal data would be beneficial to data subjects in the same way standardized nutrition labels are. They would not replace privacy policies but would complement them by reducing the opportunity to wordsmith and confuse. Benefits would accrue to platforms as well. App store operators could take the presence of a standardized label in consideration when ranking search results or otherwise labeling the apps. This would reduce their exposure in a case like Facebook / Cambridge Analytica. The relevance to UMA is clear with item 4, and somewhat with item 5. Overall, UMA is the best way I know of outsourcing GDPR. In healthcare, where HIPAA gives patients a clear right of access but allows data holders some discretion on labeling the clients of Requesting Parties, the label would be helpful. This initiative is designed around the PPR non-profit to avoid a lengthy standards process and because the key stakeholders in this case are consumers rather than institutions. I’m thinking in terms of FTC enforcement, copyright, and Creative Commons on the legal side. Comments, please! PPR Information Governance Label ▢ 1. No sharing: The data is never shared with any external entities. It is not even shared in de-identified form. ▢ 2. No aggregation: The data is never aggregated with other types of input or data from external sources. This includes mixing the data gathered via The Device¹ with other data, such as patient-reported outcomes. ▢ 3. Always voluntary self-identification: The user of The Service is able to choose their own identity, the user does not need to have their identity verified unless required by law. ▢ 4. Digital agent support: The user is able to specify a digital agent, trustee, or equivalent information manager, and this specified agent will not be subject to certification or censorship. ▢ 5. No vendor lock-in: This service is easily and conveniently substitutable, so the user can easily move their data to another vendor providing a similar service. This prevents vendor lock-in and is often accomplished using Open Standards. Indications for Use: The five separately self-asserted statements on the PPR Information Governance Label are subject to legal enforcement as would the privacy policy associated with The Service. Copyright © 2018, Patient Privacy Rights Foundation. Anyone may copy and redistribute unmodified copies of this work under the terms of the Create Commons CC-BY-ND-SA license, see link <https://creativecommons.org/licenses/> for full terms. —- 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/

1 0

Agenda for UMA telecon 2018-10-11
by Eve Maler 10 Oct '18

10 Oct '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-11 Date and Time - *Thursdays 9am 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 - Shift Oct 18 WG call a half-hour later? - Eve has a partial conflict - Prabath scheduled to do a demo of WSO2 implementation - 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> - Update on PIPC/captive insurance discussions - Update on interop testing activities - Consider publishing a draft business model tech doc - Discuss 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-04
by Eve Maler 04 Oct '18

04 Oct '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-10-04 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2018-09-20 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-09-20>: Deferred. Update on PIPC/captive insurance discussions if available Next week we plan to have a meeting, or maybe multiple meetings, related to PIPC. Vermont's AG is looking at a project involving a "regulatory sandbox" (was it called "FCA"?). Update on interop testing activities if available Prabath is able to join the *Oct 18* WG call to do a demonstration of the WSO2 UMA2 implementation. By then we should hopefully have a better idea of matrix tests and even some published blog posts from the various testers. Does the June 2019 Identiverse timeframe make sense for thinking about an interop event? Yes, likely. Eve and Andi can discuss offline. Colin also hears of additional vendor interest. Discuss Adrian's notification use cases - See last email in this thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/DpK9SmN2T…> Adrian's proposed use case text is reproduced below. This is all related to notifications. Let's discuss, analyze whether they're solvable with "UMA today", and if not, what the next steps are. *1 - Alice (RO) needs to be notified by the RS that the RS has ignored or modified an AS scope. (This is the Adrian Clause)* Another way to state this (more technically stated) is that the RS receives an RPT from the client (that the AS correctly issued), determines what resource IDs and scopes are associated with it, and then chooses to act in a way contrary to the scopes listed for a specific resource ID. (Either fewer scopes – more constrained – or more scopes – less constrained.) The latter is a sort of hard form of "break-the-glass", meaning that there was never an RO policy allowing that much scope. (We discussed this in the UMA Legal subgroup with a decision-tree approach on 2016-01-15 <https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not…> .) You can consider the knowledge of whether the access was given to be part of the equation of "Accounting of Disclosures". This topic is most often associated with healthcare security/privacy, but also has implications for other data protection regulations such as GDPR. The RS is exclusively in a position to know whether it gave access. However, it could inform the AS (and rely on the AS to tell the RO) vs. telling the RO directly. What are the timeliness requirements of this notification type? It doesn't seem strongly sensitive. What are the channels by which the RS could communicate its activity to the RO? - 1. The RS presents some app to the RO for managing resources; that app is outside the scope of UMA. (E.g., a photo service/app would have to develop its own notification functionality, or a patient portal would have to develop its own notification functionality, anytime the "Adrian clause" were invoked.) The RS app would be the one to produce notifications of RS behavior upon choosing the "anomalous case" regarding giving clients access after receiving an RPT, vs. the "normal case". For that matter, notifications/log entries could be produced anytime access were granted in the normal case too. Some implications: 1. Each RS app produces such notifications independently, rather than enabling centralization (aggregation?) of such notifications. 2. Each RS can guarantee that it has produced a notification of its own true behavior. 2. The AS (or the service presenting a standardized UMA protection API to RS's, that is, an AS interface) presents in addition some notification endpoint – which doesn't yet exist – to UMA RS's so that they can report details of their access-giving behavior to that endpoint. The intention is for that service to become the aggregated notification-producing service for the RO. Some implications: 1. The notifications now come from a single service, vs. potentially multiple independent apps. 2. Each RS now must rely on that central service to relay/make available the details of the access-giving behavior to the RO. Did the previous implementation that Maciej has demonstrated show an RO notification flow? *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)* To be continued. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Andi 3. Eve Non-voting participants: - Adrian - Colin Regrets: - Nancy - Maciej *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0