- WG-UMA - mailman.kantarainitiative.org

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

22 Jul '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2016-07-22 - Review UMA Roles and Responsibilities Primer <https://docs.google.com/a/wunderlich.ca/document/d/1HGM5-PoJFMnepyrTX91hqHK…> Attending: Eve, John, Sal, Ann, Kathleen, Colin, Adrian, Jon, Scott (Maciej regrets) We reviewed the primer and made changes dynamically. We discussed whether "Alice and Bob" are appropriate as standard RO and RqP names, given their history as equal peers in PKI, vs. their asymmetrical nature in UMA. UMA's historical goal is to empower the RO role in an ecosystem fashion a la Eve's 2008 diagram from the Digital Contracts MIT event, even if instances of a running UMA protocol are indeed asymmetrical, since the RO has an "agent" – the AS – working on her behalf whereas the RqP doesn't. Of course, there's an admittedly asymmetrical part of the UMA protocol called trust elevation where the RqP may have to supply or direct services to supply information about themselves, which could be UMA-protected, so the RqP could have an "agent" acting on their behalf too. In short, while they're not peers at an "individual instance of the protocol" technical level, it's possible that they're similarly protected at the technical, contractual, and regulatory layers. Self-regulatory structures are the common theme coming out of the list of "Additional Discussion Topics", which we spent a lot of time on. Some of those structures will be shaped by supply chain necessities – see, for example, how UPS and FedEx end up with similar contractual outputs. We think that once we have our "Tech/Contract/Reg" framework, we could spin out white papers on each of the additional discussion topics, and likely liaise more effectively with the IDoT, IRM, and BSC efforts in Kantara. (Be sure to see the notes so far <http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29…> from the BSC group.) We reviewed the scenario in the Tech section. Scott asked: Do we want to draw the equivalence between the federated identity progress and federated authorization? Eve thinks this depends on whether we're writing for an audience that understands federated identity trust frameworks. Adrian goes by the "There's only one Alice" mantra – the AS shouldn't be "domain" (sector) specific. This is the personal AS viewpoint. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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 14 Jul '16

14 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