- WG-UMA - mailman.kantarainitiative.org

MPD Writeup
by Justin Richer 01 Jul '16

01 Jul '16

As promised, here’s a writeup about how the MPD process could handle getting RqP consent. Unfortunately, the notes weren’t able to accurately reflect the discussion, so the hope is that we can get some of that out on paper here. In UMA 1.0.x, the RqP takes the client and presumably gets sent to the AS to get an AAT. This presumes that the RqP is able to log in to the AS and authorize an OAuth client to get an OAuth token in some fashion. That AAT is then used alongside the ticket to fetch an RPT. The ticket represents the current transaction as started by the RS (so it’s got a reference to the resource set and therefore RO) and the AAT represents the client and the RqP. The client does not authenticate during this call, nor does the RqP — both of those things happened at the gathering of the AAT. In MPD, the binding happens later. The client sends the ticket to get the RPT, but now it authenticates itself to the token endpoint as part of the call. The RqP, as before, doesn’t authenticate here. In order to interact with the RqP, the AS needs to require the client to redirect the RqP to the claims endpoint. Here, the RqP can authenticate, or do any number of other interactive things required for that ticket. Either alternatively or in addition to this, the client can take a set of claims and submit them alongside the ticket to the token endpoint. One of the questions is how do we capture RqP consent in MPD? I argue that it can be done easily at the interactive claims gathering endpoint. Here, the AS can ask the RqP if they consent to allowing the client to submit claims directly on their behalf or not. That way the AS knows whether or not it should accept or reject them. Nothing we can do in either protocol can ever prevent a rogue client from spewing claims everywhere, nor can we have any insight into the claims gathering process at the client — that is all strictly out of scope and out of band in both versions. So a question is: which is more complex? In the UMA flow, in the worst case, the RqP gets sent to the AS first to authorize the client’s AAT and second to the claims endpoint to attach claims to the specific ticket. That same flow in MPD requires just one visit to the claims endpoint, so I argue it’s a much simpler UX. In the case where the client is pushing claims, then in UMA 1.0 the RqP is sent to authorize the AAT and then the client sends claims. In MPD, the RqP is sent to the claims gathering endpoint to authorize the client sending claims and then the client sends claims. It’s an equivalent UX. Are there other patterns I’m missing beyond the “interactive primary” and “back-channel-primary” ones here? So with that in mind, George brings up a great question: one thing the AAT does is that it represents a long-standing grant between the RqP and the client. At least, it’s supposed to, assuming that the AAT was gathered in an interactive fashion. But let’s say that it was. How can we replicate that longer-running process? I argue that with MPD, we can already mimic this behavior by including either an old RPT or a newly defined “UMA Refresh Token”, I’ll call it a URT, in the subsequent requests. The AS can then look at the ticket, the RPT/URT, and any claims presented by the client, and determine if all of them together make for a good enough answer to the policy on the resource set. From my personal view, I find this method significantly cleaner and less hack-ish than the AAT, since it more logically chains together multiple related transactions. If the transactions aren’t really related to each other, then what continuity does the AAT really provide? We can still identify the client strongly, by use of its client credentials. We can identify the RqP strongly by use of any number of claims binding mechanisms discussed at length. If we want to carry something like that forward throughout a transaction, then yes having a long-running token makes sense, but I would argue that we’ve either already got one (the RPT) or we should issue it along side the RPT in the RPT grant process and not in a special outside loop like the AAT was. Hope this helps, — Justin

1 0

Notes from UMA legal telecom 2016-07-01
by Eve Maler 01 Jul '16

01 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-07-01 - Review document deliverables - UMA Legal Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> – intro and first section have been fleshed out and there are some comments/questions that need answering - UMA Legal Use Cases Attending: Eve, Kathleen, Colin, Jim (regrets: Mark, John, Mary) We took all our notes in the doc. Wonderful progress. Thanks, all! We will try and make progress in the doc for next time! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-07-01 (happy Canada Day -- sorry for the holiday scheduling!)
by Eve Maler 30 Jun '16

30 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-07-01 - Review document deliverables - UMA Legal Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> – intro and first section have been fleshed out and there are some comments/questions that need answering - UMA Legal Use Cases Attending: ... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2016-06-30
by Eve Maler 30 Jun '16

