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

Agenda for UMA legal telecon 2016-07-22
by Eve Maler 21 Jul '16

21 Jul '16

Yay, we're finally having a meeting again! Please let me know if you *can't* make it. Please *read* the Primer in preparation. http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… Date and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 / US +1-805-309-2350 / international lines <https://www.turbobridge.com/join.html> / web 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 2016-07-22 - Review UMA Roles and Responsibilities Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Questions about MPD
by James Phillpotts 21 Jul '16

21 Jul '16

Hi all, As per chat in the join.me session, I have a couple of questions/observations about the MPD flow we have been discussing: - Why are we using the Authorization Grant for the ticket, which is actually the context for the forthcoming authorization that the AS has to assert? Should we be initiating the Client's interaction with the AS at the Authorize endpoint, rather than the token endpoint? - How can the Client maintain a "token session" for Bob so that he doesn't have to reassert claims (and potentially, consent for claim use) every time he gets a new ticket for a future request? It was suggested after the call ended that we could send a consent token that the Client can send back with future requests. Could we issue a signed jwt token (analagous to OpenID Connect id_token, but issued by the UMA AS for presentation back to it, complete with all claims thus far acquired)? Cheers James

3 8

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

20 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-21 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-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> - Review spec editing and logistics progress - 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> - Trust elevation extension mechanisms and MPD - Including multiple resource sets while registering for a permission ticket - See proposed permission registration extension text <https://08620661282160442115.googlegroups.com/attach/f218681b41266/draft-um…> - 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

FYI
by John Wunderlich 19 Jul '16

19 Jul '16

http://securityaffairs.co/wordpress/49472/data-breach/data-breaches-healthc… Sincerely, John Wunderlich @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

Must cancel tomorrow's UMA legal call, with regret
by Eve Maler 19 Jul '16

19 Jul '16

I'm sorry about the string of cancellations of this meeting series, but I've been cordially required to attend a meeting in our HQ :-) and that takes precedence... Are people available for an ad hoc replacement call next *Monday or Tuesday* at 9am PT/noon ET/5pm UK/6pm CET? Please send me a private note with your availability by tomorrow and I'll schedule something if it looks doable. We've been doing so well on the Primer and I'd like to push it (and our definitions and clauses) forward. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Documenting UMA publication workflows
by Eve Maler 18 Jul '16

18 Jul '16

Hi folks-- Hope you are enjoying post-Christmas reentry or more holiday time, or whatever the case may be. Maciej and I are working on publishing the new Recommendations, and due to that, I unearthed the permanent/symbolic link information that I promised to Justin; we thought it would be a good idea to document the processes here -- and in the GitHub readme... It seems to work pretty well for now given that there isn't that much to the entire publishing process for our WG or others, but if you see ways to improve it for the future, let us know. After completing a draft spec revision cycle and getting it approved: 1. Edit the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources to change from Status #3 to #4 (see below), leaving the previous date in place. 2. Run the stylesheet over the XML sources to produce .html outputs, review the results as required, sync GitHub, and upload the last drafts by FTP (Eve and Oliver can do this). 3. Save the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with rec- instead. 4. Change the Status section of the new files from #4 to #5, the date, and any other metadata (some of this has to be done in the stylesheet, which is in the repo). 5. Update the two specs' References links to each other in the Reference section. 6. Run the stylesheet over the XML sources to produce HTML output with .html extensions, review the results as required, sync to GitHub, and FTP the HTML results to the website (Eve and Oliver can do this). 7. Get symbolic links created (see below) from the versioned rec- HTML links to generic links (Oliver can do this). After launching a new draft spec revision cycle: 1. Save the rec-uma-core-vn_n[_n] and rec-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with draft- and having the agreed new version numbers instead. 2. Edit the Status section from #5 to #1. 3. Proceed to edit the new drafts, and periodically produce HTML results that can be uploaded through FTP. 4. Get symbolic links created from the versioned draft- HTML links to generic links (Oliver can do this). Here are the stages of the Status section (embed links throughout as appropriate): 1. This document is a draft technical specification produced by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 2. This document is a Kantara Initiative Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 3. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. 4. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. The Ballot having passed, this document has been superseded by the Recommendation version of the document. 5. This document was developed by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and approved by the Membership of the Kantara Initiative <http://kantarainitiative.org/> as a Recommendation. Here is how the symbolic links work: https://docs.kantarainitiative.org/uma/rec-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-vn_n[_n].html - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-vn_n[_n].ht… - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/rec-uma-core.html - Symbolic link to latest Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg.html - Symbolic link to latest RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core.html - Symbolic link to latest Core draft https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html - Symbolic link to latest RSR draft *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 2

Re: [WG-UMA] Pokemon teaches us why all of us will need our own Authorization Server
by Adrian Gropper 14 Jul '16

14 Jul '16

Hi Kazue, Thank you much for turning this up. It's an even stronger example of why we can't trust any authorization server we don't specify (and can change) ourselves. Folks may remember that I recently posted about a similar experience with my Dropbox where I had no recollection of allowing Microsoft Word full access to my entire Dropbox. The mechanism that allowed that to happen may be different than Pokemon's link to Google, but that hardly matters. Frankly, I find it amazing that the UMA group, the HEART group, and even VRM are still treating the user-specified authorization server as a "nice-to-have" MAY instead of a MUST. As far as I'm concerned, the only sustainable path for both OAuth and VRM is to build on top of a user-specified authorization server. I have referred to this as: "There's only one Alice." Standards like UMA, HEART, and VRM that don't take this as a given are unlikely to scale or to drive competition and substitutability that make for an effective standard. Adrian On Thursday, July 14, 2016, Kazue Sako <k-sako(a)ab.jp.nec.com> wrote: > Hi Andrian and Doc, > > This seems to have an interesting point regarding use of OAuth where many > people here are familiar with. > > A friend of mine showed me an interesting link. > http://ericrafaloff.com/pokemon-go-and-google/ > > As google is using OAuth, the usual flow should show the user a consent > screen. Yet this was not the case with Pokemon Go. > > >Meaning authorization servers by big companies acting on persons’ behalf. > In this case Nintendo (Pokemon Go parent) and Google. > > Actually, Pokemon Go was developed by a company called Niantic which was a > part of Google at the time they developed Ingress (according to the link > above). > > Kazue Sako > > ________________________________________ > > On Jul 13, 2016, at 9:07 AM, Adrian Gropper <agropper(a)healthurl.com > <javascript:;>> wrote: > > > > > https://www.buzzfeed.com/josephbernstein/heres-all-the-data-pokemon-go-is-c… > > Here’s the link without the tracking cruft: > > > 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. > > Meaning authorization servers by big companies acting on persons’ behalf. > In this case Nintendo (Pokemon Go parent) and Google. > > > If Pokemon wants access to my Google stuff, they need to ask my > authorization server and not the one Google helpfully gave to me. > > Meaning one you operate personally. > > Does one exist? Do we have an example or a prototype among all our > developments here? (I’m so snowed under looking at all of it that I confess > to being a bit lost?in a good way.) > > > Is there any other alternative? How could Google's ever play both sides > as both game developer and privacy protector? > > That’s the right question. The answer has to come from our sovereign > personal whatever (authorization server is a good term, but it needs to be > distinguished from the same operated by giant companies playing both sides). > > And the Castle Doctrine needs to apply. <http://bit.ly/3stldoc> or < > http://j.mp/cstl3> > > Doc > > > 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/ > > > > -- 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/

3 4

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