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

Notes from UMA legal telecon 2016-10-07
by Eve Maler 07 Oct '16

07 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-10-07 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> Attending: Eve, Kathleen, Adrian, Mary Let's do some use case work today. Kathleen notes that, working with the US feds, there's a difference between a "contract" and a "memorandum of understanding" (MOU). In an MOU, they're funding a program, so some transaction value is flowing. Many types of contracts do capture some sort of payment. Maybe this has to do with the relationship being formed, and therefore impacts the model clauses most forcefully. Analogously to the Grantee/Resource Subject split, we anticipate there needs to be a Grantor/*something* split, where there's potentially someone who might request and get access as part of an employment contract on behalf of the real party who's accountable for the access (like the doctor or admin who works for a hospital). Mary brings up "*Relying Party*" as a candidate for the opposite side of the Resource Subject. Eve has some discomfort because it may cause confusion between identity federations and access federations. But what if the analogy with the sharing specifically of personal data is so powerful that this phrase evokes the right images? Or maybe *Receiving Party*? *Resource Recipient*? RO-side use cases, summarized: - UC1: RO = Grantor = Resource Subject, where this natural person has legal capacity - UC2: RO = Grantor, where Resource Subject is a natural person without legal capacity - UC3: RO = Grantor, where Resource Subject is a natural underage person unable to consent online (yet) and they are also a RqP - We need a *UC3a* that maps what happens when the underage person becomes of age - UC4: RO = Grantor, where ... What are the RqP-side analogies? Let's try and fill those out next time. We need to build out these lists for every technical role. AS-side use cases: Adrian's main concern is the AS as an agent of the Resource Subject or Grantor, where there are the strongest possible constraints (technical if possible) on anyone but them seeing their policies and the RS cannot known whether the policies are under the control of either the Resource Subject or Grantor. In this context, he wants to describe the limitations of liability of an RS. The issue here is that the service we would call the RS currently has visibility into a sign-off by people in both the resource subject and guardian/proxy roles in some fashion, and since UMA interposes an AS as an "agent", any service becoming an UMA RS would lose this visibility. The legal questions for us are: Is this loss of visibility acceptable? If not, do we have to build a facsimile of the visibility into our model clauses? Are there jurisdictional variations? *AI:* Adrian: Add the above as a GitHub issue <https://github.com/KantaraInitiative/wg-uma/issues>. PARKING LOT: One thing we should discuss at some point is the notion of "pushing" content" vs. a typical web pattern of "pulling" content. The usual web pattern we think of is that a client approaches an API unilaterally, which is nominally a "pull". However, there are patterns such as websocket where there is a constantly open channel through which the RS could push content at will. The IoT uses this a bunch, and some other technologies. Kathleen mentioned the AS serving as a content broker – we'd have to discuss what this means more. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Introduction - Cigdem Sengul
by Cigdem Sengul 07 Oct '16

07 Oct '16

Dear UMA workgroup members, I have joined the UMA working group a few days ago. I am a Senior Researcher in Nominet R&D working on the privacy in the Internet of Things. Nominet, as its core business, is the official registry of the .uk domain names. The R&D group explores emerging technologies and engages in applied research. Our current focus is on Internet of Things, Smart Cities, and TV White Space. My main expertise is network protocols and mobile and wireless networks. In the past year, I have been researching on UMA and experimenting with how it fits with our IoT projects. For more information about me: https://uk.linkedin.com/in/cigdemsengul You can find a list of our IoT projects in: http://www.nominet.uk/emerging-technology/internet-of-things-tools/ General R&D: http://www.nominet.uk/emerging-technology/ Sincerely, Cigdem Sengul, PhD Senior Researcher [cid:image001.png@01D22075.2F7E1420] Website<http://www.nominet.uk/> | Twitter<https://twitter.com/Nominet> | Facebook<https://www.facebook.com/nominet/> DD: +44 (0)1865 332256 E: cigdem.sengul(a)nominet.uk Minerva House, Edmund Halley Road, Oxford Science Park, Oxford, OX4 4DQ, United Kingdom Nominet UK. Registered in England and Wales No. 3203859 This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. Nominet UK has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment.

