- WG-UMA - mailman.kantarainitiative.org

Pokemon teaches us why all of us will need our own Authorization Server
by Adrian Gropper 13 Jul '16

13 Jul '16

https://www.buzzfeed.com/josephbernstein/heres-all-the-data-pokemon-go-is-c… This may well have been a case of accidental social engineering but it makes the point that multiple random authorization servers will not scale. If Pokemon wants access to my Google stuff, they need to ask my authorization server and not the one Google helpfully gave to me. Is there any other alternative? How could Google's ever play both sides as both game developer and privacy protector? 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/

2 1

Why won't they pay for privacy?
by John Wunderlich 11 Jul '16

11 Jul '16

Cross posted to a couple of lists. I think that there is an important lesson to be drawn from the Blackphone story (below). While the Blackphone is architected for privacy, the way that that was done reduced user choice (first version without access to the Google Play store). This increased friction and difficulty. Privacy and security are the first items on most peoples' and most organizations' secondary wish list. So long as user experience change is neutral or positive, privacy and security will have a potentially broad appeal. Additional work, effort or friction will doom the product or service to niche status. This explains the roaring success of ad blockers for example. Not only are they dead easy to install, their maintenance and update depends on black lists maintained by someone other than the user. On top of that, ad blockers actually improve the user experience. In the CISWG, as we get close to a spec for consent receipts, and with the current version off to a spec writer, we now have to start thinking, it seems to me, about how we can present a value proposition that works for for both users and enterprises? Compliance is insufficient. And how will reference implementation of consent receipts and user submitted terms look like an immediate win to a user? I wonder how much of the same logic applies to UMA? https://www.theguardian.com/technology/2016/jul/08/we-know-people-care-abou… John Wunderlich, Sent frum a mobile device, Pleez 4give speling erurz "...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin -- 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

Draft minutes of UMA telecon 2016-07-07
by Eve Maler 07 Jul '16

07 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2016-06-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30>: Deferred. Logistics Mike speaks in favor of regular 60-minute calls and additional ad hoc calls among, say, spec editors and interested others. Robert and Justin agree. Okay, we seem to have consensus around that. Justin has little availability for an editing session next week; Eve will suggest some times for a kickoff session the week of July 18. MPD writeup The "claims" endpoint is really the "interaction" endpoint for all purposes. Justin has introduced a new idea of an "UMA refresh token" (URT!) as a static refresh artifact along with the client presenting the ticket at the token endpoint, to signal a cross-session RqP relationship with the AS. This would be used in concert with a one-two punch of gathering consent at the claims endpoint and then pushing claims at the token endpoint. Eve wonders about the name: It represents the RqP's persistent consent or authorization, even if its function at the AS might be to "refresh" something. James suggests: consent context token. We have a lot of naming issues to sort out, so let's not decide right away. *We have consensus* to proceed with spec text for a mechanism that keeps consent "in-band" vs. "out of band", by virtue of a "token-ish" method that the client uses to preserve the AS's memory of the RqP. If the AS doesn't issue an urt-ish thing, then consent must be sought every session. What about Alice-to-Alice sharing? If she's sent to the claims endpoint, would we anticipate that it would be collapsed into an authorization endpoint as well, and then have it hand out (say) authorization codes in addition? The client wouldn't be expecting that; it's expecting a ticket. Ultimately, Eve had a re-epiphany about the lack of a need for any special treatment of Alice as an RqP; Alice as an RO can simply make policies about "herself as an RqP" (and the AS could, if it wishes, handle various Alice-to-Alice cases specially if it wishes). Justin would, however, like to see some experimentation where there's some confluence of the two endpoints. We discussed the "Allow ID Tokens as RPT" thread. An AS needs to have an identified and authorized RqP. Strictly speaking, does that mean the user needs to be "logged in"? James defines this as having had an interactive authentication experience, which his implementation doesn't require; it all depends on what auth modules have been leveraged. Justin's read of the meaning of "logged in" is broader, just meaning "has an authentication session". We didn't quite get to the topic of trust elevation extension mechanisms, but this will depend on how the spec text shapes up. 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. Sal 3. Nagesh 4. Robert 5. Maciej 6. Eve 7. Mike 8. Sarah Non-voting participants: - Justin - Adrian - Colin - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-07-07
by Eve Maler 06 Jul '16

06 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07 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 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 Agenda - Roll call - Approve minutes of UMA telecon 2016-06-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30> - Logistics - When/how to extend our design time? - 8:30-10am PT calls on Thursdays - 9-10:30am PT calls on Thursdays - Additional calls on other days - Multiple options - How about going long on today's call? - Spec editorship duties - 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> - MPD writeup on consent - Is doing consent later okay? - Is doing consent OOB okay? - Would an "UMA refresh token" alternative make any sense? - The Alice-to-Alice sharing mechanism in light of MPD - Trust elevation extension mechanisms and MPD - 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

No UMA Legal telecon next week (July 8)
by Eve Maler 05 Jul '16

05 Jul '16

I vaguely thought there was a conflict on my calendar for next week, and just realized what it was. I'll be removing that meeting from the calendar. In the meantime, no reason not to go into the Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> to comment!... And if you have a burning desire to set up an alternate time to meet, let me know. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 4

What are your dating and fitness apps sharing about you? - Technology & Science - CBC News
by john＠wunderlich.ca 04 Jul '16

04 Jul '16

FYI What are your dating and fitness apps sharing about you? - Technology & Science - CBC News Source: http://www.cbc.ca/news/technology/access-my-info-1.3644019 (via Mr. Reader) Thanks, John Wunderlich @PrivacyCDN Pleez 4give speling errurs, sent from a mobile device. -- 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

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

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