- WG-UMA - mailman.kantarainitiative.org

Agenda for UMA telecon 2016-03-17 (still in "summertime skew")
by Eve Maler 17 Mar '16

17 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-17 Date and Time - *Thu Mar 17,* 9-10am PT (*N.B.:* North America has changed to Daylight Savings Time; *THIS WEEK AND NEXT ARE ABNORMAL*) - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-03-10 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-03-10> - Issue 239 materials: report out and final conclusions if all goes well - "Why UMA?" AI report and discussion - Wide ecosystem: time to push this forward? - Charter-bashing <https://docs.google.com/document/d/1cv7MLdpC1SMubREbZX7L8E4YUPCAzKPwOCFBky6…> (if anyone has done any homework...) - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Final ad hoc call to discuss issue #239 and make recommendations is scheduled for Thursday
by Eve Maler 16 Mar '16

16 Mar '16

We'll meet during the hour just before our regular WG call on Thursday. (Remember summertime skew! If you want a calendar invitation and didn't yet receive one, let me know and I'll add you.) Goals: Decide what to recommend on the new mitigation idea, review latest changes (still to be made) on the extension spec, and review the non-normative doc. It would be awesome to get a suitable quorum on the WG call to review the recommendations and get consensus, so we can "go public" properly with all this stuff right away. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

Fwd: Sedona 8th Annual Int’l Programme on CB Discovery, 7-8 June 2016 – Now Accepting Applications for Invitations
by John Wunderlich 15 Mar '16

15 Mar '16

May be of interest Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca ---------- Forwarded message ---------- From: The Sedona Conference <igg(a)sedonaconference.org> Date: 15 March 2016 at 10:47 Subject: Sedona 8th Annual Int’l Programme on CB Discovery, 7-8 June 2016 – Now Accepting Applications for Invitations To: John Wunderlich <john(a)wunderlich.ca> [image: Logo] [image: Facebook] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> [image: Twitter] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> [image: LinkedIn] <https://thesedonaconference.org/sites/sedona.civicactions.net/modules/civic…> The 8th Annual Sedona Conference International Programme on Cross-Border Discovery and Data Protection Laws 7-8 June 2016 Berlin, Germany [image: Apply Now] <https://sedona.civicactions.net/sites/sedona.civicactions.net/modules/civic…> ------------------------------ NOW ACCEPTING APPLICATIONS! The Sedona Conference is returning to Europe for its 8th Annual International Programme on Cross-Border Discovery & Data Protection Laws, to be held at the Hotel Adlon Kempinski in Berlin, Germany on 7-8 June. Programme Topics Include: - Key Changes to the EU-U.S. Cross-Border Discovery Framework: A practical look at the effects the new European legislation will have on EU-U.S.cross-border transfers in the context of litigation, government investigations, and internal investigations - Safe Harbor After the European Court of Justice (ECJ) Ruling: How did we get here and where are we going? A look back at the developments that brought us to the invalidation of the original Safe Harbor adequacy decision, what changed, and what to expect from the new EU-U.S. Privacy Shield - The Microsoft Ireland Case: Implications for the way the U.S. addresses data protection and the potential effects on cross-border discovery - The Application of Technologies in Data Protection: A dialogue on how technology can support data protection compliance For the Programme agenda and a list of faculty members, along with biographies, please click here to visit the Programme webpage <https://sedona.civicactions.net/sites/sedona.civicactions.net/modules/civic…> . The Programme is by invitation only to ensure a proper balance of participants, and participation is limited to ensure we have an intimate environment for meaningful dialogue. Please click here <https://sedona.civicactions.net/sites/sedona.civicactions.net/modules/civic…> to apply for an invitation to the Programme. We have secured a highly favorable group rate of EUR 240 per night on a limited block of Deluxe Rooms at the Hotel Adlon Kempinski for the evenings of 6-8 June 2016. The group rate also is available for the four days preceding (2-5 June) and the three days following the Programme (9-11 June), but completely subject to room availability because there is no room block for these nights. Complete hotel reservation information will be provided with your Programme registration confirmation email. Accordingly, you should submit an application for the Programme as soon as possible, so we can consider your application and extend an invitation to you to participate in the Programme in a timely fashion. A meet-and-greet reception will be held at the hotel the evening before the Programme begins, Monday, 6 June, from 18:00 to 20:00. Working Group 6 (WG6) members - please note that our traditional half-day WG6 members-only meeting will be held on Thursday, 9 June, from 8:30 – 13:00 (location TBA). 301 East Bethany Home Road, Suite C-297, Phoenix, AZ 85012 Phone 602-258-4910 Email info(a)sedonaconference.org Copyright 2016 The Sedona Conference You are currently signed up to receive newsletters. To unsubscribe click here <https://sedona.civicactions.net/index.php?q=civicrm/mailing/optout&reset=1&…> If you would like to resubscribe to receive emails from The Sedona Conference click resubscribe <e-3433-2398873-ca323f776eb82fd6@thesedonaconference.org?subject=I%20would%20like%20to%20resubscribe%20to%20TSC%20emails&I%20would%20like%20to%20resubscribe%20to%20TSC%20emails> -- 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

