- WG-UMA - mailman.kantarainitiative.org

Notes from UMA telecon 2016-07-14
by Eve Maler 14 Jul '16

14 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-14 MinutesRoll call Quorum was not reached. But we had great "critical mass" for rough consensus... Approve minutes Approve minutes of UMA telecon 2016-06-30 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-30> , 2016-07-07 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07>: deferred. MPD A lot of the simplifying decisions in MPD have come from IoT. Some work Eve is involved in is IoT use cases. Consumer IoT devices influence RS and client scenarios quite a bit in health, e.g. More to come on that, no doubt. *Trust elevation:* We've discussed a variety of scenarios in the past where the trust elevation mechanism might be extended to account for others' needs. We want to be sure to still be capable of that. MPD thinking: The claims/interaction endpoint is becoming a be all/end all interaction endpoint, and should be used for all interaction (is the theory). What was an (UMA) RPT endpoint that accepted JSON is now, in MPD, the OAuth token endpoint that accepts forms with key value pairs. Indeed, the UMA inputs were simple strings. The scenarios for extension included things like: - Smart contracts that the (UMA) client/RqP is bound by - The environment exhibited by the client/RqP that the AS can detect - For contextual types of step-up authentication for complex auth loops or chains? It could be that working within the simple structure of key/value pairs of forms is fine. We can write it up and ask for feedback. *Naming questions ("phrasing!"):* Let's understand all the naming opportunities/issues first, then name them in concert later. Some challenges: - resource set, protected resource, resource... - client, Client, UMA client, OAuth client... - relying party, requesting party, resource server, client... - (newer) UMA refresh token, (who know what else?) consent token, something else... - registering permissions, registering a ticket, registering resource set(s) for getting a ticket... *Registering multiple resource sets (while getting a permission ticket):* Justin prefers the common case of registering a single resource set. Mike plays devil's advocate; in LDAP, you have multi-valued things, so he assumes arrays anyway. Otherwise the AS has to check whether the thing he's getting is single-valued or not. (The ghost of) Nagesh prefers all arrays. Do we need more inputs on this? Mike thinks it doesn't make or break either way. Justin thinks there's a different syntactical approach we could take vs. arrays entirely. Kathleen had been discussing consent structures in RDF-OWL, which could be associated with resource sets. Even if we don't go this far, because it could trip up AS interop, could it be an extensibility point? Actually, our discussion on June 23 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-06-23> *might* have been in the wrong direction because we're actually talking about registering resource sets and scopes in the context of getting a permission ticket – not original RSR. Those who have an alternative to propose vs. this one <https://08620661282160442115.googlegroups.com/attach/f218681b41266/draft-um…> should send it to the list for consideration by next week. Regrets for next week: Andi, Domenico. Regrets for the following week: Andi, Justin. Attendees As of 14 Jul 2016 (pre-meeting), quorum is 7 of 12. (Domenico, Kathleen, Sal, Nagesh, Andi, Robert, Paul, Agus, Maciej, Eve, Mike, Sarah) 1. Domenico 2. Sal 3. Andi 4. Eve 5. Mike 6. Sarah Non-voting participants: - James - Justin - François - Scott - Arlene Regrets: - Maciej - John *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: UMA telecon 2016-07-14
by Eve Maler 13 Jul '16

13 Jul '16

I'm sorry I haven't published a formal agenda yet; been heads-down on a work fire drill. However, we are definitely meeting tomorrow and pressing ahead on our MPD discussions and related protocol decision making. Please see last week's notes (http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-07) for relevant links and dial-in details if I don't manage to send out something formal in time for the call. Thanks! Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

1 0

Re: [WG-UMA] [projectvrm] Pokemon teaches us why all of us will need our own Authorization Server
by Doc Searls 13 Jul '16

13 Jul '16

Good example. Suggestions for getting in front of publishers and demonstrating how tracking protection helps them are welcome. I should add that maybe Don has had some luck with this. I sure haven’t. Doc > On Jul 13, 2016, at 2:07 PM, Guy Higgins <guy.higgins(a)performance2.net> wrote: > > Doc, > > Your observation reminds me of the story of the creation of the Harris > Corporation. The company was started by a couple of brothers who thought > that they could help companies become more productive by building a > machine to automate the envelope-stuffing process (this was, of course, > way back in the days of snail mail marketing and stone knives). They > built such a machine and went around to companies trying to market their > machine, telling the company leadership that their machine could stuff > 15,000 letters an hour. Company after company threw them out the door > before they could even arrange a demonstration ‹ the company leadership > knew it was impossible to get that kind of improvement in one step. > Finally, the two brothers approached a company and claimed that they could > stuff 5,000 envelopes an hour (a third of their actual demonstrated > capability). The manager reluctantly agreed to a demonstration and was > stunned at the actual 15,000/hr letter-stuffing rate. When he asked why > they hadn¹t told him the true rate, they explained that no one had ever > believed them ‹ not quite the same, but the idea is to get in front of a > decision maker and let them discover the benefits. > > Guy > > On 7/13/16, 11:33 , "Doc Searls" <dsearls(a)cyber.law.harvard.edu> wrote: > >> >>> On Jul 13, 2016, at 11:36 AM, Guy Higgins >>> <guy.higgins(a)performance2.net> wrote: >>> >>> Adrian, >>> >>> Your closing question is, perhaps, the most critical of all questions >>> in this area. Upton Sinclair captured the tension perfectly, ³It is >>> difficult to get a man to understand something, when his salary depends >>> on his not understanding it.² >> >> This is exactly the problem some of us experience when trying to convince >> publishers that, for example, tracking protection is good for them. Their >> salary depends on not understanding that ‹ and will continue to do so >> until they finish getting screwed by adtech at all costs, and the salary >> goes away. >> >> Doc >>> >>> >>> Guy >>> >>> From: <agropper(a)gmail.com> on behalf of Adrian Gropper >>> <agropper(a)healthurl.com> >>> Date: Wednesday, July 13, 2016 at 7:07 >>> To: "wg-uma(a)kantarainitiative.org WG" <WG-UMA(a)kantarainitiative.org>, >>> ProjectVRM list <projectvrm(a)eon.law.harvard.edu> >>> Subject: [projectvrm] Pokemon teaches us why all of us will need our >>> own Authorization Server >>> >>> >>> https://www.buzzfeed.com/josephbernstein/heres-all-the-data-pokemon-go-is >>> -collecting-from-your-phone?utm_term=.pmzKLWaD1#.prLqPbnwM >>> >>> 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/ >>> >> > >

1 0

Re: [WG-UMA] [projectvrm] Pokemon teaches us why all of us will need our own Authorization Server
by Doc Searls 13 Jul '16

13 Jul '16

> On Jul 13, 2016, at 11:36 AM, Guy Higgins <guy.higgins(a)performance2.net> wrote: > > Adrian, > > Your closing question is, perhaps, the most critical of all questions in this area. Upton Sinclair captured the tension perfectly, “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” This is exactly the problem some of us experience when trying to convince publishers that, for example, tracking protection is good for them. Their salary depends on not understanding that — and will continue to do so until they finish getting screwed by adtech at all costs, and the salary goes away. Doc > > > Guy > > From: <agropper(a)gmail.com> on behalf of Adrian Gropper <agropper(a)healthurl.com> > Date: Wednesday, July 13, 2016 at 7:07 > To: "wg-uma(a)kantarainitiative.org WG" <WG-UMA(a)kantarainitiative.org>, ProjectVRM list <projectvrm(a)eon.law.harvard.edu> > Subject: [projectvrm] Pokemon teaches us why all of us will need our own Authorization Server > > 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/ >

1 0

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