1 0

Draft minutes of UMA telecon 2016-10-06
by Eve Maler 07 Oct '16

07 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06 MinutesRoll call Quorum was reached. Logistics The call for *the week after next* will be held *Fri Oct 21* instead of *Thu Oct 20*, just after the Legal subgroup call. Next week we'll have an 04 within which we should have a permission ticket flow for the RS wherein which there will be a framework for the client to theoretically be able to ask for scopes for multiple resource sets by the time it gets to the AS. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : APPROVED by acclamation. IIW The UMA video <https://www.youtube.com/watch?v=U3mZmzVOAqE> is up! Is it better to consolidate all links to one channel, or put the video on multiple channels? Inconclusive. Do we want to start a Vimeo channel as well? Let's not. Phil has given us an opportunity to do a pre-planned UMA 101 session at IIW. George is giving the session. Others here can provide feedback. NOTE: Please give an "IP policy benediction" at the start of any UMA content-related sessions. Here's the IPR policy <http://kantarainitiative.org/confluence/pages/viewpage.action?pageId=410256…> and here's the joining form <http://signup.kantarainitiative.org/?selectedGroup=11>; you could print them out or distribute the links for people's convenience. Work on UMA.next issues We need to look at the security considerations of the PCT. It's a bit like a refresh token, in that it's got extra power over an access token and so must be wielded carefully. Could hijacking and replaying a PCT be bad? It's bound to the client credentials like a refresh token would be, but the point is to go get an access token without having to present (or have the RqP get pumped through interactions for) a whole bunch of claims all over again. In the terminology definition, do we want to go into more detail about the intended usage, or is the existing (fairly large already) detail about the "claim components" of the PCT okay? Sec 1.3.2 has more about the intended usage, similar to the previous AAT description. Regarding the "[ISSUE: what about at the same or a different resource server?]", the answer is that it's immaterial wrt the resource server, just as it was for the AAT. Regarding issue #251 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17>, the telecon notes were not accurate. Unguessable and unforgeable by an attacker is the only requirement; securely random would be one way to meet the requirement. Mike suggests pointing to OAuth Sec 10.10 <https://tools.ietf.org/html/rfc6749#section-10.10> – or maybe we could leverage its wording – to get the right effect. The specific wording we like is "The authorization server MUST prevent attackers from guessing access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials." Say this in the security considerations, or for each token/ticket/thingie? See below. Spec instructions: - Add some security considerations around PCTs, including why the client has to make a "best effort" - Remove the [ISSUE] above and fill in the language - Regarding "same requesting party as previously", change to "same as the previous requesting party". - Say "unguessable" as the definition for each token/ticket and then require the one-paragraph version of unguessability once in the security considerations. Next time, we'll look at Domenico's diagrams for UMA grant flows. Next time, for set math discussions: *What does the RS have to do at permission ticket registration time?* What is the RS's motivation for registering anything at all? Its only context is what access the client attempted. *Can the client request scopes from the RS (in addition to just attempting access)? *No. *How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?* The question we need to ask at each messaging stage to get the semantics for each actor correct, and crystal-clear, is: What is the context, and "what's my motivation?" [image: (smile)] Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Andi 3. Robert 4. Maciej 5. Eve 6. Mike 7. Sarah Non-voting participants: - Andrew - François - Kathleen - James - Justin - Scott F - Jin - John W - Adrian - George *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

FYI, the WG call in two weeks has been moved to Fri Oct 21
by Eve Maler 06 Oct '16

06 Oct '16

I've already moved the calendar entry from Thu Oct 20 at 9am PT to Fri Oct 21 at 9am PT, just after the legal call. I checked, and it looks like Europe, at least, won't have shifted off summertime yet. The calendar is here if you haven't subscribed to it yet: http://kantarainitiative.org/confluence/display/uma/Calendar *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA diagrams and flowchart
by Domenico Catalano 06 Oct '16

06 Oct '16