Neato privacy policies
by Eve Maler 14 Mar '16

14 Mar '16

On today's call, I mentioned a cool privacy policy I ran across when I downloaded this app: http://buddhify.com/privacy-policy/ The app costs $4.99, and I carefully looked at the policy and decided I was very willing to pay money -- and they were making the tradeoff very worthwhile. They based the policy closely on this (both are CC-licensed -- hooray for DRY content!): https://automattic.com/privacy/ BTW, the app is awesome too. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

5 24

[legal] Naming trust relationships before we define them: please review and respond
by Eve Maler 14 Mar '16

14 Mar '16

In today's legal subgroup call, we spent some time discussing which trust relationships are in our purview to "define" with model clauses. Adrian proposed a name for one of them. It seems like a great idea to name the trust relationships we're responsible for, partly as a shorthand for ourselves but also definitely useful for our "customers". (I also wonder if there's a conundrum here -- or maybe it's an easily solved one -- in that UMA builds up some two-party relationships into complex three-party relationships. Do we care? We have previously said that our clauses would all be two-party, with preconditions, so maybe it's as simple as that.) In order to make progress prior to next week's call, can we enumerate and try to name the relationships in email? I made a partial list of them in the notes. Here's an attempt at a more complete one in rough order of UMA flow, with our new terminology as best as I can apply it, and also with some naming proposals/discussion. (Some are "offstage" wrt our work, meaning we're not responsible for these agreements.) - Resource Subject - Grantor if they are different - This is "offstage" - RSO - ASO - Technical artifact that represents it: issuance of the client ID by the AS - Name proposal ("brute force" :-): "Protection API client agreement"? - Grantor - ASO - This actually exists prior to bringing in any specific RS connections; it's the inherent reason for the service. - Name proposal: "Authorization services agreement"? - Grantor - RSO - Any agreement a user might have with an online service might be "offstage" until the connection with the AS comes into the picture, either because of the ecosystem at large (prior arrangement) or because there's a moment where the AS and RS get sewn together with a protection API token (dynamic in some fashion) - Adrian has proposed "resource registration agreement"; I think I favor "resource protection agreement", because it should cover not just the phase 1/resource registration but also phases 2 and 3/all the respecting-the-token stuff - Client Operator - ASO - Technical artifact that represents it: issuance of the client ID by the AS - Name proposal: "Authorization API client agreement"? - Note that the Client Operator is not Bob, but the Person that created the client software or runs the client service - "Requesting Party" (for now) - Client Operator - This is "offstage" - "Requesting Party" (for now) - RSO - This is "offstage" - "Requesting Party" (for now) - ASO - Any agreement a user might have with the AS as some other kind of online service might be "offstage" until the connection for the purpose of it being an AS comes into the picture, either because of the ecosystem at large (prior arrangement) or because there's a moment where the AS and RqP get sewn together with an authorization API token (dynamic in some fashion) - Name proposal: "resource authorization agreement" to be parallel with my proposal above, and in keeping with the API names - Grantor - "Requesting Party" (for now) - This is the end-to-end trust relationship UMA really exists to make happen! :-) - Perhaps fine-grained legal agreements here could be captured as reciprocal consent receipts? - Name proposal: "resource sharing agreement" or "resource access agreement" If we can get on the same page about this stuff, does it make sense to publish a short paper explaining it for external readers? It would be a great artifact, particularly as we're getting close to our "end of Q1" deadline to present external reviewers with something to review. Notice that throughout, there's a legal context at which we're operating, and a corresponding technical context that it seems useful to refer to *but probably only non-normatively*. How should we handle that? Should we put it in "Comments" in our model definitions? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

