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

Agenda for UMA telecon 2016-12-01
by Eve Maler 30 Nov '16

30 Nov '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-12-01 Date and Time - *Thursdays,* 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 1782540 - 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 Agenda - Roll call - Approve minutes of UMA telecon 2016-11-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10> - Logistics for upcoming meetings (calendar <http://kantarainitiative.org/confluence/display/uma/Calendar>) and 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> check-in - *Dec8/9:* no meetings (consider meeting Wed afternoon or something?) - *Dec 15/16:* meet as usual - *Dec 22:* meet as usual; RSVP – Dec 23: no meeting - *FYI:* End game for V2 specs looks like this: - WG vote to publish Draft Recommendations (consider this an "implementers' draft"?) - 45-day Public Review - If no changes, LC votes to certify Draft Recommendations for All-Member Ballot - Ballot takes 14+ days - If no changes, Recommendations are prepared for publication and published - Total: if no changes, up to 90 days - Work on UMA.next issues – Core is up to 09 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html> and RReg is up to 02 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html> – please review changes ahead of time if possible - Core: token profiling, rhetorical - To discuss specifically: - Set math (see forthcoming email for discussion points) - Remove policy-specific resource/scope description properties from RReg and add as extensions in Core? - AATs could be used for "stateful trust elevation"/step-up authentication; do we have any equivalent now, and if not, is this lack okay? - claim_token_profiles_supported: Provide real profiles for OIDC and maybe SAML? - uma_profiles_supported: What to do with the extensibility profiles? - Need to have IANA registry entries for both old uma-configuration and uma2-configuration? - Shoebox endpoint - Claims hashing - Other issue backlog review/cleanup - See the latest swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #256: Consider the naming of entities and concepts: token/ticket/registration terms
by Eve Maler 30 Nov '16

30 Nov '16

https://github.com/KantaraInitiative/wg-uma/issues/256 This is one of a series of messages meant for discussion of naming of entities and concepts. This message consolidates a bunch of *token/ticket/registration* terms from the GitHub issue: - requesting party token (RPT) (original) - protection API token (PAT) (original) - authorization API token (AAT) (obsolete) - persisted claim token (PCT) (new) - permission ticket, registering a requested permission (original), registering for a permission ticket (colloquial) - uma_ticket (new; in the URL of the UMA grant type) - register a resource set (original) For now, let's please discuss only in email, unless we're all somehow magically aligned by the time we get to the next call. I'll provide my own thoughts in a followup message. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 6

Article on Privacy as a Service referencing Kantara Work
by John Wunderlich 28 Nov '16

28 Nov '16

Behind a paywall, but this article references both UMA and the Consent Receipt. If you have access, give it a read. https://www.computer.org/csdl/mags/co/2016/11/mco2016110049-abs.html Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN> Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Attempt at better clarity around "resources can have multiple parts on the RS side"
by Eve Maler 28 Nov '16

28 Nov '16

I realized that we had an unstated MAY here. Instead of trying to squish the statement into the RReg "protected resource" definition as before, I've now broken this out into a paragraph in RReg Sec 2, Resource Registration, as follows: "A resource server MAY register and manage as a single protected resource a set of digital data or API endpoints that, from its perspective, consists multiple parts, has dynamic elements, or otherwise has internal complexity; it alone is responsible for maintaining any required mappings between this complexity and the resource identifier known to the authorization server." This is something that, in fact, the HEART group has been facing in its discussions about the FHIR API, and other APIs that are working on UMA protection will face it as well (though FHIR has the worst of it since it's a complex API). Let me know what you think. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Reminder: UMA APAC sync coming up
by Eve Maler 28 Nov '16

28 Nov '16