1 0

Editors' draft 03 is up
by Eve Maler 06 Oct '16

06 Oct '16

Draft 03 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-03.html>. We're starting to make enough invasive changes that reading it through more comprehensively is a good idea, but here are the difference sets <https://github.com/KantaraInitiative/wg-uma/commits/mpd-edits> to pay close attention to: - First wave of edits <https://github.com/KantaraInitiative/wg-uma/commit/c7982502dc87557509dc5b21…> after last Thursday - Ignore the trivial stuff and hunt for lines 288, 392, 418, 1196 (edited more just below), 1307 (a bit) - In future, I'll try and isolate that extra-space stuff into a separate commit - Second wave of edits <https://github.com/KantaraInitiative/wg-uma/commit/9316db4f5202d163e11aa1f0…> after last Thursday - Implemented <https://github.com/KantaraInitiative/wg-uma/commit/2521674d9f186f6b5676d29c…> issue #251 - Quick cleanup of permission ticket language Domenico has done some nice flowchart-y graphics around the notion of "authorization process", "authorization interface", and the new token landscape we can look at together tomorrow. Let's see if we can get quorum, cement decisions around this direction, and settle on set math decisions (what flexibility does the RS have? what are the parameters within which the client works? how does this all work when it's possible to register multiple resource sets when getting a permission ticket?) tomorrow. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Agenda for UMA telecon 2016-10-06
by Eve Maler 05 Oct '16

05 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06 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-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> - IIW - UMA 101 session leader - Video premier(s) - Work on UMA.next issues - Core is up to 03 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-03.html> - RSR is up to 00 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html> - See email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/t3VvdkCvf…> for list and description of the latest changes and discussion agenda - Review Domenico's diagrams - FB page <https://www.facebook.com/UserManagedAccess/> care and feeding ideas - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: UMA APAC sync tomorrow
by Eve Maler 03 Oct '16

03 Oct '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! - Sample times: Seattle Tue Oct 4 4pm / Sydney Wed Oct 5 10am / Wellington Wed Oct 5 noon - Skype: +99051000000481 - US toll: +1-805-309-2350 - Sydney: +61.2.8014.4647 - Additional international numbers: https://www.turbobridge.com/international.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/confluence/display/uma/Calendar *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA telecon 2016-09-29
by Eve Maler 03 Oct '16

03 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends. The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec. *AI:* Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes. The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether." A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes." Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners." Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay. The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? *AI:* Eve: Get Justin's input on our analysis and questions. In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be *represnted* by the persisted claims token (PCT) present by the client in the pct *paramter*. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable." (Note and fix typos.) James had proposed set math as follows: (ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes The questions for the spec are: - What does the RS have to do at API publication time, if anything? - There *will* be scopes published, whether in informal fashion or, say, Swagger (machine-readable) - Nothing much more to say about this, probably (we have some editorial notes on it) - What does the client have to do at scope registration time, if anything? - It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) - *What does the RS have to do at permission ticket registration time?* - In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other - This remains to be fully discussed, though we started it at CIS - *Can the client request scopes from the RS (in addition to just attempting access)?* (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) - What does the client have to do at RPT request time? - *How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?* - In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible - What does the AS have to do at RPT issuance time? - In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it - There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer) Spec instructions: - See above! Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Sal 3. Nagesh 4. Robert 5. Eve Non-voting participants: - Andrew - Scott F - Kathleen - James Regrets: - Mike - John W - Andi *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 9

Re: [WG-UMA] Consider the naming of entities and concepts (#256)
by Mike Schwartz 01 Oct '16

01 Oct '16

>>> confusion around an UMA client vs. an OAuth client... I find the term "UMA Client" particularly confusing, because the RS is also an OAuth2 client when it obtains a PAT. >>> * trust elevation vs. claims gathering (interactive exclusively?) To me, trust elevation implies increased level of assurance about the identity (i.e. just the subject identifier). While additional claims can increase your trust, and perhaps each claim can carry it's own assurance, I think seperating identity from claims would be more clear.

2 1