Notes from UMA legal telecon 2016-03-11
by Eve Maler 11 Mar '16

11 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-03-11 - Do these terms work for us as model definitions? - Resource Subject: Person to whom a digital data resource relates - Grantor: Person who manages access to a resource, either as its Resource Subject or that Person's behalf - Grantee: Person seeking access to a resource - How to address the subject/grantor split in the tough use cases - Tackling model clauses for RO/RSO - Does the brute force method help? - How can we address #RSctrl and #ROctrl needs – can we actually enumerate the exceptions? Attending: Eve, Kathleen, Scott, Adrian, John W, Jim, Mary, Andrew, Thomas, Mark, Maciej (As an aside, the fact that we're using Thomas's paid join.me account and had trouble reusing it because multiple people on the call have the app is an interesting "property rights" use case that is relevant to our problem! There's the potential for misuse of the paid account and the company often stomps on simultaneous use.) Under consideration: Resource Subject: The Person to whom a digital data resource relates Grantor: The Person who manages access to a digital data resource, either as its Resource Subject or on that Person's behalf Grantee: The Person seeking access to a resource Is Grantee too "final" (vs. Requesting Party) given that they haven't yet been given access/had trust elevated? Maybe we need to split the RqP language similarly into two, to capture the states of "authorization not granted" and "authorization granted". To take an extreme example, there could be a policy condition that Bob the RqP gets access to some resource only on even-number hours of the clock. In this case, the AS can manage the token time-to-live characteristics very dynamically, the RS can check all the token authorization data frequently, etc. – but Bob will go from being a "potential Grantee" to being an "actual Grantee" really frequently. So the former phase or state is the more persistent, and the latter is the more transient. Trust elevation and degradation in Bob can be quite dynamic. (Also note that the same is true for the client app Bob uses.) Note that any trust relationship between the (requesting party bundle of concepts) and the Resource Server Operator is entirely invisible to UMA. According to our scoping of our work, it should likely be invisible to us too. ?? But the (requesting party bundle of concepts) and the Authorization Server Operator does have a trust relationship once the authorization API token is issued, so we need to take care of that set of obligations. - RSO - ASO (client ID) - RO (Subj/Grantor?) - RSO - ASO (PAT) - C - ASO (client ID) - RqP (trust elev/degr?: Grantee) - C - ASO (AAT) - RqP (trust elev/degr?: Grantee) - RSO = no UMA relationship ??? The "Adrian clause <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#give-access>" in the UMA Core spec is intended to reassure RSO's that they are free to elevate trust in the "requesting side" (that is, both the RqP and C) themselves. Note that the phrasing in the spec only allows further tightening; a clause a bit lower down makes clear that the intention is not for the RSO to enable *loosening* of access, although it's impossible in technical terms to prevent this. This is why we are working on how far we can take our model clauses to give RSOs the appropriate (and not *inappropriate*) flexibility to manage liability. Eve suggests a group norm: Let's talk about "notice" and "consent" as consent life cycle words, and "notification" as what happens apart from that life cycle, so heads don't explode. We agree on these model definitions for now: Resource Subject: The Person to whom a digital data resource relates Grantor: The Person who manages access to a digital data resource, either as its Resource Subject or on that Person's behalf We have discovered an important "phase split" in considering "Grantee", and can't really use it outright as a wholesale replacement for Requesting Party. For the world of devices, client apps, and so on, should we introduce "Agent"/"Entity"/something? Eve is wary of Agent from our legal discussions, but Kathleen could submit ideas to the list. Eve reviewed her "brute force version <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/ld7QQPycj…>" of the "RO-RSO" trust relationship. Note that the last bullet is the only one that represents a break-glass scenario; the party seeking access never established a trust relationship with the ASO, never got into the position of being a RqP/Grantee/etc., and is unknown (at least as far as UMA is concerned) to the RO. Adrian has introduced the term "resource registration agreement". Is this a good name for the overall agreement representing this trust relationship? ("Resource protection agreement"?) How do we square the circle of having two "three-party" trust relationships? How should we name each of the trust relationships? Let's try and bat this around on the list before the next meeting. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Who is interested in one final ad hoc call on issue #239 deliverables before next Thursday?
by Eve Maler 11 Mar '16