30 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-06-23 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-23> as amended to reflect Andi regrets: APPROVED. Breadth-first MPD review The client request that (potentially) includes scopes is now form-encoded vs. JSON, to align more closely with OAuth. If Alice's policies say that the client is able to get access (e.g., because it pushed sufficient claims about the RqP that matched the RO's policies and the particular identified client is okay), then the AS could issue an access token right away. This is the final choice outside the loop. Inside the loop, there are now two choices, vs. three, since there's no AAT. The AS rotates the ticket every time it returns a response to the client, and gives it need_info (with new syntax). The client either "sends claims" to the token endpoint, or "sends the RqP" to the claims endpoint. With the AAT in the picture, UMA had an in-band way to let the RqP permission the pushing of claims (about them) to the AS. What happens now? We discussed what uma_authorization scope really means. Although UMA Core says *"The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims, ask for authorization, and perform any other tasks needed for obtaining authorization for access to resources at all resource servers that use this authorization server"*, is it strictly true that Bob would know this in practice? Would UX standards have to be put in place in deployments? Since the AAT was covering an unspecified set of claims, Justin is suggesting that an AAT was insufficiently granular to inform Bob about what was going on. Can we assume the wonderful circumstance that Bob's relevant claims are UMA-protected and therefore the "out-of-band" protection circumstance is ideal for fine-grained protection with Alice's AS? A typical case, we expect, is a SSO-like pattern where the information the AS needs is pre-negotiated with the client. In the case of a "promiscuous client" that is set up to share a lot of information about Bob, the interactive pattern could be used as a flow to get Bob to approve of, confirm, or consent to sharing that would otherwise happen silently. This would exploit two parts of the loop. If we want to ensure this pattern is available as a regular thing, Bob would get redirected to the claims endpoint at the AS, where Bob has to choose some claims provider that can supply a claim about accepting the client as representing him. The "non-in-band" experience is totally silent = smoother. The "in-band" experience involves a redirect to the AS and then to a claims provider = equal to the current AAT experience if there is a local login, or possibly more involved if there's choice about where to go to get the claim (Eve believes this is true; Justin disputes it). There are now the two options. Will clients have the incentive to go for the smoother option (and will "UMA protection" arise for this)? *AI:* Justin: Write up answers in email to the questions above. Another question: When the RqP = the RO (that is, it's Alice-to-Alice sharing), how would the loop work? *(We closed the formal WG call and continued discussing.)* Right now, the RqP's identity is bound into the AAT. But without the AAT, the client wouldn't have that available. As long as we can provide an identity token in a client-authenticated call, George asks, isn't there a way to solve this? Eve's question is about the use of the claims endpoint vs. the authorization endpoint: If it's Alice, shouldn't she use the latter? Only if it's OAuth vs. UMA. Alice-as-RqP should use the claims endpoint. George wants a strong proof of Bob. The AAT gave him that, so whatever future mechanisms need to not lose that. Also, the AAT made the semantic of identity (and approval) persistent across a single transaction or session. We discussed how, in the current UMA flow, the client is able to pass in the current RPT to get the next one; we could leverage this pattern in order for the client to provide "Bob context" to the AS at the token endpoint. Another question: We know that the trust elevation mechanism is gaining attention as a place for extension. How should we ensure this going forward? Logistics (discussed post-official call) Since we're once again in design mode, we should strongly consider expanding our meetings to 90 minutes. Would 8:30-10am or 9-10:30am PT be better for people? Attendees As of 23 Jun 2016 (post-meeting), quorum is 6 of 11. (Domenico, Kathleen, Sal, Nagesh, Andi, Robert, Agus, Maciej, Eve, Mike, Sarah) 1. Domenico 2. Kathleen 3. Nagesh 4. Andi 5. Maciej 6. Eve 7. Sarah Non-voting participants: - François - John W - James - Scott - Justin - Ishan - George *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecom 2016-06-30
by Eve Maler 29 Jun '16

29 Jun '16

(Try the web calling interface this time if the other calling methods give you trouble...) http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30 Date and Time - *Thu Jun 30,* 9-10am PT - Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web calling interface <https://panel.turbobridge.com/webcall/>, code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar - If our TurboBridge troubles persist, we'll consider moving to a donated bridge Agenda - Roll call - Approve minutes of UMA telecom 2016-06-23 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-23> - For reference: MPD sequence diagram <http://www.websequencediagrams.com/files/render?link=2DdzslbnVj3ShhlrLVV-> and generic low-level sequence diagram <http://www.websequencediagrams.com/files/render?link=V0tZE2kWrO0l-tGlZX1a> - Registering multiple resource sets - Input from George on existing spec text? - Client awareness of scopes - Concrete proposals based on multiple-resource-set directions? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Token-first, reduced-ticket use flow
by James Phillpotts 27 Jun '16

27 Jun '16

Hi all, I'd like to formally propose support for a token-first, reduced-ticket use flow for UMA-next. The scenario this addresses is when the RS publicly publishes the scopes that it uses for resources (as many OAuth2 RSs do currently), and the Client would like to get a single token for this up-front, before it accesses anything at the RS specifically owned by Alice. Here is a brief description of how I see this working: - For the simple case, let's say that Client service is a tightly coupled client to services from one RS (could be multiple, not necessary for this description). Let's say the RS is a photo sharing site, and the Client is a photo printing site - Bob signs up to Printing (client) service - Client uses AS for sign in - Because the Client knows that the user will be printing photos, it requests scope photos-view-hires in its token - Client has obtained access token that includes the requested scope - Client accesses Alice's photo resource, presenting Bob's bearer token - RS uses the protection API to register an attempted access to a Resource Set, but includes the presented token in the request - The AS evaluates the policy for the Resource Set using the details from the token, and responds: - If the policy is satisfied, (a) a ticket is not generated, and the AS returns a success response - If the policy is not satisfied, the AS can choose whether (b) to return a ticket, in which case the UMA flow continues as usual, or (c) return a forbidden response with optional message for Bob - The RS then returns either (a) the resource, (b) returns a WWW-Authenticate response, as per usual flow, or (c) returns a forbidden response with the message from the AS, if supplied. If it would help, I'm happy to produce a sequence diagram for the above. Cheers James

4 9

Really scary Microsoft Word and Dropbox experience
by Adrian Gropper 25 Jun '16

25 Jun '16

(apologies for cross-posting) I just created a shared folder with a vendor in my Dropbox and was notified by Dropbox of the change by email. I went to my Dropbox account settings to check on the scope of sharing that the new vendor just got and was surprised to see that Microsoft Word already had full access to read and write all of my Dropbox. I'm pretty careful about these things and I don't recall ever, for any reason, connecting Word and Dropbox. I assume that I did and just forgot but this kind of thing blows my mind. My point is simply that scattering my OAuth2-type authorization policies across multiple portals (and multiple OAuth2 Authorization Servers) is completely un-scalable. The model for policy management relative to either VRM or UMA has to be that each person gets to specify their policy server and notification endpoint to the various vendors. Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

Notes from UMA legal telecon 2016-06-24
by Eve Maler 24 Jun '16

24 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-06-24 - Review document deliverables - UMA Legal Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - UMA Legal Use Cases Attending: Eve, Kathleen, Ann, John W, Adrian, Scott, Paul, Mark We started reviewing the primer. If we can't make it all fit into 2-3 pages as we first hoped, let's try and use a "progressive disclosure" approach, so that the first part boils down the rest of the paper in a very short space. *NOTE:* All but Eve (and John): Eve will "take the pen" over the weekend in the doc. If you want to do stuff in the doc till the next meeting, please do so in Suggest mode! Adrian introduced the notion of the AS as the only safe way to handle bots (such as Siri) that are the alternative to the explosion of apps on mobile devices (see the de-app-ification trend <http://www.wired.com/2015/06/apple-google-ecosystem/>). So the "agent" theme as exemplified by a *personal* AS could be an exploratory theme in the doc. How deep to go on privacy compliance? Scott suggests that UMA makes the underlying systems reliable and predictable, which provides a basis for trust and enables observability of regular actions. The systems are tuned to local expectations. Things are "done to spec". Adrian observes that UMA could be said to be a "core component of privacy engineering <https://en.wikipedia.org/wiki/Privacy_engineering>". Scott also reframes as "operational privacy". Don't forget about Privacy by Design <https://www.ipc.on.ca/english/privacy/introduction-to-pbd/> – here is the (old by now?) paper on Privacy by Design implications of UMA <http://tinyurl.com/umapbd>. Why could an XXX love it? CPO: - Standards make for cheaper solutions for compliance. Average US privacy budget (PSR '15): $300K. - Emerging ecology of user control standards gives an alternative to contracts of adhesion. Data subject: - There's power in having more "consent tech" solutions available and deployed on your behalf to choose from. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-06-24
by Eve Maler 23 Jun '16

23 Jun '16

Please note that TurboBridge is still being frustrating, but James P on today's UMA WG call discovered that the web interface (link provided below) was working very nicely for him. Domenico, on the other hand, found that the "Call" button wasn't working for him on Safari... Please give it an extra couple of minutes to try and get into the call, if you can. Thanks! http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… Date and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web interface <https://panel.turbobridge.com/webcall/>, code 178-2540# - Screen sharing: http://join.me/findthomas – NOTE: do not use the join.me dial-in line - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar 2016-06-24 - Review document deliverables - UMA Legal Primer - UMA Legal Use Cases *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2016-06-23
by Eve Maler 23 Jun '16

23 Jun '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-23 MinutesLogistics Did you know that it's possible to join through the TurboBridge website <https://panel.turbobridge.com/webcall/> for free????? Thanks to James for discovering this! Roll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-06-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02>: APPROVED. Implementation page and UMA Dev We discussed the plan of action decided by UMA Dev yesterday <http://kantarainitiative.org/confluence/display/umadev/UMA+Dev+telecon+2016…>. To clarify, we won't question or test their info, just provide it as-is, and we can make that clear. Leadership team elections A candidate motion: MOTION: Moved by Sarah: Approve Eve as Chair, Maciej as Vice-Chair, Domenico as User Experience Editor, and Maciej as UMA Dev WG Liaison for the next year: APPROVED by unanimous consent. AI: Eve: Sort out editor role elections and update the Leadership Team page. AI: Eve: Sort out corresponding UMA Dev elections. Registering multiple resource sets George's proposal was to use the existing REST path we have and use an array/not-array cue for whether we are registering multiple resource sets or a single resource set. According to his research, this seems to be a somewhat common pattern for indicating that the AS is about to get just one thing. Our previous work on the permission registration extension, while not reflected in our latest draft <https://08620661282160442115.googlegroups.com/attach/f218681b41266/draft-um…> in the email archives, was going in the direction of assuming that it's more consistent to have the RS always use an array; the only problem at the time was that this was backwards-incompatible. On what basis should we be making a decision? - Our requirements and design principles <http://kantarainitiative.org/confluence/display/uma/UMA+Requirements> say that the AS should bear more complexity than the RS or client; the RS shouldn't have to help the AS with this. - If the RS is registering one thing vs. multiple things most of the time, it shouldn't have to wrap it in an array. (What are the use cases that drive the percentage of the time? Nagesh prefers the certainty of knowing it's going to be an array vs. picking.) - In an extension we have to care about backwards compatibility, but in a new version where we're already doing other backwards-incompatible things, we don't have to care. Is it really necessary for the RS to explicitly register all of the many resources to give the AS visibility into the structure of an API? Adrian has a vision of informing the AS that the FHIR semantics are in play, and it could know that the relevant sub-resource sets are being protected once the top-level EHR or whatever is registered. FHIR was actually a key motivation for multiple resource set registration in Eve's case. Given that the AS is currently "stupid" with respect to resource set dividing lines, and the RS is authoritative for them, it's important (to her mind) to be sure the RS is actually capable of exploiting the entirety of the currently-flat namespace for resource sets, including experimenting with the possibility of extending resource set description documents. Kathleen notes that there is work on a FHIR Consent structure, and an RDF-OWL FHIR mapping. These could enhance a registered resource set, e.g. by being included with the description document, so that the relevant policies are bound to labeled resources. A use case for using this would be that if you have to do a notification for Accounting of Disclosures, and it has to go to the patient's endpoint, it could be connected to the correct consent downstream. We'll see if we can lock down consensus next time; our current leaning seems to be an "all-array" approach. AI: George: Look at and critique the current permission registration extension text as a candidate for new spec text, from the perspective our current leaning. Attendees As of 12 Jun 2016, quorum is 7 of 13. (François, Domenico, Kathleen, Sal, Nagesh, Thomas, Andi, Robert, Agus, Maciej, Eve, Mike, Sarah) 1. Domenico 2. Kathleen 3. Sal 4. Nagesh 5. Maciej 6. Eve 7. Mike 8. Sarah Non-voting participants: - Adrian - Scott S - Scott F - James - George - John W Regrets: - Justin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0