June 2016 - WG-UMA - mailman.kantarainitiative.org

Thoughts on resource set scope "math"
by George Fletcher 06 Nov '16

06 Nov '16

Assumptions: 1. In UMA, scopes are really "per user" rather than per API. Now it is unlikely, and not encouraged, that an RS would produce an API where the scopes are really unique to each user. In most cases it is more likely that the RS will have a set of defined scopes that work across their entire API and hence across all registered resources. 2. For any given resource set, a subset of the full list of the scopes supported by the RS may be registered. Sets of scopes as identified in the meeting notes from 2016-06-02 [1] 1. The universe of scopes the RS has registered for the resource set 2. The scopes the client has registered for at the AS (if it has done this at all) 1. Note that I would add to this that this list of scopes should rather be the list of scopes the AS has determined the client is allowed to request 3. What the RO has attached to the policy for the resource set 4. What the RS requests for at the permission endpoint (in order to get a ticket) 5. The scopes the client requests at the token endpoint Possible algorithm for determining the set of scopes to be issued with a permissions ticket. * The max possible set of scopes that could be returned from the /token endpoint when requesting a token is the "universe of scopes the RS has registered for the resource set" identified by the permissions-ticket * The allowed set of scopes that can be issued by the UMA AS is the INTERSECTION of "universe of scopes [#1]" and the scopes allowed by the RO policy for that resource set [#3]. Let's give this resulting set a number of [#6] {allowed scopes for the resource set} * The list of scopes requested by the client is determined by the INTERSECTION of [#2] and [#5]. Let's give this resulting set a number of [#7] {scopes the client is allowed to request} * The set of requested scopes is the UNION of set [#7] and set [#4]. Let's give this resulting set a number of [#8]. * The max scopes that can be allowed for this access_token request is the INTERSECTION of set [#6] and set [#8]. Mapping this to pseudo-code: Set PossibleScopes = RegisteredResourceSetScopes INTERSECTION ROAllowedScopes Set ClientScopes = ASAllowedClientScopes INTERSECTION ClientRequestedScopes Set RequestedScopes = ClientScopes UNION PermissionTicketScopes Set AllowedScopes = PossibleScopes UNION RequestedScopes Thanks, George [1] https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-02

5 6

Questions about MPD
by James Phillpotts 21 Jul '16

21 Jul '16

Hi all, As per chat in the join.me session, I have a couple of questions/observations about the MPD flow we have been discussing: - Why are we using the Authorization Grant for the ticket, which is actually the context for the forthcoming authorization that the AS has to assert? Should we be initiating the Client's interaction with the AS at the Authorize endpoint, rather than the token endpoint? - How can the Client maintain a "token session" for Bob so that he doesn't have to reassert claims (and potentially, consent for claim use) every time he gets a new ticket for a future request? It was suggested after the call ended that we could send a consent token that the Client can send back with future requests. Could we issue a signed jwt token (analagous to OpenID Connect id_token, but issued by the UMA AS for presentation back to it, complete with all claims thus far acquired)? Cheers James

3 8

Documenting UMA publication workflows
by Eve Maler 18 Jul '16

18 Jul '16

Hi folks-- Hope you are enjoying post-Christmas reentry or more holiday time, or whatever the case may be. Maciej and I are working on publishing the new Recommendations, and due to that, I unearthed the permanent/symbolic link information that I promised to Justin; we thought it would be a good idea to document the processes here -- and in the GitHub readme... It seems to work pretty well for now given that there isn't that much to the entire publishing process for our WG or others, but if you see ways to improve it for the future, let us know. After completing a draft spec revision cycle and getting it approved: 1. Edit the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources to change from Status #3 to #4 (see below), leaving the previous date in place. 2. Run the stylesheet over the XML sources to produce .html outputs, review the results as required, sync GitHub, and upload the last drafts by FTP (Eve and Oliver can do this). 3. Save the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with rec- instead. 4. Change the Status section of the new files from #4 to #5, the date, and any other metadata (some of this has to be done in the stylesheet, which is in the repo). 5. Update the two specs' References links to each other in the Reference section. 6. Run the stylesheet over the XML sources to produce HTML output with .html extensions, review the results as required, sync to GitHub, and FTP the HTML results to the website (Eve and Oliver can do this). 7. Get symbolic links created (see below) from the versioned rec- HTML links to generic links (Oliver can do this). After launching a new draft spec revision cycle: 1. Save the rec-uma-core-vn_n[_n] and rec-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with draft- and having the agreed new version numbers instead. 2. Edit the Status section from #5 to #1. 3. Proceed to edit the new drafts, and periodically produce HTML results that can be uploaded through FTP. 4. Get symbolic links created from the versioned draft- HTML links to generic links (Oliver can do this). Here are the stages of the Status section (embed links throughout as appropriate): 1. This document is a draft technical specification produced by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 2. This document is a Kantara Initiative Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 3. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. 4. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. The Ballot having passed, this document has been superseded by the Recommendation version of the document. 5. This document was developed by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and approved by the Membership of the Kantara Initiative <http://kantarainitiative.org/> as a Recommendation. Here is how the symbolic links work: https://docs.kantarainitiative.org/uma/rec-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-vn_n[_n].html - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-vn_n[_n].ht… - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/rec-uma-core.html - Symbolic link to latest Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg.html - Symbolic link to latest RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core.html - Symbolic link to latest Core draft https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html - Symbolic link to latest RSR draft *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 2

Allow ID Tokens as RPT
by James Phillpotts 02 Jul '16

02 Jul '16

Hi again, Another suggestion for consideration in UMA-next is whether we should support ID Tokens as an alternative to OAuth2 access tokens for bearer tokens from the Client to the RS. As the ID Token would be minted by the AS, then it should be able to introspect it just as it would an access token. This would also have an advantage in the token-first flow I outlined in my other mail, where the Client can use the additional claims part of requesting an ID Token in OpenID Connect to get the AS to eagerly get extra claims for the user, for example at the time of enrolment. Cheers James

5 16

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