- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA legal telecon 2016-10-14
by Eve Maler 13 Oct '16

13 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-10-14 - Working session on User-Managed Access (UMA) in Contractual and Regulatory Contexts <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> - Working through use cases per party in the transaction – see last week's notes for the pattern *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2016-10-13 (meeting is on FRIDAY next week)
by Eve Maler 13 Oct '16

13 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13 MinutesRoll call Quorum was reached. Logistics REMINDER: The call for *NEXT WEEK *will be held *Fri Oct 21* instead of *Thu Oct 20*, just after the Legal subgroup call. IIW WEEK: Move to Friday? *NO*: We will cancel the *Thu Oct 27 call* that would have been during IIW. Approve minutes Approve minutes of UMA telecon 2016-10-06 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06> : APPROVED by acclamation. Work on UMA.next issues Sec Considerations: 7.1 and 7.3 do seem somewhat related, and could usefully be put closer together and conceptually brought closer together somehow. Also, there's a typo in 7.3: Needs to be "authentication and *user mapping* capabilities". Sec Considerations: 7.2 talks about two different OIDC topics. The first paragraph is about one topic ("RECOMMENDED for the authorization server to use OpenID Connect, and to use its mechanisms for stronger client authentication at the token endpoint, in order to strengthen the authentication of OAuth clients."). The second paragraph is about end-user identification; we should break it out. In error_details, Justin's MPD work doesn't have a redirect_user Boolean; rather it has a dynamically provided URL for where the client should redirect the RqP to. Putting this information in the response could mitigate a discovery document attack, according to some in the OIDC – this attack is the basis for the AS mixup attack. On the other hand, a client registering a callback is a case of using static-ness on the other side to mitigate attacks. Another (potential?) benefit is that the AS could bind state to the URL, making it different every time. The static declaration does make it possible to proactive send the end-user RqP to an interaction with the AS, though the spec doesn't explicitly remind people that it's possible the way it explicitly reminds people that it's possible to proactively push claims to the RPT (now token) endpoint. Options: 1. Keep static declaration of requesting party claims endpoint in config data document and don't add to AS need_info response to client (status quo) 2. Keep static declaration and ADD to AS response 3. DROP static declaration and ADD to AS response *Decide next time on which option to choose.* Regarding 3.2.4: What is the expectation about the AS providing more information about the exact resource set IDs or scopes that were at fault? Would it be a good idea to provide more guidance around error descriptions that could accompany UMA errors? Development time and deployment time are different things; would end-users see these errors? Instructions: - Address Sec 7.1 and 7.3 comments above. Will take some thought. - Address Sec 7.2 comments above. - Make an ISSUE around analyzing the spec for what its effective "operational modes" are. Look for all MAYs and natural dividing lines, and be sure to document a rationale for every MAY if possible. - Change title that has "Consent" in it to "Authorization" - Sec 3.2.4: Should be "Any one of the provided resource set identifier *s*". Attendees As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Robert 4. Eve 5. Cigdem - researcher - new to the call! 6. Sarah Non-voting participants: - Adrian - Andrew - George - James - Scott F - Jin - Justin - Ishan Regrets: - Andi - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA presentation at IIW
by George Fletcher 13 Oct '16

13 Oct '16

Hi, Here is the deck I plan to use to talk about UMA at IIW the week of 10/24. Any feedback gladly accepted:) http://www.slideshare.net/CloudIDSummit/cis-2015-user-managed-access Thanks, George -- Distinguished Engineer Identity Services Engineering, AOL Inc. Mobile:+1-703-462-3494 Office:+1-703-265-2544

1 0

UMA Core editors' draft 04 is up
by Eve Maler 13 Oct '16

13 Oct '16

Sorry for the tardiness; it's been a long few days! https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-04.html Diff set is here (everything dated Oct 12); sorry, I don't know how to tag stuff in a non-master branch... https://github.com/KantaraInitiative/wg-uma/commits/04-edits Got to more stuff than I thought I would, but less than I strictly hoped. Lots of good stuff to discuss tomorrow. Please do take a quick review. Things to note especially: - Code examples and ASCII diagram now have proper line breaks, and I even caught/fixed a JSON bug through this tool <https://jsonformatter.curiousconcept.com>. - All the stuff we discussed last week <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06> is addressed in some fashion. - How an RS registers for a permission ticket and asks for multiple resource sets is in there <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-03.html#rfc.section.…> Talk tomorrow... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Agenda for UMA telecon 2016-10-13
by Eve Maler 12 Oct '16

12 Oct '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-13 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 - Logistics for upcoming meetings - Next week: moved to Friday - Week after: should we move to Friday given that it's IIW week? - Approve minutes of UMA telecon 2016-10-06 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-10-06> - Work on UMA.next issues - See last week's notes - Core should be up to 04 shortly - Review Domenico's diagrams and the UMA grant flow options - RSR is up to 00 <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-00.html> - New input simplification of the protection API - FB page <https://www.facebook.com/UserManagedAccess/> care and feeding ideas (if time) - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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