- WG-UMA - mailman.kantarainitiative.org

Indian Consent Tech Framework
by Adrian Gropper 08 Jul '18

08 Jul '18

See attached. I'm involved in various (health) data infrastructure policy groups for India. I consistently try to steer them in the direction of UMA. This document is referenced in relation to India Stack and National Health Stack for India. There's a lot going on and it seems to be moving quite quickly. I'm looking for allies and help with comments as might come up. -- Adrian

1 0

No meeting tomorrow (Jun 21) / leadership team elections
by Eve Maler 20 Jun '18

20 Jun '18

Let's not meet tomorrow after all. Key folks are too busy with Identiverse prep and travel, and our agenda is a little too short to justify going ahead with it. So we won't meet again until *Jul 12*. The online calendar is here <https://kantarainitiative.org/confluence/display/uma/Calendar> for your reference. I'd like to remind voting participants that our *Chair and Vice-Chair positions are coming due for re-election*; currently these positions are filled by me and Maciej, respectively. You can see the entire leadership team roster here <https://kantarainitiative.org/confluence/display/uma/Leadership+Team>. If you'd like to put in nominations, please send them to me ahead of time -- or you can bring them up on the call if you like -- and we'll be holding elections on the 12th (assuming we're quorate). Let me know if you have any questions. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Lighter UMA Work Group meeting schedule for the summer
by Eve Maler 19 Jun '18

19 Jun '18

As mentioned in last week's meeting, we are not meeting on June 28 (just after Identiverse) or July 5 (just after the US Independence Day holiday). We are meeting June 12. After that, I have removed meetings every other week from the calendar through August 30. Enjoy! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-06-14
by Eve Maler 14 Jun '18

14 Jun '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-14 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-06-07 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-07>: APPROVED by unanimous consent. Michigan Health Information Exchange The Michigan HIE had a connectathon with a use case that was very UMA-like. A patient who has just reached the age of 18 is able to share info with another app or whoever she wants, using her right of access. The use case involves using filters and labels so that HPV information doesn't reach her parents. It's a healthcare + education use case. Upcoming meeting planning - Meet Jun 28 right after Identiverse? - No meeting July 5 - Should we reduce the meeting schedule over July/August? - Who might attend a Kantara plenary on Fri Oct 26 (just after IIW)? Potential cross-group agenda items (e.g. IRMWG, CISWG, CMWG...)? No meeting Jun 28, no meeting Jul 5, chop out some meetings in Jul and Aug. Who might be available for a Kantara plenary? Chris Blanton from Gluu, Adrian, Eve, possibly Maciej. Adrian has tried to bring the SSI and Kantara communities together. Gluu has demonstrated that a "SSI claim" can be used to satisfy policy, and IIW itself can be used for discussing combining UMA and SSI to the extent that this is of interest, or if there are challenges that are arising. On the other hand, there are potentially opportunities not yet being exploited. Other cross-group agenda items Eve had thought of were along the lines of the "cradle-to-grave scenarios" and solving them with suitable application of IRM workflows and throwing off receipts, but we haven't gotten any farther than that. UMA and Decentralized Identity Foundation Adrian has been advocating for UMA being a component of DIF <http://identity.foundation/>'s "hub" role. Kim Cameron spoke on this at EIC18. Let's start to take a look at what this might mean over the summer. Decoupled flow Deferred. Enterprise use cases/Gluu Gateway Mike showed a demo; find it here <https://github.com/GluuFederation/gluu-gateway/tree/master/gg-demo>. It uses Kong underneath. Question: Kathleen: Can it handle scopes like HEART has? The Gluu take is that scopes map to policies on the Gluu Server. An UMA scope might be something like "OutSideUS", and the policy is a Python script. The policy provides context: Who is the subject? What is the client? It could call an external RBAC or XACML PDP. The gateway (proxy) is really simple; it's the PEP; it doesn't know anything about that. (See the documentation <https://gluu.org/docs/gg/>.) It introspects the token and caches the results. So if an API comes with whatever scope design, can it handle that and map to policy as necessary? Yes. You can switch from "UMA Resources" (settings for resources with their scopes) to "OAuth Scope Security". Mike is seeing a lot of consumer use cases for the gateway these days, and use with microservices. What is the business case? - Proxy for APIs for internal and external services that are containerized - Centrally enforce access - Rate limiting for DoS protection, billing, etc. UMA2 masterclass materials Eve walked through the draft slides for the masterclass she and Mike are doing at Identiverse. The "federated authorization" language is challenging to people, so it's now "externalized" authorization. People will review the deck more before Monday. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Maciej 3. Eve 4. Mike Non-voting participants: - Scott - Bjorn - Kathleen - Adrian - Tim - Nancy Regrets: - Andi - Cigdem *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Who is responsible for Client Registration?
by Adrian Gropper 14 Jun '18