11 Mar '16

We have a normative spec (which I'd like to rev for consideration based on our conversation at the tail end of yesterday's call), a non-normative doc, and a new idea for a mitigation (which may or may not pan out but needs substantive discussion). All this could use a solid hour of time, which is tough to get on a regular call. Noting that next week we are *in summertime skew already* (North America springs forward while others don't yet), would one of these times work? - Monday 9am PT for 60 minutes - Tuesday 9am PT for 60-90 minutes - Thursday 8am PT for 60 minutes (that is, the hour before our WG call) Please respond privately to me ASAP, and I'll send put out a winning calendar entry with personalized invitations to those who can make it. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal telecon 2016-03-11
by Eve Maler 11 Mar '16

11 Mar '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes Date and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:**IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar 2016-03-11 - Do these terms work for us as model definitions? - Resource Subject: Person to whom a digital data resource relates - Grantor: Person who manages access to a resource, either as its Resource Subject or that Person's behalf - Grantee: Person seeking access to a resource - How to address the subject/grantor split in the tough use cases - Tackling model clauses for RO/RSO - Does the brute force method help? - How can we address #RSctrl and #ROctrl needs – can we actually enumerate the exceptions? Attending: ... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

[legal] The brute-force method of specifying what a RO wants (when it comes to a RS/RSO)
by Eve Maler 11 Mar '16

11 Mar '16

Mark L and I were IMing a couple of weeks back, discussing some of the things that could constitute "consent instructions" in UMA. I ended up typing out what I thought of as what Alice (y'know, the resource owner or her proxy/guardian/agent :-) wants some RS operator "X" to do on her behalf in "plain English": - Form an agreement with me and my AS operator "Y" to put some set of resources managed by me under the protection of that AS - I might or might not have had a choice about which AS I use, or which AS operators this RS operator will work with. But once we make this agreement, any of my resources that get registered for central protection do have to be under "Y"'s protection for realsies -- and I'm going to be telling "Y" how to protect the resources so they know what to put in the token that the RS eventually gets. - Within normal UMA operations, in the general case, have the RS do what the token from "Y" says to do when a client seeks access -- that is, give access when it says to and deny access when it says to, on the basis of what the client was attempting to do - Within normal UMA operations, in *limited* circumstances (tbd to be enumerated by us if possible, with model clause support????), enable the RS to deviate -- that is, to give access when the RPT says to deny access and to deny access when the RPT says to give access - Possibly requiring the RS to send a notification message somewhere (tbd????) - Outside normal UMA operations, in *limited* circumstances (tbd to be enumerated by us if possible, with model clause support????), enable the RS to give access on request - Possibly requiring the RS to send a notification message somewhere (tbd????) This is pretty much what I as a human being would expect UMA to "mean" wrt a RSO, giving them just enough of an "out" in case they have to live up to laws in their jurisdiction etc. Is this helpful in the spirit of having both Creative Commons human-readable and lawyer-readable text? :-) Should I keep going and write a brute-force list for what the RO/ASO relationship should "mean" and so on? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Summertime skew is coming
by Eve Maler 10 Mar '16

10 Mar '16

There is a roughly two-week period starting -- if my calculations are correct -- next week, when North America and other parts of the world experience what I refer to as "summertime skew" (as in "There ain't no cure for the...") because we all start/end daylight saving time on different dates. This group treats North America as canonical because, well, it's where I live. :-) So please doublecheck the Kantara UMA WG calendar <http://kantarainitiative.org/confluence/display/uma/Calendar>, and/or be sure you have calendar invites for our WG/legal calls showing on your own personal calendar, and/or get onto the UMA Chat on Skype, and/or browse timeanddate.com, and/or do whatever else is necessary not to miss a call during this weird period if you like joining the calls and not missing them by that much <https://www.youtube.com/watch?v=oPwrodxghrw>. If you have questions, please let me know. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0