*Purpose:* Synchronizing on current work with APAC-based participants and gathering their input. *RSVPs* from those in the APAC region (sent directly to me) will be much appreciated! *Call may be canceled if no RSVPs* - Sample times: US Pacific *Tue Nov 29* 4pm / Aus east *Wed Nov 30* 11am / NZ *Wed Nov 30* 1pm - Skype: +99051000000481 - US toll: +1-805-309-2350 - Sydney: +61.2.8014.4647 - Auckland: +64.9.973.0310 - Additional international numbers: https://www.turbobridge.com/in ternational.html <https://www.google.com/url?q=https%3A%2F%2Fwww.turbobridge.com%2Finternatio…> - Web: https://panel.turbobridge.com/webcall/ <https://www.google.com/url?q=https%3A%2F%2Fpanel.turbobridge.com%2Fwebcall%…> - Code: 178-2540# - Screenshare: http://join.me/findthomas <https://www.google.com/url?q=http%3A%2F%2Fjoin.me%2Ffindthomas&sa=D&ust=147…> (DO NOT USE join.me <https://www.google.com/url?q=http%3A%2F%2Fjoin.me&sa=D&ust=1475556106312000…> dial-in number) - See the calendar entry for more details: http://kantarainitiative.org/c onfluence/display/uma/Calendar *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New drafts are ready
by Eve Maler 28 Nov '16

28 Nov '16

Core rev 09: https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html RReg rev 02: https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-02.html I closed issues #235 and #236 from Sarah on RReg. We haven't been very disciplined about closing issues that have been implemented and thoroughly discussed in Core, but there's really quite a lot of them that could be closed by now; I'll plan to do that shortly. Biggest changes this time around/food for thought for our call this Thursday: - Token profiling in Core - Lots of rhetorical/conceptual changes in the front part of Core (please read through -- new ASCII art!) - Scope set math is fully on the docket! - Assumption: Only one grant is in use at a time - Assumption: Client-requested scopes are intended to apply only to the apparent resource that the client attempted to access (since they can't know about resource IDs) ?? - Question: What should guide RS's in requesting permissions on behalf of a client? I for one would be very willing to have this week's call go a little long as I have to miss the following week again, and time is getting very short. If anyone can stay long with me, that would be great. Lots still to do. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: No WG or Legal call this week due to US Thanksgiving
by Eve Maler 22 Nov '16

22 Nov '16

I do plan to have Core 09 and RReg 02 out sometime after Thursday, though! The Core changes will concentrate on the Intros, conceptual descriptions, and new diagrams (so text diffs will unfortunately be a bit invasive). Happy Thanksgiving to all those celebrating it! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Removing RReg's dependency on resource owners
by Eve Maler 19 Nov '16

19 Nov '16

Currently in RReg we make the "name" property in the resource description and the scope description REQUIRED, for the UMA use case. Given our discussion in the 2016-11-18 telecon about softening resource owner-related things in RReg, properly these should be OPTIONAL (since OAuth and OIDC don't involve "setting policies", and OAuth sometimes doesn't involve resource owners at all, only clients acting on their own behalf). Should the Core spec profile RReg to make these properties REQUIRED vs. OPTIONAL? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA telecon 2016-11-18
by Eve Maler 18 Nov '16

18 Nov '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-18 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-11-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-11-10>: Deferred. Logistics The agenda is starting to include even the minutiae of the issue backlog and the roadmap. It looks long, but is designed to keep us honest in gaining consensus on discussion topics. If people show up to meetings and review spec drafts, we'll push through everything on a good schedule. No meetings next week. Work on UMA.next issues The RReg definition of a protected resource goes too far because it presumes an RO. If we soften it to mention just an AS, then we think that the RReg spec is generic enough to serve OAuth needs along with UMA etc. needs. Let's try that. Eve asked an aesthetic question about the sample endpoints in the config response. If anyone would like to see them looking different send mail with your preference. The entire abstract and Introduction are new (and is awaiting a new ASCII diagram). PLEASE review and comment. Discussion of Eve's strawman proposal: James likes the idea because, what if you want to mix UMA and OAuth scopes? You can't expect a client to maintain multiple access tokens where there are AS's supporting multiple grant types that deal with incompatible tokens. This is where getting Implementer's Drafts out there would be really useful. You could include OAuth scopes in an RPT now with no UMA permissions, but the permissions property would still have to appear with nothing in the array; that's ugly. If the AS gives the RS a locally validatable RPT, normally the format of the token would be considered in the realm of a "private communication" between them, and it would be considered a burden to impose constraints on that. In the interest of making possible the new Intro text's promise that "The token introspection extension lets the resource owner increase and decrease grants at a grain finer than a whole access token.", do we want to say that the AS MUST/SHOULD/MAY package up locally validatable RPTs as signed versions of the token introspection object? Maybe we just point this out; it's the obvious object to sign if you want that functionality. *AI:* James: Send a note to the list about the question of a locally validatable RPT and whether to recommend something about its format. What scopes should the client ask for, and why? The client knows nothing about resource IDs and in particular nothing about any of the resource IDs associated with the permission ticket it just brought to the AS, only about the API and presumably about the scopes possible on the HTTP resource to which it just attempted access. This client-AS request is the first step in the UMA grant, and we can tell because the client is coming to the token endpoint with a permission ticket. Let's say the ticket has R1, R2, and R3. They all have "view" available, and R2 and R3 have "print" available. There are OAuth-protected resources at the same RS that have scopes that overlap. Is it possible to have a hybrid client-AS request at this stage? Is it possible to be executing two OAuth grants at the same time? Eve hasn't heard of this before, and we do already have an invalid_scope error in place to protect against scope clashes of the sort imagined. This may mean that our hybrid UMA-OAuth scenario above wouldn't work anyway. *AI:* Eve: Send a note to the list laying out the current situation wrt scopes. Instructions: - RReg 02: Soften "protected resource" definition and any similar passages to remove the insistence that an RO is required for protection to obtain over a resource. - Implement the token introspection proposal. - Sketch a Sec 1 Intro diagram. - Revise the Sec 3 intro and sketch an ASCII diagram for it. Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Eve 2. Maciej 3. Sarah Non-voting participants: - James - Arlene - Kathleen Regrets: - John W - Sal *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA legal telecon 2016-11-18
by Eve Maler 18 Nov '16