14 Jun '18

Folks, This issue has come up as I am looking into issues raised by the recently announced API access to individual's Medicare records: https://bluebutton.cms.gov/developers/#production-api-access To frame the issue, under current US law, the patient has an unrestricted right to directed access (patient can specify any address for the record to be sent to directly) to their own data, at least when the access is via paper or fax. The question is how will patient-directed access work on top of a FHIR API. For example, the policy for registering an OAuth client to the production Open.Epic FHIR API, is accessible to anyone willing to assume the role of "developer" and holding a valid credit card. The Client registration process is tedious and takes up to 24 hours, but otherwise unrestricted. The process for registering a client to the Medicare production API (link above) is considerably more tedious and expensive. It involves a claim that you're a US corporation, a link to a privacy policy, a telephone conference, and up to two weeks delay. Which brings up my UMA question: Who is responsible for RqP's (Bob) Client Registration (OAuth or UMA)? (1) Is it the patient, because under patient-directed access the patient takes all responsibility for Bob's actions? (2) Is it Bob, because he is presumed to have the responsibility for his own Client and patient Alice has no real way to know much about Bob's client? (3) The Resource Server is responsible but highly constrained in its actions by HIPAA and the API Task Force that say that patient-directed Client access can be denied only in the case of security violations like a DoS attack? What is the current situation with or without Dynamic Client Registration in OAuth and UMA? 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/

2 2

Agenda for UMA telecon 2018-06-14
by Eve Maler 13 Jun '18

13 Jun '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-14 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 - Approve minutes: Approve minutes of UMA telecon 2018-06-07 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-07> - Upcoming meeting planning - Meet Jun 28 right after Identiverse? - No meeting July 5 - Should we reduce the meeting schedule over July/August? - Who might attend a Kantara plenary on Fri Oct 26 (just after IIW)? Potential cross-group agenda items (e.g. IRMWG, CISWG, CMWG...)? - Decoupled flow if new data - Enterprise use cases/Gluu Gateway - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Facebook launches privacy design lab to create awareness about data sharing
by Maciej Machulak 12 Jun '18

12 Jun '18

https://www.business-standard.com/article/companies/facebook-launches-priva…

1 0

Re: [WG-UMA] Feedback on CIBA
by Mike Schwartz 07 Jun '18

07 Jun '18

MODRNA Group, CIBA was discussed on the UMA WG call today. Eve has been working on a compare/contrast analysis between UMA and CIBA. And this discussion got me thinking a little more... One point from Justin Richer was that you are sending tokens back to the Client Notification Endpoint. This is risky, as you are trusting DNS. UMA makes the client authenticate at the token endpoint to obtain the tokens. Pushing tokens was discussed and dismissed as lacking security. I'm surprised the Open Banking group was ok with this. I also wonder if the response from the bc_authorize should include an id_token--I think it should be some other signed JWT assertion (with many of the claims present in an id_token). It seems weird to me to return an id_token to a client when the subject is not the person connected to the user agent. IMHO, CIBA could be accomplished using UMA as the security mechanism, with bc_authorize as the RS (protected endpoint on the OP). Its request and response would be defined much as you did. If you are starting from scratch, is it easier to implement CIBA with UMA for security, or CIBA plus it's one-off security model? Personally, I think UMA would be cheaper because we'd get more re-use. If I get some time in the next week, I'll try to write up a draft of CIBA using UMA. HEART also uses UMA, so it's not unheard of for an OpenID WG to use it as part of a solution. I know everyone wants to ship ASAP, so it's probably too late to bring this stuff up. - Mike

1 0

Draft minutes of UMA telecon 2018-06-07
by Eve Maler 07 Jun '18

07 Jun '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-06-07 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2018-05-31 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-05-31>: APPROVED by unanimous consent. Decoupled flow: continue discussion - "Force authentication"? - Poll with interval vs. use a notification endpoint? The CIBA spec has both a polling mechanism and a client notification endpoint <http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-…>. Mike is concerned that the token passed here is duplicating the function of the state parameter. When the client calls the notification endpoint, it gets back the equivalent of a permission ticket. Then it can present that ticket at the equivalent of the token endpoint and get back a token, or register a callback URL and say it authenticated the person. But isn't this "backwards UMA", because it would say it authenticated Alice vs. Bob? Mike also has a concern about the /bc-authorize endpoint <http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-…> defined in the CIBA spec, which is basically a new API but not pulled out as a proper API definition. UMA has a claims redirect URI. But it doesn't have any other redirect/callback URI. CIBA suggests another callback URI, that for us might be called an "RPT grant": You get a ticket, you present it at the AS, it returns "OK", and then sometime later, the AS says "I have your RPT" and it sends it back to the client. The comment Mike sent to the MODRNA list about CIBA was: *"In section 6.4. "Token Error Response", There is no way for the user to fix the error if the back channel communication fails. Although you are kicking off the authentication via backchannel, if the user can switch to front channel, she may be able to resolve a problem. For this reason, I would suggest you define a "claims_gathering_endpoint" which can be returned to the client, and in which the user could then interact with the AS. Your claims gathering endpoint could be like an airline quickcode. For example, if I'm working with airline ABC, then the agent could tell me to direct my browser to https://abc.com/ciba/G5JQ2 <https://abc.com/ciba/G5JQ2> Then you have a lot more options to fix the problem (especially if this claims gathering endpoint is on the OP, and you could put the subject through a multi-step authentication workflow)."* Justin notes that CIBA gets that it's not a complete solution. It's identity-focused. UMA is also not complete; it's authorization-focused, and runs in the other direction (Alice to Bob). So the two hurdles to applying UMA-as-it-exists-today to decoupled are a) it runs "backwards" (a big challenge, presumably) and b) it doesn't have a notification endpoint (a smaller challenge, presumably). Justin has been collecting "what do you hate about OAuth2" items. In the chat, Cigdem noted that currently the RO authenticates to the AS for permission purposes and the RS for resource management purposes separately; these are outside UMA's scope. What decoupled seems to look for is authentication of the RO by the AS. Maybe someday there would be a "grand unified theory" version of various specs (OAuth, OIDC, UMA...) that would offer some kind of complete solution for the requirements of decoupled, but today they don't seem to. Mike imagines UMA-protecting the bc-authorize endpoint (effectively the RS role). What would happen? It's an API. It has parameters. They define a permission ticket equivalent (the identifier for the session), and what happens if the person doesn't authorize (similar to UMA's error responses). Part of what they did was needed. What they made up that isn't as "well made up" as UMA, in Mike's estimation, is what happens if the access token is not issued: the authentication error response <http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-…>. UMA allows both back-channel and front-channel loops (this is with the RqP, not the RO, though). Mike is thinking of proposing a "revised CIBA" that uses UMA. To do that, he may need to solve the "backwards" problem! But it would be very interesting to see such a proposal. Enterprise use cases and Gluu Gateway Deferred to next week! Identiverse Justin, Eve, Thomas, Mike, Maciej, Sal, Mark, Colin, and likely other UMAnitarians and Kantarans will be there. 2000 people are expected. They target CxOs and identity architect types. Mark, Sal, and Eve are doing a Privacy 2.0 masterclass. Mike and Eve are doing an UMA2 masterclass. Ping Identity runs it but it's very "ecumenical" in terms of sponsorship. It's in Boston this year. It moves around every year. ZZ Auth and the Love Tokens (featuring Eve, Justin, and others you may know this year [image: (smile)] ) are playing at the closing party. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Andi 3. Maciej 4. Eve 5. Mike 6. Cigdem Non-voting participants: - Justin - Nancy - Thomas - Colin - Tim Regrets: - Sal - Adrian *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Fwd: Re: Feedback on CIBA
by Mike Schwartz 07 Jun '18

07 Jun '18

I sent this comment to MODERNA: 2. In section 6.4. "Token Error Response", There is no way for the user to fix the error if the back channel communication fails. Although you are kicking off the authentication via backchannel, if the user can switch to front channel, she may be able to resolve a problem. For this reason, I would suggest you define a "claims_gathering_endpoint" which can be returned to the client, and in which the user could then interact with the AS. Your claims gathering endpoint could be like an airline quickcode. For example, if I'm working with airline ABC, then the agent could tell me to direct my browser to https://abc.com/ciba/G5JQ2 Then you have a lot more options to fix the problem (especially if this claims gathering endpoint is on the OP, and you could put the subject through a multi-step authentication workflow).

1 0