18 Nov '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-11-18 - Eve to give update on Karsten Kinast convo Attending: Eve, John W, Kathleen Eve had a chance to deep-dive on some of our current topics with Karsten. In the rights-based EU conception, law/regulatory interpretation/contract can capture the sheer reality of little Johnny's natural rights to privacy over data about him; he has an aura that can't be detached. His relationship with his mother Alice is internal, and UMA's relationship is with him, not Alice. This is "the view of the world from the human rights/legal end". On the other hand, "the view of the world from the technical end", where the technical end in our case is UMA, would connect UMA to Alice because she is the one actually wielding the technology as a resource owner. So the bridge we're building connects those two worlds at the point of identifying the resource owner, data subject, and grantor roles. Does that work? For this reason, it's perhaps best to use the literal GDPR (and other data protection law) wording, vs. being cute and using "resource subject". This is making us want to revise the charter to a) ensure that our work helps UMA be used for good and not evil generally, and also b) ensure it's used *on behalf of* data subjects, not just for resource owners in that role. How about replacing ", particularly where the resource owner is an individual" with "in a manner consistent with protecting privacy rights" (and get rid of the word "themselves")? They also talked about sharing access with the intent of making the grantee a(nother) data controller vs. making them a data processor. Making someone a DP (say, because you're asking them to do something "on your behalf" for consideration – e.g. outsourcing payroll processing) means accountability remains with the grantor (Alice), while making someone another DC means you've just given them access for whatever reason, and they're just another accessor. Control becomes additive. So Eve's working theory became: Would it be possible to develop tools that distinguish between Alice's ability to grant access for the purpose of processing vs. for other purposes, as a broad means of managing the DS's/ risk? Would our time be best spent in this group working on these tools first vs. other tools? Could grantors/resource owners clearly understand such distinctions? This is where the DS would be accountable but the DP would need to take on responsibilities (think "RACI") to balance the risk. Our tools – e.g., data sharing agreements – could include standard text for that. The last subject they discussed was the types of use cases that would need to be developed. Eve has started a fresh Legal Use Cases page, here <http://kantarainitiative.org/confluence/display/uma/Legal+Use+Cases>. It's just a shell so far. Following are the use case axes identified so far. - Granting access to DC vs. DP - Disclosing data vs. granting other kinds of access (e.g., letting a client of a grantee add data back through the API, or let it use an algorithm by paying for access, or accessing a photo...) - Whether the DS and the grantor are both in the EU (leave this complexity aside for now??) - Every vertical and horizontal use case will probably need its own special-sauce text! But we should at least start gathering examples and identifying what are hopefully "design patterns" John is concerned that XACML went down a similar path, with resulting complexity. Let's seek ways to boil the smallest of ponds. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0