April 2017 - WG-UMA - mailman.kantarainitiative.org

Open issues - let's try to work through them by email BEFORE May 12
by Eve Maler 10 May '17

10 May '17

We really don't have a lot of 2.0 issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> left. A few new ones are coming to light now...which is good. The sooner the better. :) BTW, I've just published Grant 03 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-03.html> and FedAuthz 03 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-03.…>, with a bunch of strictly editorial cleanup. Current status: - #303 <https://github.com/KantaraInitiative/wg-uma/issues/303>: JSON usage and OIDC for client authentnication: These security considerations have been removed from the drafts, and it doesn't seem they'd be missed. Unless anyone yells, we'll close this issue for May 12. - #304 <https://github.com/KantaraInitiative/wg-uma/issues/304>: Do we need the invalid_request issue? It would only be for FedAuthz (the protection API). I've taken it out for now. Request messages have their own custom errors for specific things that could go wrong. Basically, yell if you see a need to add it (or any other more-specific errors) back, or we'll close this with no action by May 12. - #306 <https://github.com/KantaraInitiative/wg-uma/issues/306>: Best to keep downscoping undefined when refreshing? I've now included a rationale in the refreshing language in Grant. Given the current state of Grant and FedAuthz, let's plan to close this without action by May 12 unless someone has a problem. - #307 <https://github.com/KantaraInitiative/wg-uma/issues/307>: Lower-priority, but nice to think about since there are already a bunch of profiles and extensions: Should we create a "pseudo-IANA-registry" for profiles and extensions? - #308 <https://github.com/KantaraInitiative/wg-uma/issues/308>: Really kind of low-priority: Should we flatten the innards of need_info to remove the error_details layer? If no one pays attention to this before May 12, let's close without action. - *#310* <https://github.com/KantaraInitiative/wg-uma/issues/310>: NEW and important, highlighted by Mike: Our requirement to have the client pre-register for scopes is likely at least somewhat problematic. See the issue for why. (Domenico, this would potentially affect your Venn...) - *#311* <https://github.com/KantaraInitiative/wg-uma/issues/311>: NEW and would be nice to look at: We go on and on about how the PAT is susceptible to implicit grant threats, but this seems like just a generic OAuth threat (especially with our refactoring now), and everyone is familiar with it. Remove? Please review, and in particular please weigh in on 310, 311, and any other new issues that get submitted between now and our May 12 meeting. Thank you! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Browser Clients in UMA?
by Mike Schwartz 01 May '17

01 May '17

In UMA Grant, any thoughts about including considerations for browser based clients with regard to RPT, PCT and refresh tokens? - Mike

2 1

Re: [WG-UMA] PSD2 as a driver for UMA
by James Hazard 30 Apr '17

30 Apr '17

Kevin, thanks. If I've understood your concern, it is that hosting of the data stores should be independent of financial institutions. My thought is that the data model should work for both (all) situations - the data store can be hosted by a financial institution or by someone else, including by individuals themselves. This, I believe, is how email works - there is a common standard and you can set up your own server for yourself or a group, or have someone else do it. The email interchange standards and open source software keeps this cheap and portable. You can take your email history when you change hosts, so hosts have little leverage. The critical thing seems to be the data model and interchange protocols. Jim On Sun, Apr 30, 2017 at 3:48 AM, Kevin Cox <kevin(a)welcomer.me> wrote: > This is a good start but there are better ways of handling money. > > We do not need AISP (Account Information Service Provider) or PISP > (Payment Initiation Service Provider) any more than we need Identity > Providers. What we need are free apps we are given to look after the > information in our accounts, and for apps to help us to spend our money as > we see fit. We do not need Identity Providers as we are quite capable of > acting on our own behalf and purchasing the tools that enable us to do it > electronically. The apps are free and we use the transaction charges made > on transfer of money to pay for the app development. These transfer > charges will be less than the current transfer charges. > > The cost of operating electronic systems will drop when we get rid of > intermediaries in electronic space that stand between people and between > people and collaborative human entities like companies and governments. We > replace the intermediaries with open source apps. > > Money is the good one to start with because the way we organise our money > system is ridiculously expensive. The savings made with money can fund the > development of other ways of working together in collaborative and > co-operative ways. > > Money is a promise to repay. A promise costs nothing to make. It costs a > lot when the promise is broken and not fulfilled. A promise is zero cost > so why do we charge for the use of zero cost money tokens that represent > the promise? We should not pay to use money tokens. We should pay if we > break a promise. Changing to zero cost money tokens will reduce the cost > of operating an economy by at least 50% and perhaps more. We have become > so used to thinking that money tokens have a value that we forget that cash > tokens have no value. The value is the promise that the government will > accept the money for us to pay our taxes. The idea that money tokens have > to have a value leads to the planned inflation of money tokens, nonsense > cost-benefit studies that rarely predict outcomes, expensive cumbersome > systems like collateralized debt and bitcoin - and these are only the least > harmful. > > We can be truly autonomous in the electronic world but only if we have > electronic ways of working together in small and large collaborative groups > that can handle the situations when some of us break our promises. > > Here is a proposal > <https://medium.com/@kevin_34708/water-rewards-information-rich-money-345ee9…> we > are working on to save the community of 400,000 people in which I live $70M > per year for no cost to the community. An emergent property of the system > will be a safe secure electronic identity for our Co-op members that only > they can access. (PS. It is the reason I am not at IIW) > > Kevin > > > On Sun, Apr 30, 2017 at 1:44 AM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> Agreed. PSD2 and GDPR both require P2P data model. Mentioned here in >> conversation with Eve. https://commonaccord.wordpress >> .com/2017/04/09/prose-objects-for-enterprise/. >> >> A P2P, smart contract and prose object data model for finance could look >> something like: >> http://www.commonaccord.org/index.php?action=doc&file=bqc/fr >> /bnpp/a5we/Account/Check/00001/06-Accept.md >> >> On Sat, Apr 29, 2017 at 5:38 PM, Adrian Gropper <agropper(a)healthurl.com> >> wrote: >> >>> https://www.evry.com/en/news/articles/psd2-the-directive-tha >>> t-will-change-banking-as-we-know-it/ >>> >>> >>> >>> -- >>> >>> 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/ >>> >>> _______________________________________________ >>> WG-UMA mailing list >>> WG-UMA(a)kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>> >>> >> >> >> -- >> @commonaccord >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma >> >> > > > -- > 0413961090 > -- @commonaccord

3 2

PSD2 as a driver for UMA
by Adrian Gropper 29 Apr '17

29 Apr '17

https://www.evry.com/en/news/articles/psd2-the-directive-that-will-change-b… -- 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

Notes from UMA Legal telecon 20017-04-28
by Eve Maler 28 Apr '17

28 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-04-28 - Reviewing draft deliverable #3 - "Resource Regulator" role Attending: Eve, John, Adrian, Kathleen, Tim, Mark, Bjorn Review of Move Fast and Break Things <https://www.theguardian.com/books/2017/apr/26/move-fast-and-break-things-jo…>, recommended by John. (We were talking about turpentine and the importance of something stinging in order to tell that it's working – also "if it hurt, do it more often" from Agile.) *Resource Regulator role:* How would we include Resource Regulator in any charts, if we did? A regulator constrains, by law, what some of the other parties do, in a context of enabling others. In other words, it sets rights and responsibilities. And we can't change these. These are jurisdictional. So a regulator is a sort of "god". It's out of band of the UMA protocol and Eve suggests it's also "out of band" of UMA legal because we can't affect regulatory/public law on any reasonable time scale. Here's what we're doing in this subgroup: 1. Building a legal framework... 2. So that we can next build "toolkits" that are friction-reducing building blocks for various contractual mechanisms ("private law")... 3. So that third parties can deploy UMA-enabled service systems in a manner consistent with protecting privacy rights using those contractual mechanisms that adhere to the laws and regulations ("public law") of their jurisdictions Kathleen points out that in the case of HIEs, e.g. in Michigan, there's a kind of blending of private and public law – there's a contract made among HIE participants that includes 42 CFR Part 2 by value. But that was their choice; by-reference would have probably been better. (Hey, CommonAccord would have helped. [image: (smile)] ) Eve's proposal: We can influence interpretation of regulations (especially now when a lot of GDPR etc. guidance is being written), but let's keep "regulator" lowercase since we can't influence written regulations and laws directly. *Consensus* not to uppercase the Resource Regulator party role. *Roles and splitting:* We have roles that mostly stick to the existing UMA technical roles, with the exception of *splitting* Resource Subject and Resource Owner for now. Once we have some model contracts, we can add nuance in splitting roles. Our previous "party" terms of Authorization Server Operator, Resource Server Operator, and Client Operator weren't about splitting but just about acknowledging the different between "software entity" terms and "party to a contract" terms. *Trust frameworks and access federation:* The only ones we are familiar with that exist (that could potentially accommodate UMA-style – party-to-party – user-centric authorization and "consent directives", vs. just opt-in consent) already are trust frameworks for identity federations, except for the emerging Pan-Canadian Trust Framework and the very new health trust framework efforts that Kathleen has mentioned in the BSC context. The latter work puts the data under the patient's control under the "patient's right of access". There are liability shifts which would result in the motivation becoming stronger for appealing to individuals to ask for data for secondary-use purposes. Interesting situation: For a genome, there's more than just one data subject for the same data set! (Should we be talking about reducing friction in "federating access" in UMA-enabled contracts and not yet talk about automation of true "access federations" a la Shibboleth-like automated onboarding of IdPs/RPs?) *Licensing as our legal model:* We need to use some well-understood legal model in our "private law" tools. Effectively there has to be some sort of cascade of rights that the RO gets. As Kathleen points out, the RS will only expose licensing rights that meet their business model. We hope that reducing friction to "doing the right thing". *Tokens:* There are three tokens that come into play: - Requesting party token (RPT) - required - The RqP is able to revoke this through the OAuth token revocation mechanism. - Protection API access token - required - The RO is able to revoke this through the OAuth token revocation mechanism. - Persisted claims token (PCT) - optional - The RqP is able to revoke this through the OAuth token revocation mechanism. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: UMA Legal call tomorrow (Friday) 8am PT
by Eve Maler 27 Apr '17

27 Apr '17

Dial-in and screenshare: http://join.me/findthomas We'll be discussing Tim's updated chart (attached) and the Resource Regulator topic. :-) Thanks, Tim! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA Legal telecon 2017-04-21
by Eve Maler 27 Apr '17

27 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-04-21 - Reviewing draft deliverable #2 Attending: Eve, Tim, John, Mark Tim's insight around identifying the "harms" to the parties in the #2 exercise helped guide the development of the draft deliverables we're looking at today. John opines that this view elides the "rights" basis for privacy breaches because it's property-based. Well, this is the question. What can we effectively achieve with our clauses and other tools? If agreements/contracts are the basis for what can be achieved between/among a resource owner and other parties, what are all the choices for legal theories? Tim is proposing a licensing basis. (We discussed this back in 2017-04-15 <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…> and seemed to reject this, but what are other alternatives?) There is a governance function and also an economic function. Looking at Sec 2.1 of the EDPS opinion on digital content <https://edps.europa.eu/sites/edp/files/publication/17-03-14_opinion_digital…>, John points to some commentary on the VRM list where someone was troubled by the "market for personal data". The point they were making was that someone could agree to selling organs (or their body into slavery or whatever), but this shouldn't perhaps be possible with selling data. We in UMA take a different, more empowered/powerful, position. Tim's Chart 1 is more of a windup to chart 2, and he will supply more explanatory text for it. The "Communicative Behavior" column means how the requirements for Value, Meaning, and Information are conveyed/communicated, e.g., trust frameworks, regulations, configuration documents, API documentation, etc. Both are about the relationships formed, and are explicitly not about "data ownership". Chart 2 is the "money chart". (Eve screenshared them, and Tim will be revising these and making them available to all before next week's meeting.) So can we state the following? - The data subject has rights over the information about them. - True as part of the Universal Declaration of Human Rights. - Different jurisdictions ensconce this right to different degrees in law/regulation or not. - True of information even prior to its being digitized. - The data controller and the data processor have property rights related to records containing a data subject's information. - The records could be in digital form or not. - The formal "interface" (communicative behavior) defined between data controllers, data processors, and data subjects is regulations. - UMA has the potential to enable data subjects ("resource subjects") and their proxies (resource owners), or even data subjects on their own, to consent to data ("resource") access by third parties ("requesting parties") in such a way that the third party is a data processor. - We believe the regulations are currently blind to: - The proxying opportunity in UMA - The potential ability for UMA to distinguish between granting access to someone who fills the role of a "data processor" vs. "another data controller" - UMA only has soft technical constraints (the "Adrian clause") around jurisdictional nonfunctional requirements for things like data localization. - The potential extension for "cascading authorization servers" would provide a potential hard technical solution. - We have the potential for providing legal toolkits that give legal solutions that may suffice. Do we need a Resource Regulator role? If you're interested, there is a SAMHSA Consent2Share webinar on April 25 at 3:30pm ET. Registration link is here <https://attendee.gotowebinar.com/register/2571416131011406338>. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 6

Draft minutes of UMA telecon 2017-04-27 (see new spec links below)
by Eve Maler 27 Apr '17

27 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-27 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> and UMA telecon 2017-04-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20> : APPROVED by unanimous consent. Logistics Who is traveling next week, particularly next Thursday, and can't make a WG call? Justin and Mike. Mike's got Yuriy reviewing the specs and starting UMA2 implementation right now. Eve's team is also starting implementation. There is also the IIW "coming-out party" sort of opportunity for the refactored specs, to get feedback. Assuming we gain directional consensus on the refactoring today, let's schedule a special WG meeting for Friday May 12 at 9am PT/11am CT/5pm UK for the purpose of approving Draft Recommendations for a Public Comment period. The idea would be to gather feedback between now and then, particularly implementation feedback, and put it into editors' drafts timely. UMA V2.0 work Wrt the refactoring proposition, there are two big questions: - Do the specs taken together have within them everything that was important in Core and RReg (no important testable assertions missing)? - Is the handoff between the specs correct and does it not drop anything on the floor? Eve explained how the concept of permissions is handled in the Grant spec; this will be a key point for implementers and readers to test. In fact, issue #306 <https://github.com/KantaraInitiative/wg-uma/issues/306> is directly related to questions about permissions and resource-specific scopes, so please keep this in mind. For #307 <https://github.com/KantaraInitiative/wg-uma/issues/307>*,* you'd need a standards-track IETF spec to do a real IANA registry. Maybe we should at least take a registry template-like approach. The FedAuthz spec only extends Grant; it is not generally applicable to all OAuth grants. (Maybe seeing it will inspire someone(s) to work on a more generic federated authorization approach together...) So this is a backing-off of the question in #290 <https://github.com/KantaraInitiative/wg-uma/issues/290>! What is the correct description of these specs? What is "feature" and what is "benefit"? Justin called it "uma-ticket" because the permission ticket pattern is the essential feature of the grant. "User-managed access" has been the defining phrase for the set of benefits we targeted with our design principles. The file name/spec identifier should definitely have the word "grant" in it. So replace "ticket" with "grant"? That seems to be the thing to do. The "Adrian clause", about the RS getting to apply its own authorization controls, now sits in FedAuthz. Why? It only makes sense when you enter the land of federated authorization, when the RS and AS are actually operated by different parties. Consensus on continuing with the refactoring approach. *AI*: Eve: Cancel next week's meeting and move the meeting of two weeks from now. (DONE) *AI:* Eve: Reach out to George about his UMA 101 session. (DONE) *AI:* Eve: Edit specs so that it's oauth-uma-grant and an xref of "UMAGrant". (DONE - Grant rev 02 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-02.html> and FedAuthz rev 02 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-02.…> ) *AI:* All: Review and implement specs, and submit issues ASAP so we'll be in a position to get the Public Comment period under way in mid-May. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Andi 3. Eve 4. Mike 5. Cigdem Non-voting participants: - Justin Regrets: - John - Sal *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-04-27 / new drafts...please review ASAP!
by Eve Maler 27 Apr '17

27 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-27 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> and UMA telecon 2017-04-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20> - Logistics/timing: - Need to decide on direction and Draft Recommendation schedule ASAP - Meet next week, or no because of IIW? - Get the word out about IIW sessions (including George's UMA 101 session Day 1 2-3pm!) - UMA V2.0 work: - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>/ dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> (not updated to the spec refactor) - *Please review: Grant rev 01 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-01.html>** and FedAuthz rev 01 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-01.…>* - Issues still open but that have an implemented solution in the current specs (so yell if you don't like the solutions): - *#303 <https://github.com/KantaraInitiative/wg-uma/issues/303>*: JSON Usage and OIDC for client authentication are gone in Grant security considerations - *#304 <https://github.com/KantaraInitiative/wg-uma/issues/304>*: invalid_request is gone (if anything, would only apply to protection API/FedAuthz) - *#305 <https://github.com/KantaraInitiative/wg-uma/issues/305>*: lots of metadata/discovery document cleanup and OAuth alignment, after discussion with Justin, Cigdem, Andi (let's review on the call) - Newer issues arising from the spec refactor (*#290 <https://github.com/KantaraInitiative/wg-uma/issues/290>* / *#296 <https://github.com/KantaraInitiative/wg-uma/issues/296>*) effort: - *#306 <https://github.com/KantaraInitiative/wg-uma/issues/306>*: Re-examine if downscoping should still be undefined in Grant now - *#307 <https://github.com/KantaraInitiative/wg-uma/issues/307>*: Redo Profiles section in Grant into IANA-like registry? - Generally review and decide on spec refactor - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New issue: #305: Even more metadata fields to remove if they're in OAuth/OIDC Discovery?
by Eve Maler 26 Apr '17

26 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/305 In the continuing quest for simplification and OAuth/OIDC alignment as I work on the refactored specs, this seems like a biggie. Thoughts from y'all? If we go with Grant/Fed Authz vs Core/RReg, which seems to be the prevailing opinion, I really don't like the idea of including all the "here's a new definition of how you do discovery/metadata infrastructure" stuff in our specs vs. just leveraging OAuth's and OIDC's invitation to add new metadata fields. The only unattractive part is that OAuth discovery is in draft, and I wonder if it's going anywhere. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Pre-session ad hoc on Wed 9am PT/5pm UK; big decisions on Thursday
by Eve Maler 25 Apr '17

25 Apr '17

Andi, Cigdem, and I are going to meet tomorrow, Wednesday, at 9am PT/5pm UK to review the refactored specs. You are very welcome indeed to join us, but you *MUST* let me know ahead of time (i.e. *NOW*); right now we're just planning to meet on Skype. On Thursday, we need to make a key decision on the refactoring direction, remaining open issues, and our timeline. So far the response has been positive on the grant spec; we need to be just as certain about the federated authorization spec (which is currently in an inconsistent state, but I'll send out a link before Thursday's call). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-04-20
by Eve Maler 21 Apr '17

21 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09>: Deferred. UMA V2.0 work *#293 <https://github.com/KantaraInitiative/wg-uma/issues/293>*: Consensus on pushing only a single claim token being "hunky dory" (a good idea). *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298>*: The redirect-back paths look much cleaner now. *#290 <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and *#296 <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling): We looked at the new oauth-uma-ticket rev 00 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-00.html> experimental spec. General support for this approach, though we don't have a federated authorization spec yet. Can we sync the high-level flow diagram more with OAuth's abstract protocol flow diagram? Andi says: "I like this effort to re-architect the way the specs are laid out, Eve. Happy to help if I can (dm me later if so and we can discuss)." Cigdem says: "I think if we want to provide a comparison to OAuth - comparison via "abstract protocol flows" maybe more appropriate. In this case (C) Authorization grant: includes ticket, claims collection, RqP interaction etc. for UMA, After that we can have the more detailed flow diagram." So we could have two diagrams, where the first indicates explicitly the mapping to OAuth's letters A through F. Why do we still have registration_endpoint metadata? Sort of historical (because our group wrote the first dynamic client registration spec)? Should we consider dropping it? People could just use the OIDC spec, or the draft OAuth metadata spec, to declare their registration endpoint. Eve will make an issue to consider this. (DONE <https://github.com/KantaraInitiative/wg-uma/issues/305>.) Ishan points to the OIDC wording: "Additional Client Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session]" Since we've never had an "UMA grant" per se before, should we overtly label this as UMA2? Seems to make sense since UMA1 is out there (and we have semantic versioning!). Eve has done so, sort of, but will make it more obvious. "Permission" has been defined, but is there actually any reason to do so? It doesn't seem like it. In the spec swimlane, the redirect and redirect-back, there should probably be two arrows/steps, since there are two whole sections for this. This is only a "sample high-level flow" in that there are pushed claims followed by interactive claims gathering followed by success. The client approaching the resource first, with the whole ticket flow etc., is not optional. The swimlane should use very short phrases with a list following, a la 6749's style. Sec 1.3.2's claims collection discussion should clarify that while claims collection is probably not really optional, claims don't strictly have to be collected through UMA messaging; it could be done out of band (don't use that phrase?). In the section on Endpoints, the last paragraph may be out of place. *AI:* Eve: Propose an ad hoc early next week for at least her, Andi, and Cigdem (others welcome) to work on the refactored specs. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Andi 4. Eve Non-voting participants: - Ishan - John - Crina Regrets: - Justin - Maciej - Mike *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Legal: meeting tomorrow 8am PT to discuss deliverable #2 topics
by Eve Maler 20 Apr '17

20 Apr '17

<eom/> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft UMA grant spec for your perusal
by Eve Maler 20 Apr '17

20 Apr '17

https://docs.kantarainitiative.org/uma/ed/oauth-uma-ticket-2.0-00.html I *might* get time to do at least a partial federated authorization spec tomorrow early morning -- we'll see. Please weigh in here if you manage to get time to skim it before the call. (In the course of working on this spec, I ruthlessly chopped out lots of duplicative text, partly because one purpose was to get things more readable and partly because the spec was getting short enough that the main sections were ending up next to each other in most cases, with little need to do cross-references to make sense of the three-party "dance" through links. But I think quite a few of the edits could be back-ported to the existing specs, if we ultimately don't like the refactoring idea. I'm keeping track of a few key editorial things I want to do regardless even of this back-porting notion.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-04-20
by Eve Maler 19 Apr '17

19 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-20 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> - UMA V2.0 work: - All GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>/ dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 21 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html> and RReg is up to 08 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-08.html> (back to editors' drafts) - Most issues were proactively closed because we had good consensus on substantive issue discussions and/or the issues were editorial - What was done (you've had this list since Monday): - #293 <https://github.com/KantaraInitiative/wg-uma/issues/293>: Check/fix all examples for missing required (and optional) fields; other editorial (the not-quite-editorial change to "flatten" the pushing of claim tokens so that a client pushes one claim token at a time; see Core Sec 3.6.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#uma-grant-ty…> ) - #294 <https://github.com/KantaraInitiative/wg-uma/issues/294>: Consider a proof-of-possession option for the RPT core security (see Core Sec 6.2 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc.section.…> ) - #295 <https://github.com/KantaraInitiative/wg-uma/issues/295>: When a requesting party needs to withdraw their access core (see Core Sec 3.11 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#token-revoca…> ) - #302 <https://github.com/KantaraInitiative/wg-uma/issues/302>: Typo in RReg source regarding the stylesheet editorial rsrc-reg (trivial; RReg didn't change substantively) - Your turn to yell (*before* the call) if you're not happy with this - *#290 <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and *#296 <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling): Should have a concrete proposal for discussion - *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses): a "flattened" claim token in native form-urlencoded format was implemented in Core Sec 3.6.3 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#redirect-back> -- didn't close this issue yet because only a relatively small subset of us discussed the recommendation, so let's review - *#303 <https://github.com/KantaraInitiative/wg-uma/issues/303>* (Cleaning up the security considerations: JSON Usage): Possibly pass a quick eye over this one - *New:* *#304 <https://github.com/KantaraInitiative/wg-uma/issues/304>* (Do we need the UMA error invalid_request?): Let's consider this - *#297 <https://github.com/KantaraInitiative/wg-uma/issues/297>* (Add the authorization process flowchart or some other visual explanation): To be closed without action unless someone speaks up - Logistics/timing - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New editor's drafts: Core rev 21 and RReg rev 08
by Eve Maler 18 Apr '17

18 Apr '17

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-08.html http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd In these drafts you will find the following issue implementations (mostly closed): #293 <https://github.com/KantaraInitiative/wg-uma/issues/293>: Check/fix all examples for missing required (and optional) fields; other editorial (the not-quite-editorial change to "flatten" the pushing of claim tokens so that a client pushes one claim token at a time; see Core Sec 3.6.1 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#uma-grant-ty…> ) #294 <https://github.com/KantaraInitiative/wg-uma/issues/294>: Consider a proof-of-possession option for the RPT core security (see Core Sec 6.2 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc.section.…> ) #295 <https://github.com/KantaraInitiative/wg-uma/issues/295>: When a requesting party needs to withdraw their access core (see Core Sec 3.11 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#token-revoca…> ) #298 <https://github.com/KantaraInitiative/wg-uma/issues/298>: Reconsider whether ticket should be on all redirect-back AS responses core (see Core Sec 3.6.3 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#redirect-back>) -- didn't close this issue yet because only a relatively small subset of us discussed the recommendation #302 <https://github.com/KantaraInitiative/wg-uma/issues/302>: Typo in RReg source regarding the stylesheet editorial rsrc-reg (trivial; RReg didn't change substantively) Please do check over the new text and examples, and the swimlane summary, and see what you think. Also please note that there are still a couple of issues that could use your opinion! *Existing:* #303 <https://github.com/KantaraInitiative/wg-uma/issues/303>: Cleaning up the security considerations: JSON Usage and OIDC for client authentication *New:* #304 <https://github.com/KantaraInitiative/wg-uma/issues/304>: Do we need the UMA error invalid_request? I'm going to turn my full attention to the spec refactoring proposal now... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #295: Token revocation not that simple?
by Eve Maler 17 Apr '17

17 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/295 This was our token revocation discussion. It seemed so simple on our call on Thursday: Just define a new token type hint keyword, say "pct". But reading RFC 7009, I'm not sure that's quite the end of it. Token revocation requires <https://tools.ietf.org/html/rfc7009#section-2> authenticating the identity of the resource owner at the authorization endpoint a la OAuth Sec 3.1 <https://tools.ietf.org/html/rfc6749#section-3.1>. Of course, by analogy, that would be using the claims interaction endpoint for us, but we allow a lot more flexibility in our authorization process, e.g. pushing claims etc. And this isn't just because it's an asynchronous grant. So I think we need to do a bit more "surgery". I can't think of any reason why the client shouldn't be able to go ahead and ask to revoke any RPT it has, even if the RqP isn't around. Is that legit? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Issue #293: Not-that-editorial: example of pushed claims needs to be form-urlencoded
by Eve Maler 17 Apr '17

17 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/293 Hi folks-- Please take a look at the latest comment in this issue, which highlights what started as an editorial issue but discovered a (potentially minor) decision point around how the client pushes claims to the AS's token endpoint. Because we've gone from UMA1's custom RPT endpoint which takes JSON payloads to UMA2's regular OAuth token endpoint which takes form-urlencoded payloads, our carried-over spec text talking about a JSON-formatted claim_tokens structure -- combined with an old example -- needed an update. *The proposal:* An update that changes the actual structure of claim pushing slightly, so that: - It's a truly native and streamlined form-urlencoded format. - The client pushes a single claim token (say, one ID token) and can't push a bunch of them. The theory is that we'd normally think it odd to send a set of ID tokens or SAML assertions or whatever anyway, so the old design that had an array was probably overdesigned. I'm going to try this out in the latest editor's draft unless somebody tells me they were already using the multiples feature... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Full discussion on issue #298: Reconsider whether ticket should be on all redirect-back AS responses
by Eve Maler 15 Apr '17

15 Apr '17

https://github.com/KantaraInitiative/wg-uma/issues/298 Since a subset of the WG (Just, Robert, and me) kept going for about 30 minutes after Thursday's call ended, I said I'd pull out this part of the notes to highlight it for everyone and ensure you have a real chance to think about it. This was a really fascinating discussion. Our conclusion was that the redirect-back from the claims interaction endpoint, rather than try to duplicate the token (was RPT) endpoint status messages as it had kind of been doing, should sync up *directly* with what OAuth does instead. The basic thing it needs to achieve (as far as the client actually cares) is "yes, continue, everything went fine" or "something went wrong". If you *don't* agree, shout now! (I'm going to try and implement this in the next editors' draft so you can see what you think...) ==== *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* We have errors that are identical on redirect-back (RqP/claims interaction endpoint) and the token request (client/token endpoint). On which errors should the AS produce a (rotated) ticket, and on which ones should the authorization process end? *(The formal meeting ended and we kept going ad hoc.)* *Redirect-back:* Thinking of how the client is going to respond ("What's my motivation?"), can we consolidate claims_submitted and request_submitted? We don't have enough experience to know if the difference is truly significant. In a way, all these options boil down to "continue" (or "don't continue")! Do we need authorization_state at all? Flipping the logic entirely, we could just pass an error if the client should just stop. Since our claims interaction endpoint is the moral equivalent of the authorization endpoint, only for RqPs, it's way better for our OAuth alignment goal to sync with the authorization endpoint's error response <https://tools.ietf.org/html/rfc6749#section-4.1.2.1>. Our proposal: Require the AS to use an error response according to Sec 4.1.2.1 as defined in OAuth (by reference). *Token request:* Obviously, if the client gets a token successfully, it got a token and that ends the process. A "need info" means it needs to (has the opportunity to) continue the process in the next call to the token endpoint. Thus, same-process context is needed. A broken request message means the process ends. If the request is submitted and the client has nothing to do but it's all about the AS and RO doing something, the discussion in the issue is about how a ticket needs to be issued in order to correlate a (possibly much) later "polling" attempt by the client. Of course, the client could ignore and start a new authorization process. Eve's argument about reusing invalid_grant for the "non-structural" error of not_authorized, which doesn't hand out a ticket, stopping the authorization process, is that reusing an existing OAuth error for something it doesn't truly mean is weird. Justin feels that since clients don't care and wouldn't change their behavior either way, why not reuse invalid_grant? Robert and Cigdem say that the only reason to have both is to provide extra information why it was a no. Robert: "If the information is not going to be used, it's not data. It's wasted." Of course, error_description could be used. - invalid_grant: no; state that a definitive failure, vs. a deliberate continuance of the process, uses this error (a change) - invalid_scope: no - request_submitted: yes (a change) - need_info: - not_authorized: remove (a change) *AI:* Eve: Send separate note to the WG proposing this and asking for feedback. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Legal: Will we have critical mass if we meet on Friday at 8am PT?
by Eve Maler 14 Apr '17

14 Apr '17

Hi all-- Tim has a draft of deliverable #2 for us to look at; we met today about it. But I know it's Good Friday, and many people may be taking off. Who is available to meet? Please let me know and I'll make a decision by tomorrow (Thursday) noon my time. Thanks. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 2

Legal: European Data Protection Supervisor publishes "toolkit" -- a checklist!
by Eve Maler 14 Apr '17

14 Apr '17

https://edps.europa.eu/sites/edp/files/publication/17-04-11_necessity_toolk… Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Notes from UMA telecon 2017-04-13
by Eve Maler 13 Apr '17

13 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-13 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09>: Deferred. Logistics - The Apr 11 ad hoc (which was quorate) worked through <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/G_cPnocQ8…> *#294* <https://github.com/KantaraInitiative/wg-uma/issues/294>* (Consider a proof-of-possession option for the RPT)* - Concrete proposal for spec refactoring (*#290* <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and **#296* <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling)*) *may* be ready for consideration in Apr 20 meeting - Let's see if we can work through the rest of the open substantive issues in this meeting UMA V2.0 work *#295* <https://github.com/KantaraInitiative/wg-uma/issues/295>* (When a requesting party needs to withdraw their access):* The Token Revocation spec (a coarse-grained mechanism of positively rescinding one's granted access from the client side) "should work" as usual; in this case, the client would be acting on behalf of the RqP instead of the RO. For any fine-grained recision, a la "I want to keep read access, but rescind write access" (or "I want to still get access to the trunk but rescind access to driving the car"), the client could simply ask for few scopes, but there's in-band way (OAuth or UMA) for the client to confirm that it then received the fewer scopes it wanted. The point of the issue is that Bob takes on accountability/responsibility/liability from the moment access is granted, whether or not he ever drives the car. The general idea <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note…> is that the juncture at which the technical artifact is issued has a corresponding agreement/contract. But if the client previously asked for "trunk" and "drive" scopes, but now asks for only "trunk", and the RS's documented pattern that it executes is to still always ask for "drive" scope, then our *RequestedScopes* set in that later calculation will still have "drive" in it because of the *PermissionTicket* portion. However, there's evidence from the client's request at the token endpoint that it *wished* to have fewer scopes. Is this enough to reduce Bob's accountability, if the token it gets back still has "drive" scope in it? This doesn't seem strong enough, but "fine-grained revocation" seems like a stretch goal for now anyway. Does the Token Revocation spec (RFC 7009 <https://tools.ietf.org/html/rfc7009>) work the same way for UMA? Justin says it should work the same, as the RPT is just an access token. What about revoking the PCT? What's the motivation for revoking a PCT? They're useful/usable across RPTs, but we wouldn't want to revoke RPTs that were issued on the basis of some PCT. The point of token revocation generally is security hygiene, allowing a client to clean up after itself and let the AS record that the client did so. Justin suggests an (optional) method for leveraging the existing token revocation mechanism, providing some sort of "pct" keyword as a new token type hint. We'd have to add more IANA registry stuff. The AS is required *not* to say what it did in response to the revocation request, in order not to give an attacker with a stolen token TMI. *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* We have errors that are identical on redirect-back (RqP/claims interaction endpoint) and the token request (client/token endpoint). On which errors should the AS produce a (rotated) ticket, and on which ones should the authorization process end? *(The formal meeting ended and we kept going ad hoc.)* *Redirect-back:* Thinking of how the client is going to respond ("What's my motivation?"), can we consolidate claims_submitted and request_submitted? We don't have enough experience to know if the difference is truly significant. In a way, all these options boil down to "continue" (or "don't continue")! Do we need authorization_state at all? Flipping the logic entirely, we could just pass an error if the client should just stop. Since our claims interaction endpoint is the moral equivalent of the authorization endpoint, only for RqPs, it's way better for our OAuth alignment goal to sync with the authorization endpoint's error response <https://tools.ietf.org/html/rfc6749#section-4.1.2.1>. Our proposal: Require the AS to use an error response according to Sec 4.1.2.1 as defined in OAuth (by reference). *Token request:* Obviously, if the client gets a token successfully, it got a token and that ends the process. A "need info" means it needs to (has the opportunity to) continue the process in the next call to the token endpoint. Thus, same-process context is needed. A broken request message means the process ends. If the request is submitted and the client has nothing to do but it's all about the AS and RO doing something, the discussion in the issue is about how a ticket needs to be issued in order to correlate a (possibly much) later "polling" attempt by the client. Of course, the client could ignore and start a new authorization process. Eve's argument about reusing invalid_grant for the "non-structural" error of not_authorized, which doesn't hand out a ticket, stopping the authorization process, is that reusing an existing OAuth error for something it doesn't truly mean is weird. Justin feels that since clients don't care and wouldn't change their behavior either way, why not reuse invalid_grant? Robert and Cigdem say that the only reason to have both is to provide extra information why it was a no. Robert: "If the information is not going to be used, it's not data. It's wasted." Of course, error_description could be used. - invalid_grant: no; state that a definitive failure, vs. a deliberate continuance of the process, uses this error (a change) - invalid_scope: no - request_submitted: yes (a change) - need_info: - not_authorized: remove (a change) *AI:* Eve: Send separate note to the WG proposing this and asking for feedback. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Eve 3. Cigdem Non-voting participants: - Robert - Justin - Ishan - Jin - Bjorn *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-04-13
by Eve Maler 12 Apr '17

12 Apr '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-13 Date and Time - *Thursdays, 9-10am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-03-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09> - Logistics: - The Apr 11 ad hoc (which was quorate) worked through <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/G_cPnocQ8…> *#294* <https://github.com/KantaraInitiative/wg-uma/issues/294>* (Consider a proof-of-possession option for the RPT)* - Concrete proposal for spec refactoring (*#290* <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and **#296* <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling)*) *may* be ready for consideration in Apr 20 meeting - Let's see if we can work through the rest of the open substantive issues in this meeting - UMA V2.0 work: - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> / GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>/ dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 20 <https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html> and RReg is up to 06 <http://docs.kantarainitiative.org/uma/wg/oauth-resource-reg-2.0-07.html> (WG drafts; no change) - *#295* <https://github.com/KantaraInitiative/wg-uma/issues/295>* (When a requesting party needs to withdraw their access):* This touches on downscoping and token revocation, and thus could use some analysis - *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* Main issue seems to need no action, but a related issue came up about the appropriateness of not_authorized as an error that we could consider - *#303 <https://github.com/KantaraInitiative/wg-uma/issues/303> (Cleaning up the security considerations: JSON Usage):* Possibly pass a quick eye over this one - AOB - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA ad hoc telecon 2017-04-11
by Eve Maler 11 Apr '17

11 Apr '17

*Tuesday 9-10am PT* *Dial-in and screenshare:* http://join.me/findthomas *Calendar:* http://kantarainitiative.org/confluence/display/uma/Calendar *(if you are currently not being invited to WG meetings and want to be, or the reverse, let me know)* Attending: Eve, Robert, Justin, John, Cigdem, Prabath, Mike, Domenico, Maciej (quorum!) Our current substantive open issues look like this: - *#290* <https://github.com/KantaraInitiative/wg-uma/issues/290>* (Generality of RReg spec?) and **#296* <https://github.com/KantaraInitiative/wg-uma/issues/296>* (Out-of-the-box profiling for tight AS-RS coupling):* This is a biggie. Current proposal (*for which I hope to have some more details by call time!*) is to consider a different way of modularizing the specs. A group consisting of me, Mark L, Maciej, Andi, and Cigdem talked about this further in London last Monday and there was a pretty strongly favorable impression. Eve reviewed her approach. Implied in the refactoring is two “operational modes”, that is, it would be possible to use the extension grant without using the federated authorization piece. Justin suggests that this is a 2.1-phase action, on the theory that it’s almost certainly backwards compatible. Mike likes the approach and is supportive of the suggested timeline. So commit to only going as far as backwards compatibility allows? Yes. Justin estimates that a 2.1 would be a 6-12 month effort. This sounds like a long time to Eve. :-) A big motivation is adoptability of even the 2.0 specs as they are, so she’d like to try the refactoring sooner. Before we make a decision, Eve agrees to create a second, more detailed proposal that amounts to draft specs on a branch that can be examined for viability. She’ll do this by Apr 21. - *#294* <https://github.com/KantaraInitiative/wg-uma/issues/294>* (Consider a proof-of-possession option for the RPT):* This topic is broader by now, including token binding etc., and we suspect this all might "just work". This just needs to be analyzed a bit. *Prabath*, you were going to take a look -- can you, please, and write up? Prabath sent a nice writeup <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/EUVEot8ZM…> summarizing the state of play. Justin: RFC 7662 (token introspection) notes <https://tools.ietf.org/html/rfc7662#appendix-A>, in an appendix, that there’s — presumably — an extension being written to finish the unfinished PoP piece. Some options for our purposes: 1. Say nothing, since we incorporate (and profile) 7662. 2. Point explicitly at this language so that there is a mention of PoP. 3. Point explicitly at this language and add commentary regarding the need for extensions etc. 4. Define an extension ourselves at this juncture. 5. Mention in an appendix, a la 7662, the places where PoP would affect UMA but not do the work. This is like 2 but is more hands-off. Discussion: Eve’s rationale for no. 2 or 3 (prior to Justin’s suggesting no. 5) is that mentioning proof of possession in the spec would give implementers something to hang onto to answer their questions. Cigdem points out that we do mention PoP, in Sec 6.1.1. However, this is actually a different meaning, referring to the RqP’s proof, not the client’s proof, so should we remove this usage of the phrase and stick to “holder of key” instead (SAML-like)? We have consensus around no. 5. Eve proposes putting a new subsection in Sec Consid, discussing security properties of the RPT, modeling the language after the 7662 language. Let’s do that. Speaking of Sec 6.1.1, it really has two attacks in it: innocent Bob/malicious Carlos but also malicious Bob handing off the RPT to his malicious friend Carlos. There’s very little we can do about the latter other than legal enforcement remedies. (This has been called “ABC” for the Alice-and-Bob Collusion attack.) Note that the OAuth WG has rejected this as a form of attack. Some options: 1. Do nothing. Rationale: OAuth has chosen not to dignify the ABC attack. 2. Clarify that 6.1.1 is about innocent Bob, and if Bob is malicious, these mitigations are largely ineffective, but the premise of an access token is that the receiving side MUST keep it secure. No appetite for no. 2, so we keep the status quo. - *#295* <https://github.com/KantaraInitiative/wg-uma/issues/295>* (When a requesting party needs to withdraw their access):* This touches on downscoping and token revocation, and thus could use some analysis. *Justin*, this could use your eyeballs in particular, but it's really for *everyone*. - *#298* <https://github.com/KantaraInitiative/wg-uma/issues/298>* (Reconsider whether ticket should be on all redirect-back AS responses):* Justin and Cigdem have been commenting on this one and seem to have consensus so far that we're okay, but it could use more eyeballs. But another related issue has come up about the appropriateness of not_authorized as an error that we could consider. Deferred to Thursday. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Apr 10, 2017 at 11:40 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: > *Tuesday 9-10am PT* > *Dial-in and screenshare:* http://join.me/findthomas > *Calendar:* http://kantarainitiative.org/confluence/display/uma/Calendar > *(if you are currently not being invited to WG meetings and want to be, or > the reverse, let me know)* > > Our current substantive open issues look like this: > > - *#290 > <https://github.com/KantaraInitiative/wg-uma/issues/290> (Generality of > RReg spec?) and #296 > <https://github.com/KantaraInitiative/wg-uma/issues/296> (Out-of-the-box > profiling for tight AS-RS coupling):* This is a biggie. Current > proposal (*for which I hope to have some more details by call time!*) > is to consider a different way of modularizing the specs. A group > consisting of me, Mark L, Maciej, Andi, and Cigdem talked about this > further in London last Monday and there was a pretty strongly favorable > impression. > - *#294 > <https://github.com/KantaraInitiative/wg-uma/issues/294> (Consider a > proof-of-possession option for the RPT):* This topic is broader by > now, including token binding etc., and we suspect this all might "just > work". This just needs to be analyzed a bit. *Prabath*, you were going > to take a look -- can you, please, and write up? > - *#295 <https://github.com/KantaraInitiative/wg-uma/issues/295> (When > a requesting party needs to withdraw their access):* This touches on > downscoping and token revocation, and thus could use some analysis. > *Justin*, this could use your eyeballs in particular, but it's really > for *everyone*. > - *#298 > <https://github.com/KantaraInitiative/wg-uma/issues/298> (Reconsider > whether ticket should be on all redirect-back AS responses):* Justin > and Cigdem have been commenting on this one and seem to have consensus so > far that we're okay, but it could use more eyeballs. But another related > issue has come up about the appropriateness of not_authorized as an > error that we could consider. > > > *Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | > Twitter: @xmlgrrl > >

1 0

Proof-of-possession option for the RPT
by Prabath Siriwardena 11 Apr '17

11 Apr '17

Please find below some thoughts related to https://github.com/KantaraInitiative/wg-uma/issues/294. The RFC 7800 [1] presents a concrete approach, which defines how to communicate the confirmation key information in JWTs. This is applicable in any case where the RPT itself is a self-contained access token (which is an JWT). In other words, as per RFC 7800 the authorization server (or the token issuer) embeds the confirmation key (associated with the client) (or a reference to the confirmation key) in the JWT (which signed by the issuer. The confirmation key can be either symmetric or asymmetric proof of procession key. If it's asymmetric, then the public key information is communicated in the JWT issued by the authorization server. If it's symmetric, then the confirmation key is encrypted by a key known to the resource server. In either case, the JWT can also communicate the confirmation key by reference, using the kid or the jku. What is not discussed in the RFC 7800? 1. It does not talk about how the key information is established between the client and the authorization server. 2. It does not talk about how the client proves its procession of the confirmation key. The draft spec OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution [2] addresses how key distribution happens between the client and the authorization server. The draft spec A Method for Signing HTTP Requests for OAuth [3] can be used as way for the client to prove the procession of the key. *Overall the architecture to build PoP tokens (or RPT in UMA) is in development - and UMA may need not to do any thing specific to itself - but rather provide recommendations and pointers.* Thoughts please... [1]: https://tools.ietf.org/html/rfc7800 [2]: https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 [3]: https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 On Wed, Apr 5, 2017 at 4:41 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: > Instead, I'd like to ask people to review the specs and open issues, and > prepare final comments in preparation for next week; we said our "WG last > call" would end by Tue, Apr 11. > > Our current substantive open issues look like this: > > - *#290 > <https://github.com/KantaraInitiative/wg-uma/issues/290> (Generality of > RReg spec?) and #296 > <https://github.com/KantaraInitiative/wg-uma/issues/296> (Out-of-the-box > profiling for tight AS-RS coupling):* This is a biggie. Current > proposal (for which I hope to have some more details soon) is to consider a > different way of modularizing the specs. A group consisting of me, Mark L, > Maciej, Andi, and Cigdem talked about this further in London on Monday and > there was a pretty strongly favorable impression. > - *#294 <https://github.com/KantaraInitiative/wg-uma/issues/294> > (Consider a proof-of-possession option for the RPT):* This topic is > broader by now, including token binding etc., and we suspect this all might > "just work". This just needs to be analyzed a bit. *Prabath*, you were > going to take a look -- can you, please, and write up? > - *#295 <https://github.com/KantaraInitiative/wg-uma/issues/295> (When > a requesting party needs to withdraw their access):* This touches on > downscoping and token revocation, and thus could use some analysis. > *Justin*, this could use your eyeballs in particular, but it's really > for *everyone*. > - *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298> > (Reconsider whether ticket should be on all redirect-back AS responses):* Justin > and Cigdem have been commenting on this one and seem to have consensus so > far that we're okay, but it could use more eyeballs. But another related > issue has come up about the appropriateness of not_authorized as an > error that we could consider. > > For anyone interested, I'd like to propose an ad hoc meeting next *Tue, > Apr 11* at 9am PT to discuss these issues (and any others people report), > in addition to our regular *Thu, Apr 13* call. > > I'll make the changes to the calendar right now. > > > *Eve Maler*Cell +1 425.345.6756 <+1%20425-345-6756> | Skype: xmlgrrl | > Twitter: @xmlgrrl > > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://facilelogin.com

1 0

Agenda for UMA ad hoc telecon 2017-04-11
by Eve Maler 10 Apr '17

10 Apr '17

*Tuesday 9-10am PT* *Dial-in and screenshare:* http://join.me/findthomas *Calendar:* http://kantarainitiative.org/confluence/display/uma/Calendar *(if you are currently not being invited to WG meetings and want to be, or the reverse, let me know)* Our current substantive open issues look like this: - *#290 <https://github.com/KantaraInitiative/wg-uma/issues/290> (Generality of RReg spec?) and #296 <https://github.com/KantaraInitiative/wg-uma/issues/296> (Out-of-the-box profiling for tight AS-RS coupling):* This is a biggie. Current proposal (*for which I hope to have some more details by call time!*) is to consider a different way of modularizing the specs. A group consisting of me, Mark L, Maciej, Andi, and Cigdem talked about this further in London last Monday and there was a pretty strongly favorable impression. - *#294 <https://github.com/KantaraInitiative/wg-uma/issues/294> (Consider a proof-of-possession option for the RPT):* This topic is broader by now, including token binding etc., and we suspect this all might "just work". This just needs to be analyzed a bit. *Prabath*, you were going to take a look -- can you, please, and write up? - *#295 <https://github.com/KantaraInitiative/wg-uma/issues/295> (When a requesting party needs to withdraw their access):* This touches on downscoping and token revocation, and thus could use some analysis. *Justin*, this could use your eyeballs in particular, but it's really for *everyone*. - *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298> (Reconsider whether ticket should be on all redirect-back AS responses):* Justin and Cigdem have been commenting on this one and seem to have consensus so far that we're okay, but it could use more eyeballs. But another related issue has come up about the appropriateness of not_authorized as an error that we could consider. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Re: [WG-UMA] [projectvrm] GDPR and individuals as first parties
by Adrian Gropper 06 Apr '17

06 Apr '17

Thank you, Marcin for the perspective. It's up to the UMAnitarians to document and demonstrate how UMA relates to GDPR. It's up to all of us to label resource servers and highlight voluntary adoption of (c) and (d) to encourage Competition for Privacy as we scale the amount of networked personal data. Adrian On Wed, Apr 5, 2017 at 8:15 PM Marcin Betkier <Marcin.Betkier(a)vuw.ac.nz> wrote: > > > Adrian, I am afraid that you may expect too much from ‘data portability’. > It is just the right to receive some of your personal data and /or transmit > them directly to other controller (‘when technically feasible’). > > In particular, I do not think that (b) or (c) is in its scope. That is to > say, I wouldn’t say that data controller according to Art 20 GDPR should > establish a mechanism/process of accessing particular elements of personal > data leaving data subjects (or/and their agents) decisions what exactly to > transmit and to whom (effectively making data controllers to act as > resource servers in UMA scheme). Neither I would say that data subjects (or > their agents/authorisation severs) should be the only source of decisions > what data controllers could share to 3rd parties. Again, to achieve this > (if I read the idea correctly), we probably need much stronger, different > right. > > > > Article 20 does not have many details. What is somehow specified is data > format which should be “structured, commonly used and machine-readable“. > The rest (including protocol and authorisation process) remains a sweet > mystery which will be revealed in practice. You may look into the Art 29 > WP’s opinion (WP 242) for more details remembering that it is just opinion > of the European Data Protection Authorities. So, I would guess that future > reality may be closer to (e). Especially, if we take a look at the outcomes > from ‘midata’ in the UK. As I heard, banks just allow their customers to > click midata button to download .csv files with 12-months of statements. It > is probably the easiest way to fulfil the regulatory obligation. > > > > BTW, I am not sure that UMA can fully do (c) – control data. As far as I > understand it, it is an authorisation protocol. So, you need to have data > under your control on a resource server before you start to authorise > others to use them. (Hopefully, you may be able to use data portability to > get some :-) ) Furthermore, I think that there may be problem with control > over data after they are accessed/copied by the 3rd party. But, maybe > this is somehow covered.(?) > > Having said that, I believe that UMA is a great step forward in the right > direction. I am sure that there are many scenarios in which it will be > successfully applied (eg. delegations). And, answering the question, I know > no other protocol like this. > > > > Eve, thanks for the links! > > > > Cheers, > > Marcin > > > > *From:* Eve Maler [mailto:eve@xmlgrrl.com] > *Sent:* Thursday, 6 April 2017 10:06 a.m. > *To:* Adrian Gropper <agropper(a)healthurl.com> > *Cc:* Tim Walters <walterswdf2(a)gmail.com>; Devon Loffreto < > devon.loffreto(a)gmail.com>; Marcin Betkier <Marcin.Betkier(a)vuw.ac.nz>; > Manon Molins <mmolins(a)fing.org>; wg-uma(a)kantarainitiative.org WG < > WG-UMA(a)kantarainitiative.org>; ProjectVRM list < > projectvrm(a)eon.law.harvard.edu>; Guy Higgins <guy.higgins(a)performance2.net>; > Iain Henderson <iainhenderson(a)mac.com> > *Subject:* Re: [WG-UMA] [projectvrm] GDPR and individuals as first parties > > > > (I don't think I can post to the ProjectVRM list, but I'm about to find > out.) Very interesting thread. A few thoughts: > > - Mark L recently consolidated a bunch of feedback from the Consent > and Information Sharing WG for the ICO draft consent guidance; this > included some feedback I offered on "directed" ways of sharing personal > data that take after "consent directive" patterns in healthcare, noting > that this is more of a true parallel to unilateral consent withdrawal than > is "opt-in". So sounds like we're all trying to reach out and ensure that > honestly empowered consent is accounted for in GDPR in various ways! > - If you haven't been following the UMA Legal effort, which is working > towards a legal framework that bridges UMA's technical capabilities and > legal and contractual capabilities (including various jurisdictional data > protection regimes including GDPR), may want to check out this page > <http://kantarainitiative.org/confluence/display/uma/UMA+Legal>. > - At RSA this year, I presented > <https://www.rsaconference.com/events/us17/agenda/sessions/6826-designing-a-…> > an enhanced classification system for consent based on the need to be more > inclusive of things like "consent directives"/"Share button" paradigms and > user-submitted terms. The rough idea is that you can tell just how much > you're enabling a trusted digital relationship by how many dimensions of > consent get exercised in the classification system. I'd love to know what > y'all think. > > > > > > *Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl > > > > > > On Wed, Apr 5, 2017 at 3:39 PM, Adrian Gropper <agropper(a)healthurl.com> > wrote: > > Thanks, Tim for the GDPR review. The comments on portability are > particularly relevant to UMA. There are many ways to interpret portability: > > > > (a) give me the data and then close access or delete it > (b) put the data under my control and allow me to decide what 3rd party > can access it > > (c) put the data under my control and allow me and my agent to decide what > 3rd party can access it > > (d) give out the data under a standard format, protocol, and authorization > process > > (e) give out the data in whatever format you want and with your special or > proprietary authorization process > > > > When we talk about terms and receipts it's important to make clear if and > how a data holder interprets portability. Does GDPR differentiate between > (a) - (e)? Is there anything other than UMA that can do (c)? > > > > Adrian > > > > > > > > On Wed, Apr 5, 2017 at 9:55 AM, Tim Walters <walterswdf2(a)gmail.com> wrote: > > For what it's worth, I just noticed that the WP 217 opinion does include > this specific enthusiastic reference to PIM-type platforms ("midata"). > (This is pp. 47-48.) > > Data portability, 'midata' and related issues > Among the additional safeguards which might help tip the balance, special > attention should be given to data portability and related measures, which > may be increasingly relevant in an on-line environment. The Working Party > recalls its Opinion on Purpose Limitation where it has emphasised that 'in > many situations, safeguards such as allowing data subjects/customers to > have direct access to their data in a portable, user-friendly and > machine-readable format may help empower them, and redress the economic > imbalance between large corporations on the one hand and data > subjects/consumers on the other. It would also let individuals 'share the > wealth' created by big data and incentivise developers to offer additional > features and applications to their users.109 > > The availability of workable mechanisms for the data subjects to access, > modify, delete, transfer, or otherwise further process (or let third > parties further process) their own data will empower data subjects and let > them benefit more from digital services. In addition, it can foster a more > competitive market environment, by allowing customers more easily to switch > providers (e.g. in the context of online banking or in case of energy > suppliers in a smart grid environment). Finally, it can also contribute to > the development of additional value-added services by third parties who may > be able to access the customers' data at the request and based on the > consent of the customers. In this perspective, data portability is > therefore not only good for data protection, but also for competition and > consumer protection.110 > > Notes: > 108 See Annex II (on Big Data and Open Data) of the Opinion (cited in > footnote 9 above), page 45. > 109 'See initiatives such as 'midata' in the UK, which are based on the > key principle that data should be released back to consumers. Midata is a > voluntary programme, which over time should give consumers increasing > access to their personal data in a portable, electronic format. The key > idea is that consumers should also benefit from big data by having access > to their own information to enable them to make better choices. See also > 'Green button' initiatives that allow consumers to access their own energy > usage information.' For more information on initiatives in the UK and in > France see http://www.midatalab.org.uk/ and http://mesinfos.fing.org/. > 110 On the right to data portability, see Article 18 of the Proposed > Regulation. > > > > On Tue, Apr 4, 2017 at 3:40 PM, Tim Walters <walterswdf2(a)gmail.com> wrote: > > Just to wrap up (maybe). > > One, Marcin is quite right that the Article 29 WP's April 2014 opinion (WP > 217) provides rather detailed guidance on how legitimate interest may and > may not be used. Interestingly, at the recent CIPL event I attended in > Madrid, the industry representatives studiously ignored WP 217 and instead > repeatedly referred to WP 199, a 2012 opinion that considers how input > should (have) be(en) provided for the "data protection reform discussions" > i.e., the nascent GDPR. I was relieved to see that when the DPAs and EU > officials joined the discussion, they did not hesitate to cite from WP 217. > > Second, Iain said: > "And yes, there will be many in the ad tech space that try to utilise > ‘legitimate interest’ as an excuse to carry on business as usual. But there > are also at least a couple already that regard their platform as illegal > come 25th May 18, and taking steps accordingly. Interesting times ahead > in adtech." > > Could I get more information about these adtech players and what steps > they are taking in light of the perceived illegality of their tools? > > Cheers, > > tw > > > > On Mon, Apr 3, 2017 at 9:29 AM, Doc Searls <dsearls(a)cyber.law.harvard.edu> > wrote: > > First, big hats-off to this list and this thread. There are many good and > helpful answers to the original question, and to additional questions as > well. > > > > Second, it is essential to make clear where Customer Commons stands and > comes from, which is the individual customer. (And, since all individuals > other perhaps than babies are also customers, we’re talking about all > individuals here: the 100%.) > > > > Third, we are working on terms individuals assert as sovereign and > independent actors in the marketplace: in legal terms, as first parties. We > should each be able to proffer terms as first parties in our dealings with > the second parties of the world: namely, everybody else. We are starting > with two of those. > > > > Fourth, my questions about the GDPR are primarily about what kind of ease > the GDPR provides for individuals proffering terms as first parties, and > how (or to what degree) individuals proffering terms addresses both the > letter and spirit of the GDPR. > > > > Fifth, while it will be helpful for Customer Commons to specify how it > treats terms individuals respond to as second parties, it would be best for > other entities (e.g. CISWG/Consent Receipts, UMA/Authorization Server, > PDEC, Hyperledger, Sovrin Foundation, Indie Web...). Fortunately, others > are working on those things, and Customer Commons can coordinate with them. > (It helps that some of us are active in more than one of those efforts.) > > > > Sixth, we need to be very careful about framing all possible choices, > actions and outcomes inside standing administrative systems, which are > built to understand the individual entirely as a second party. This is why > ProjectVRM, Customer Commons and allied efforts are pioneering work. We > have been defaulted as second parties for so long, and in so many different > ways that it is very very hard to think and work outside that old incumbent > industrial age box. But we need to. (I should note that the GDPR does not > appear to comprehend the individual as a first party. But maybe I’m missing > it. What it does do, clearly, is recognize the individual as a sovereign > entity with a bundle of rights that need to be protected by law. This is a > Good Thing that I believe gives us some of the ease we need.) > > > > Seventh, at some point, and in some way (or ways), we need to grow > Customer Commons, beyond its current few members. Once we do that, we can > do a much better job of integrating with allied developers and development > efforts. Help with that is also welcome. > > > > Cheers, > > > > Doc > > > > On Apr 3, 2017, at 7:22 AM, Adrian Gropper <agropper(a)healthurl.com> wrote: > > > > Doc's original post is about Terms in Customer Commons. My comment about > GDPR and UMA is related to how Customer Commons decides to threat a term > for Transparency and a term for Consumer-Directed Sharing of data. > > > > As a starting point, I propose that we link some Customer Commons Terms > directly to GDPR as follows: > > > > A *Transparency Term* tells the customer how and where they will be > notified when their data is used. Apple, for example, notifies me every > time some of my data is modified (sign-in from a new machine, a charge of > $0.99 for a song) by sending an email to an address that I specify. This > Transparency Term is a cousin to consent receipts but, last time I looked, > the consent receipt did not actually address _contemporaneous_ transparency > of data use or the means by which a customer specifies where the consent > receipts are to be sent. This may have been fixed in later versions - if > so, my apologies in advance. > > > > A *Customer-Directed Sharing Term* tells the customer how they will be > able to direct a data controller to share data with a requesting party. Tim > Walters starts to point out where this intersects with GDPR in his comment > 10 hours ago. This is also where UMA comes in. I hope that UMA can directly > address this GDPR issue and that Customer Commons will figure out how to > make it clear to customers if they have a right to authorize sharing using > UMA or any other standard automated agent that does that. > > > > As far as advertising is concerned, data uses need to be at least > transparent and hopefully specifically authorized by may authorization > server _every time_. If I then decide that I only want aggregate > notifications once a quarter from the data controllers, then that should be > my choice. I don't think advertising is fundamentally different from any > other data uses in GDPR or anywhere else. If my data is used to target an > add for diapers, I expect Google to notify me that my data was shared with > a named broker that presented a Depends ad to me and I expect Google to > give me an opportunity to introduce an (UMA) Authorization Server to be > consulted the every time they decide to share my data with any other > business unit in Alphabet or with an outside party. > > > > Adrian > > > > > > > > On Sun, Apr 2, 2017 at 8:28 PM, Iain Henderson <iainhenderson(a)mac.com> > wrote: > > The post below is how I see some practical implications of GDPR > > > > > https://www.jlinclabs.com/you-want-my-data-sure-can-i-have-a-receipt-for-th… > > > > > That post was on the back of the recent ICO (UK) consent guidance. I was > surprised to see it so directly set out that most current consents held > will not meet the necessary standard, so re-permissioning will be required > at mass scale. > > > > We should not be thinking in black and white terms, there will be a range > of organisational responses, with only a small proportion taking the high > ground. I suspect that will pay off nicely for them. > > > > And yes, there will be many in the ad tech space that try to utilise > ‘legitimate interest’ as an excuse to carry on business as usual. But there > are also at least a couple already that regard their platform as illegal > come 25th May 18, and taking steps accordingly. Interesting times ahead in > adtech. > > > > As a community, my suggestion is that we get behind the concept of the > personal data receipt, aka consent receipt. I think if that story is told > well, the individual can inherently get that idea - ‘i give you my data, > you give me a receipt’. They don’t have to buy into that they can then use > that receipt, merely having one would get the ball rolling. > > > > Thoughts on personal data receipts as something to get behind? > > > > Cheers > > > > Iain > > > > > > > > > > On 2 Apr 2017, at 19:37, Marcin Betkier <Marcin.Betkier(a)vuw.ac.nz> wrote: > > > > Dear All, > > > > Just a couple of comments from (yet another) technology lawyer. > > > > The question about the relation between VRM and GDPR is an excellent one. > I just wanted to draw your attention to Article 29 Working Party’s > opinions: about data portability (end of last year, linked below by Manon), > and about “legitimate interest” grounds (April (?) 2014). They both shed > some light on the possible scope and limitations of data portability right. > > > > As per the relation in question, I think that VRM (as I understand it) is > simply more advanced concept than GDPR. GDPR is limited by thinking based > on OECD principles and, even deeper into the past, on FIPs from 1973. So, > instead of individual/customer right to independence (informational > self-determination, or autonomy, if you prefer) you have a number of > procedural provisions which, taken together, may not really do the job. As > a result, we need to look for VRM ideas in institutions like revocable > consent, right to object, data portability, or maybe privacy by design & > default. > > > > > > Best regards, > > > > Marcin > > > > *From:* Iain Henderson [mailto:iainhenderson@mac.com > <iainhenderson(a)mac.com>] > *Sent:* Monday, 3 April 2017 8:27 a.m. > *To:* Tim Walters <walterswdf2(a)gmail.com> > *Cc:* Manon Molins <mmolins(a)fing.org>; ProjectVRM list < > projectvrm(a)eon.law.harvard.edu> > *Subject:* Re: [projectvrm] GDPR and individuals as first parties > > > > Hi Doc, I think what we discussed before was having the individual point > to GDPR as at least one of the terms they propose. In addition we'd need to > create a formal Guidance doc that sets out the Customer Commons > interpretation of each of the key areas. So, as mentioned below, 'industry' > will wish to use their own interpretations; for example marketers (e.g. > through IAB 'guidance') might (i.e. are already) argue that digital > advertising is permitted as a legitimate interest of the recipient. That's > pretty dubious in most cases, but that's what's being argued, and without a > strong counter point could win. The Customer Commons Guidance would be much > more overtly on the side of the customer. So what the individual would be > pointing to in their terms offer would be 'GDPR, subject to Customer > Commons interpretation. > > > > Lots of detail to build in there, but I think the approach is solid. > > > > Iain > > > On 2 Apr 2017, at 16:06, Tim Walters <walterswdf2(a)gmail.com> wrote: > > Manon - > > Thanks for the information. I'm very interested in attending Mydata and > will seriously consider submitting a proposal. > > Concerning data portability: Zbynek is right that this is the most direct > connection to VRM in the GDPR. However, it is important to be aware of the > conditions or restrictions. Article 20 states: > > "The data subject shall have the right to receive the personal data > concerning him or her, which he or she has provided to a controller, in a > structured, commonly used and machine-readable format and have the right to > transmit those data to another controller without hindrance from the > controller to which the personal data have been provided, where [and I > stress, *only* where]: > > (a) the processing is based on consent pursuant to point (a) of Article > 6(1) or point (a) of Article 9(2) or on a contract pursuant to point (b) of > Article 6(1); and > (b) the processing is carried out by automated means." > > The provisions listed in (a) refer to consent provided by the data subject > (Article 6(1) and Article 9(2)) or data required for the performance of a > contract (Article 6(1)(b).) > > Consent and performance of a contract are two of the six legal grounds for > data collection and processing. Of the remaining four, the most > interesting/troubling is "legitimate interest." I won't go into the many > details here -- in fact this could be the subject of a presentation at > Mydata -- but suffice to say that businesses have multiple incentives to > use the legitimate interest ground (thus excluding data from the > portability requirements) and for the purview of that ground to be a broad > as possible (thus legitimizing wide(r) spread data collection). > > I recently witnessed industry representatives and EU data protection > authorities (DPAs) playing handball with legitimate interest in a joint > meeting. I was pleased to see that the DPAs resisted all efforts to make > legitimate interests a "get out of jail free card" for intrusive marketing. > But continued vigilance will certainly be necessary. > > Cheers, > > tw > > > > > > On Sun, Apr 2, 2017 at 11:58 AM, Manon Molins <mmolins(a)fing.org> wrote: > > Hello, > > > > +1 Zbynek, the data portability right is indeed the VRM core of the GDPR. > > > > "The data subject shall have the right to receive the personal data > concerning him or her, which he or she has provided to a controller, in a > structured, commonly used and machine-readable format and have the right to > transmit those data to another controller without hindrance from the > controller to which the data have been provided" > > > > Maybe you have already seen the G29’s Guidelines on the right to data > portability > <http://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp2…> > . > > - The Midata project in United Kingdom + the MesInfos project (Fing) > <http://mydata2016.org/2016/07/27/if-i-can-use-your-data-you-can-too-however…> in > France are listed examples of those guidelines on how this portability > right can foster innovation in Europe. > - Individuals will be able to transmit their data from a controller to > another (this other controller can be another competing organisation or a > third-party service, a Pims - as Zbynek said : « VRM tools (private clouds, > personal assistants, etc.) » > - Data concerned by this right is the one provided by the individual - > see p7 - and this term cover so much more than just address, name, etc. > It’s the data resulting in the relationship between the individual and the > data controller/organisation. Ex: consumption data from smart meters, from > loyalty programs, from IoT, browsing history, geolocation, list of calls > (telco), bank data, etc. > > > > Companies will need to be GDPR compliant by may 2018, they are positioning > themselves as we speak to see how (creating API, download functionalities, > etc.). > > > > You may know this too, but just a reminder: the main European event on the > subject (on VRM, My Data, Self Data, Pims economy, etc. - so many names to > speak of individual empowerment through data!) is called Mydata2017 - > Advancing Human Centric Personal Data <http://mydata2017.org/> (end of > August/beginning of September in Helsinki and Tallinn). > > - It will have a specific track on GDPR > <http://mydata2017.org/programme/tracks/#gdpr>. At Mydata2016 (in > which Doc spoke) we had a presentation of the GDPR by Edouard Geffray the > General Secretary of the National Commission for Information Technology and > Civil Liberties (CNIL). Now that it is « out » we will be able to go even > deeper. > - It’s a collaborative event, in which anyone can contribute to the > program, and we need your input for our 12 tracks :) > - We can contribute through the call for proposals > <http://mydata2017.org/programme/call-for-proposals/>(if you think of > a speaker, a session, a use case, …), it is open till mid-april! > - If you want to come, the registration opens up mid-april: > http://mydata2017.org/registration/ > > > > > > Best to all, > > > > Manon on behalf of the MesInfos project team > > ———————————————————————————————— > > *FING - association pour la Fondation Internet Nouvelle Génération * > > Manon Molins - mmolins(a)fing.org <dkaplan(a)fing.org> - 06 85 86 47 05 > http://www.fing.org / http://www.internetactu.net > > *Soutenez les actions et travaux de la Fing, *adhérez ! > <http://fing.org/?-Adhesion-> > > > > Le 2 avr. 2017 à 10:34, zbynek(a)loebl.info a écrit : > > > > Dear Doc and others, > > I rarely contribute to your discussion. I am a technology lawyer from > Czechia and in this capacity I deal with GDPR in detail. I agree with Tim > that GDPR has a VRM core. In addition to what Tim mentions in his email I > would add data portability (Art. 20). This Article contains a totally new > right of data subjects to request transfer of their data provided to the > data controller based on consent or contract in a standard format. > > Data subjects can transfer their data to a new data controller or control > them themselves using - VRM tools (private clouds, personal assistants > etc.). This is a direct link to what you are preparing - via such VRM tools > data subjects can negotiate contract terms with service providers, they can > provide them with necessary authenticity checks regarding data subjects or > their childern etc. > > Best personal wishes, > > Zbynek > > Dne 2017-04-01 23:47, Tim Walters napsal: > > I'm not sure if this is useful, but: > Article 5 spells out the fundamental principles of personal data > collection/processing. these are (more detail upon request): > * lawfulness, fairness, and transparency > * purpose limitation [i.e., the controller must state precisely what > the collected data will be used for, and use it only for the purpose] > * data minimization [i.e., use only what is necessary for the stated > purpose] > * accuracy [i.e., controller has an obligation to ensure that data is > accurate and up to date] > * storage limitation [i.e., kept no longer than necessary for the > stated purpose] > * integrity and confidentiality [i.e., data is secure] > This if followed by a "behavioral" requirement for "accountability" -- > i.e., not only must you follow all of these principles, you must be > able to demonstrate and document that you do so. > However -- I think these stated principles are based in and in certain > ways trumped by a more fundamental conviction: namely, that personal > data always only belongs to the person it identifies. > Recital 7 states: "Natural persons should have control of their own > personal data." And it ties this directly to "the importance of > creating trust that will allow the digital economy to develop across > the internal [EU] market." > I recently attended an event in which Telefonica presented their > "Aura" personal data management platform. It clearly does not adhere > to each of the six core principles, but it does express the notion > that people should control their own data. I asked two EU data > protection authorities what they thought of it. Naturally, they would > not give a definitive judgement. But they did both say that they like > the innovative approach to putting people in charge of their data, > even if it did not accord with every one of the principles. > Cheers, > tw > On Sat, Apr 1, 2017 at 8:27 PM, Adrian Gropper > <agropper(a)healthurl.com> wrote: > > Is'nt it important to be able to signal that the entity seeking > consent must register with and contact a standard authorization > server? > This particular term ought to be a profile of UMA labeled and > documented for GDPR. > Adrian > On Sat, Apr 1, 2017 at 10:26 AM Mike O'Neill > <michael.oneill(a)baycloud.com> wrote: > > Hi Doc, > The GDPR does not have much in terms of signalling from the user > (aka the Data Subject), other than the ability to give or revoke > consent, and the right to object. > Article 4.11 defines consent, Article 6.1(a) says it is one of the > legal bases for processing, Recital 32 further describes it, plus > other Recitals refer to it. > Article 21 deals with the right to object, especially A21.5 which > says it can be expressed by "automated means". This applies when > another basis for processing (other than consent) is claimed. > In terms of information required to be given by companies i.e. > website (the Data Controller), this is spread throughout but > Article 13 covers most of it. > The other place which deals with user signalling, i.e. consent, > ability to revoke at any time etc. is the proposed ePrivacy > Regulation which is supposed to come into force at the same time > as the GDPR, though it is still being debated. Here is a link to > the proposal: > > > https://ec.europa.eu/digital-single-market/en/news/proposal-regulation-priv… > > [1] > Mike > > -----Original Message----- > From: Doc Searls [mailto:doc@searls.com] > Sent: 01 April 2017 14:34 > To: ProjectVRM list <projectvrm(a)eon.law.harvard.edu> > Subject: [projectvrm] GDPR and individuals as first parties > Customer Commons and its partners are working on terms > > individuals proffer as > > first parties in dealings with sites and services acting as > > second parties can > > satisfy both the letter and the spirit of the GDPR—or at least > > some of its > > requirements. > Since there are people on this list who know the GDPR better > > than I, it would be > > good if we could get pointed to the parts of the GDPR that > > justify this claim. I > > believe somebody here (Iain?) has done this before, but I > > can’t find anything > > right now, so help would be welcome. > Thanks! > Documents: > The GDPR in English HTML— > <http://eur-lex.europa.eu/legal- [2] > content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN <http://eur- > lex.europa.eu/legal- [3] > content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN>> > The Wikipedia page on the GDPR— > > <https://en.wikipedia.org/wiki/General_Data_Protection_Regulation > [4]> > > Doc > > -- > 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/ [5] > > Links: > ------ > [1] > > https://ec.europa.eu/digital-single-market/en/news/proposal-regulation-priv… > [2] http://eur-lex.europa.eu/legal- > [3] http://lex.europa.eu/legal- > [4] https://en.wikipedia.org/wiki/General_Data_Protection_Regulation > [5] 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/ > > > > > > > > > > > > -- > > > > 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/ > > > _______________________________________________ > WG-UMA mailing list > WG-UMA(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > > > -- 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

Re: [WG-UMA] [projectvrm] GDPR and individuals as first parties
by Adrian Gropper 05 Apr '17

05 Apr '17

Thanks, Tim for the GDPR review. The comments on portability are particularly relevant to UMA. There are many ways to interpret portability: (a) give me the data and then close access or delete it (b) put the data under my control and allow me to decide what 3rd party can access it (c) put the data under my control and allow me and my agent to decide what 3rd party can access it (d) give out the data under a standard format, protocol, and authorization process (e) give out the data in whatever format you want and with your special or proprietary authorization process When we talk about terms and receipts it's important to make clear if and how a data holder interprets portability. Does GDPR differentiate between (a) - (e)? Is there anything other than UMA that can do (c)? Adrian On Wed, Apr 5, 2017 at 9:55 AM, Tim Walters <walterswdf2(a)gmail.com> wrote: > For what it's worth, I just noticed that the WP 217 opinion does include > this specific enthusiastic reference to PIM-type platforms ("midata"). > (This is pp. 47-48.) > > Data portability, 'midata' and related issues > Among the additional safeguards which might help tip the balance, special > attention should be given to data portability and related measures, which > may be increasingly relevant in an on-line environment. The Working Party > recalls its Opinion on Purpose Limitation where it has emphasised that 'in > many situations, safeguards such as allowing data subjects/customers to > have direct access to their data in a portable, user-friendly and > machine-readable format may help empower them, and redress the economic > imbalance between large corporations on the one hand and data > subjects/consumers on the other. It would also let individuals 'share the > wealth' created by big data and incentivise developers to offer additional > features and applications to their users.109 > > The availability of workable mechanisms for the data subjects to access, > modify, delete, transfer, or otherwise further process (or let third > parties further process) their own data will empower data subjects and let > them benefit more from digital services. In addition, it can foster a more > competitive market environment, by allowing customers more easily to switch > providers (e.g. in the context of online banking or in case of energy > suppliers in a smart grid environment). Finally, it can also contribute to > the development of additional value-added services by third parties who may > be able to access the customers' data at the request and based on the > consent of the customers. In this perspective, data portability is > therefore not only good for data protection, but also for competition and > consumer protection.110 > > Notes: > 108 See Annex II (on Big Data and Open Data) of the Opinion (cited in > footnote 9 above), page 45. > 109 'See initiatives such as 'midata' in the UK, which are based on the > key principle that data should be released back to consumers. Midata is a > voluntary programme, which over time should give consumers increasing > access to their personal data in a portable, electronic format. The key > idea is that consumers should also benefit from big data by having access > to their own information to enable them to make better choices. See also > 'Green button' initiatives that allow consumers to access their own energy > usage information.' For more information on initiatives in the UK and in > France see http://www.midatalab.org.uk/ and http://mesinfos.fing.org/. > 110 On the right to data portability, see Article 18 of the Proposed > Regulation. > > On Tue, Apr 4, 2017 at 3:40 PM, Tim Walters <walterswdf2(a)gmail.com> wrote: > >> Just to wrap up (maybe). >> >> One, Marcin is quite right that the Article 29 WP's April 2014 opinion >> (WP 217) provides rather detailed guidance on how legitimate interest may >> and may not be used. Interestingly, at the recent CIPL event I attended in >> Madrid, the industry representatives studiously ignored WP 217 and instead >> repeatedly referred to WP 199, a 2012 opinion that considers how input >> should (have) be(en) provided for the "data protection reform discussions" >> i.e., the nascent GDPR. I was relieved to see that when the DPAs and EU >> officials joined the discussion, they did not hesitate to cite from WP 217. >> >> Second, Iain said: >> "And yes, there will be many in the ad tech space that try to utilise >> ‘legitimate interest’ as an excuse to carry on business as usual. But there >> are also at least a couple already that regard their platform as illegal >> come 25th May 18, and taking steps accordingly. Interesting times ahead >> in adtech." >> >> Could I get more information about these adtech players and what steps >> they are taking in light of the perceived illegality of their tools? >> >> Cheers, >> tw >> >> On Mon, Apr 3, 2017 at 9:29 AM, Doc Searls <dsearls(a)cyber.law.harvard.edu >> > wrote: >> >>> First, big hats-off to this list and this thread. There are many good >>> and helpful answers to the original question, and to additional questions >>> as well. >>> >>> Second, it is essential to make clear where Customer Commons stands and >>> comes from, which is the individual customer. (And, since all individuals >>> other perhaps than babies are also customers, we’re talking about all >>> individuals here: the 100%.) >>> >>> Third, we are working on terms individuals assert as sovereign and >>> independent actors in the marketplace: in legal terms, as first parties. We >>> should each be able to proffer terms as first parties in our dealings with >>> the second parties of the world: namely, everybody else. We are starting >>> with two of those. >>> >>> Fourth, my questions about the GDPR are primarily about what kind of >>> ease the GDPR provides for individuals proffering terms as first parties, >>> and how (or to what degree) individuals proffering terms addresses both the >>> letter and spirit of the GDPR. >>> >>> Fifth, while it will be helpful for Customer Commons to specify how it >>> treats terms individuals respond to as second parties, it would be best for >>> other entities (e.g. CISWG/Consent Receipts, UMA/Authorization Server, >>> PDEC, Hyperledger, Sovrin Foundation, Indie Web...). Fortunately, others >>> are working on those things, and Customer Commons can coordinate with them. >>> (It helps that some of us are active in more than one of those efforts.) >>> >>> Sixth, we need to be very careful about framing all possible choices, >>> actions and outcomes inside standing administrative systems, which are >>> built to understand the individual entirely as a second party. This is why >>> ProjectVRM, Customer Commons and allied efforts are pioneering work. We >>> have been defaulted as second parties for so long, and in so many different >>> ways that it is very very hard to think and work outside that old incumbent >>> industrial age box. But we need to. (I should note that the GDPR does not >>> appear to comprehend the individual as a first party. But maybe I’m missing >>> it. What it does do, clearly, is recognize the individual as a sovereign >>> entity with a bundle of rights that need to be protected by law. This is a >>> Good Thing that I believe gives us some of the ease we need.) >>> >>> Seventh, at some point, and in some way (or ways), we need to grow >>> Customer Commons, beyond its current few members. Once we do that, we can >>> do a much better job of integrating with allied developers and development >>> efforts. Help with that is also welcome. >>> >>> Cheers, >>> >>> Doc >>> >>> On Apr 3, 2017, at 7:22 AM, Adrian Gropper <agropper(a)healthurl.com> >>> wrote: >>> >>> Doc's original post is about Terms in Customer Commons. My comment about >>> GDPR and UMA is related to how Customer Commons decides to threat a term >>> for Transparency and a term for Consumer-Directed Sharing of data. >>> >>> As a starting point, I propose that we link some Customer Commons Terms >>> directly to GDPR as follows: >>> >>> A *Transparency Term* tells the customer how and where they will be >>> notified when their data is used. Apple, for example, notifies me every >>> time some of my data is modified (sign-in from a new machine, a charge of >>> $0.99 for a song) by sending an email to an address that I specify. This >>> Transparency Term is a cousin to consent receipts but, last time I looked, >>> the consent receipt did not actually address _contemporaneous_ transparency >>> of data use or the means by which a customer specifies where the consent >>> receipts are to be sent. This may have been fixed in later versions - if >>> so, my apologies in advance. >>> >>> A *Customer-Directed Sharing Term* tells the customer how they will be >>> able to direct a data controller to share data with a requesting party. Tim >>> Walters starts to point out where this intersects with GDPR in his comment >>> 10 hours ago. This is also where UMA comes in. I hope that UMA can directly >>> address this GDPR issue and that Customer Commons will figure out how to >>> make it clear to customers if they have a right to authorize sharing using >>> UMA or any other standard automated agent that does that. >>> >>> As far as advertising is concerned, data uses need to be at least >>> transparent and hopefully specifically authorized by may authorization >>> server _every time_. If I then decide that I only want aggregate >>> notifications once a quarter from the data controllers, then that should be >>> my choice. I don't think advertising is fundamentally different from any >>> other data uses in GDPR or anywhere else. If my data is used to target an >>> add for diapers, I expect Google to notify me that my data was shared with >>> a named broker that presented a Depends ad to me and I expect Google to >>> give me an opportunity to introduce an (UMA) Authorization Server to be >>> consulted the every time they decide to share my data with any other >>> business unit in Alphabet or with an outside party. >>> >>> Adrian >>> >>> >>> >>> On Sun, Apr 2, 2017 at 8:28 PM, Iain Henderson <iainhenderson(a)mac.com> >>> wrote: >>> >>>> The post below is how I see some practical implications of GDPR >>>> >>>> https://www.jlinclabs.com/you-want-my-data-sure-can-i-have-a >>>> -receipt-for-that/ >>>> >>>> That post was on the back of the recent ICO (UK) consent guidance. I >>>> was surprised to see it so directly set out that most current consents held >>>> will not meet the necessary standard, so re-permissioning will be required >>>> at mass scale. >>>> >>>> We should not be thinking in black and white terms, there will be a >>>> range of organisational responses, with only a small proportion taking the >>>> high ground. I suspect that will pay off nicely for them. >>>> >>>> And yes, there will be many in the ad tech space that try to utilise >>>> ‘legitimate interest’ as an excuse to carry on business as usual. But there >>>> are also at least a couple already that regard their platform as illegal >>>> come 25th May 18, and taking steps accordingly. Interesting times ahead in >>>> adtech. >>>> >>>> As a community, my suggestion is that we get behind the concept of the >>>> personal data receipt, aka consent receipt. I think if that story is told >>>> well, the individual can inherently get that idea - ‘i give you my data, >>>> you give me a receipt’. They don’t have to buy into that they can then use >>>> that receipt, merely having one would get the ball rolling. >>>> >>>> Thoughts on personal data receipts as something to get behind? >>>> >>>> Cheers >>>> >>>> Iain >>>> >>>> >>>> >>>> >>>> On 2 Apr 2017, at 19:37, Marcin Betkier <Marcin.Betkier(a)vuw.ac.nz> >>>> wrote: >>>> >>>> Dear All, >>>> >>>> Just a couple of comments from (yet another) technology lawyer. >>>> >>>> The question about the relation between VRM and GDPR is an excellent >>>> one. I just wanted to draw your attention to Article 29 Working Party’s >>>> opinions: about data portability (end of last year, linked below by Manon), >>>> and about “legitimate interest” grounds (April (?) 2014). They both shed >>>> some light on the possible scope and limitations of data portability right. >>>> >>>> As per the relation in question, I think that VRM (as I understand it) >>>> is simply more advanced concept than GDPR. GDPR is limited by thinking >>>> based on OECD principles and, even deeper into the past, on FIPs from 1973. >>>> So, instead of individual/customer right to independence (informational >>>> self-determination, or autonomy, if you prefer) you have a number of >>>> procedural provisions which, taken together, may not really do the job. As >>>> a result, we need to look for VRM ideas in institutions like revocable >>>> consent, right to object, data portability, or maybe privacy by design & >>>> default. >>>> >>>> >>>> Best regards, >>>> >>>> Marcin >>>> >>>> *From:* Iain Henderson [mailto:iainhenderson@mac.com >>>> <iainhenderson(a)mac.com>] >>>> *Sent:* Monday, 3 April 2017 8:27 a.m. >>>> *To:* Tim Walters <walterswdf2(a)gmail.com> >>>> *Cc:* Manon Molins <mmolins(a)fing.org>; ProjectVRM list < >>>> projectvrm(a)eon.law.harvard.edu> >>>> *Subject:* Re: [projectvrm] GDPR and individuals as first parties >>>> >>>> Hi Doc, I think what we discussed before was having the individual >>>> point to GDPR as at least one of the terms they propose. In addition we'd >>>> need to create a formal Guidance doc that sets out the Customer Commons >>>> interpretation of each of the key areas. So, as mentioned below, 'industry' >>>> will wish to use their own interpretations; for example marketers (e.g. >>>> through IAB 'guidance') might (i.e. are already) argue that digital >>>> advertising is permitted as a legitimate interest of the recipient. That's >>>> pretty dubious in most cases, but that's what's being argued, and without a >>>> strong counter point could win. The Customer Commons Guidance would be much >>>> more overtly on the side of the customer. So what the individual would be >>>> pointing to in their terms offer would be 'GDPR, subject to Customer >>>> Commons interpretation. >>>> >>>> Lots of detail to build in there, but I think the approach is solid. >>>> >>>> Iain >>>> >>>> >>>> On 2 Apr 2017, at 16:06, Tim Walters <walterswdf2(a)gmail.com> wrote: >>>> >>>> Manon - >>>> >>>> Thanks for the information. I'm very interested in attending Mydata and >>>> will seriously consider submitting a proposal. >>>> >>>> Concerning data portability: Zbynek is right that this is the most >>>> direct connection to VRM in the GDPR. However, it is important to be aware >>>> of the conditions or restrictions. Article 20 states: >>>> >>>> "The data subject shall have the right to receive the personal data >>>> concerning him or her, which he or she has provided to a controller, in a >>>> structured, commonly used and machine-readable format and have the right to >>>> transmit those data to another controller without hindrance from the >>>> controller to which the personal data have been provided, where [and I >>>> stress, *only* where]: >>>> >>>> (a) the processing is based on consent pursuant to point (a) of Article >>>> 6(1) or point (a) of Article 9(2) or on a contract pursuant to point (b) of >>>> Article 6(1); and >>>> (b) the processing is carried out by automated means." >>>> >>>> The provisions listed in (a) refer to consent provided by the data >>>> subject (Article 6(1) and Article 9(2)) or data required for the >>>> performance of a contract (Article 6(1)(b).) >>>> >>>> Consent and performance of a contract are two of the six legal grounds >>>> for data collection and processing. Of the remaining four, the most >>>> interesting/troubling is "legitimate interest." I won't go into the many >>>> details here -- in fact this could be the subject of a presentation at >>>> Mydata -- but suffice to say that businesses have multiple incentives to >>>> use the legitimate interest ground (thus excluding data from the >>>> portability requirements) and for the purview of that ground to be a broad >>>> as possible (thus legitimizing wide(r) spread data collection). >>>> >>>> I recently witnessed industry representatives and EU data protection >>>> authorities (DPAs) playing handball with legitimate interest in a joint >>>> meeting. I was pleased to see that the DPAs resisted all efforts to make >>>> legitimate interests a "get out of jail free card" for intrusive marketing. >>>> But continued vigilance will certainly be necessary. >>>> Cheers, >>>> tw >>>> >>>> >>>> >>>> On Sun, Apr 2, 2017 at 11:58 AM, Manon Molins <mmolins(a)fing.org> wrote: >>>> >>>> Hello, >>>> >>>> +1 Zbynek, the data portability right is indeed the VRM core of the >>>> GDPR. >>>> >>>> "The data subject shall have the right to receive the personal data >>>> concerning him or her, which he or she has provided to a controller, in a >>>> structured, commonly used and machine-readable format and have the right to >>>> transmit those data to another controller without hindrance from the >>>> controller to which the data have been provided" >>>> >>>> Maybe you have already seen the G29’s Guidelines on the right to data >>>> portability >>>> <http://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp2…> >>>> . >>>> >>>> - The Midata project in United Kingdom + the MesInfos project (Fing) >>>> <http://mydata2016.org/2016/07/27/if-i-can-use-your-data-you-can-too-however…> in >>>> France are listed examples of those guidelines on how this portability >>>> right can foster innovation in Europe. >>>> - Individuals will be able to transmit their data from a controller >>>> to another (this other controller can be another competing organisation or >>>> a third-party service, a Pims - as Zbynek said : « VRM tools (private >>>> clouds, personal assistants, etc.) » >>>> - Data concerned by this right is the one provided by the >>>> individual - see p7 - and this term cover so much more than just address, >>>> name, etc. It’s the data resulting in the relationship between the >>>> individual and the data controller/organisation. Ex: consumption data from >>>> smart meters, from loyalty programs, from IoT, browsing history, >>>> geolocation, list of calls (telco), bank data, etc. >>>> >>>> >>>> Companies will need to be GDPR compliant by may 2018, they are >>>> positioning themselves as we speak to see how (creating API, download >>>> functionalities, etc.). >>>> >>>> You may know this too, but just a reminder: the main European event on >>>> the subject (on VRM, My Data, Self Data, Pims economy, etc. - so many names >>>> to speak of individual empowerment through data!) is called Mydata2017 >>>> - Advancing Human Centric Personal Data <http://mydata2017.org/> (end >>>> of August/beginning of September in Helsinki and Tallinn). >>>> >>>> - It will have a specific track on GDPR >>>> <http://mydata2017.org/programme/tracks/#gdpr>. At Mydata2016 (in >>>> which Doc spoke) we had a presentation of the GDPR by Edouard Geffray the >>>> General Secretary of the National Commission for Information Technology and >>>> Civil Liberties (CNIL). Now that it is « out » we will be able to go even >>>> deeper. >>>> - It’s a collaborative event, in which anyone can contribute to the >>>> program, and we need your input for our 12 tracks :) >>>> - We can contribute through the call for proposals >>>> <http://mydata2017.org/programme/call-for-proposals/>(if you think >>>> of a speaker, a session, a use case, …), it is open till mid-april! >>>> - If you want to come, the registration opens up mid-april: >>>> http://mydata2017.org/registration/ >>>> <http://mydata2017.org/registration/> >>>> >>>> >>>> >>>> Best to all, >>>> >>>> Manon on behalf of the MesInfos project team >>>> ———————————————————————————————— >>>> *FING - association pour la Fondation Internet Nouvelle Génération * >>>> Manon Molins - mmolins(a)fing.org <dkaplan(a)fing.org> - 06 85 86 47 05 >>>> http://www.fing.org / http://www.internetactu.net >>>> *Soutenez les actions et travaux de la Fing, *adhérez ! >>>> <http://fing.org/?-Adhesion-> >>>> >>>> >>>> Le 2 avr. 2017 à 10:34, zbynek(a)loebl.info a écrit : >>>> >>>> Dear Doc and others, >>>> >>>> I rarely contribute to your discussion. I am a technology lawyer from >>>> Czechia and in this capacity I deal with GDPR in detail. I agree with Tim >>>> that GDPR has a VRM core. In addition to what Tim mentions in his email I >>>> would add data portability (Art. 20). This Article contains a totally new >>>> right of data subjects to request transfer of their data provided to the >>>> data controller based on consent or contract in a standard format. >>>> >>>> Data subjects can transfer their data to a new data controller or >>>> control them themselves using - VRM tools (private clouds, personal >>>> assistants etc.). This is a direct link to what you are preparing - via >>>> such VRM tools data subjects can negotiate contract terms with service >>>> providers, they can provide them with necessary authenticity checks >>>> regarding data subjects or their childern etc. >>>> >>>> Best personal wishes, >>>> >>>> Zbynek >>>> >>>> Dne 2017-04-01 23:47, Tim Walters napsal: >>>> >>>> I'm not sure if this is useful, but: >>>> Article 5 spells out the fundamental principles of personal data >>>> collection/processing. these are (more detail upon request): >>>> * lawfulness, fairness, and transparency >>>> * purpose limitation [i.e., the controller must state precisely what >>>> the collected data will be used for, and use it only for the purpose] >>>> * data minimization [i.e., use only what is necessary for the stated >>>> purpose] >>>> * accuracy [i.e., controller has an obligation to ensure that data is >>>> accurate and up to date] >>>> * storage limitation [i.e., kept no longer than necessary for the >>>> stated purpose] >>>> * integrity and confidentiality [i.e., data is secure] >>>> This if followed by a "behavioral" requirement for "accountability" -- >>>> i.e., not only must you follow all of these principles, you must be >>>> able to demonstrate and document that you do so. >>>> However -- I think these stated principles are based in and in certain >>>> ways trumped by a more fundamental conviction: namely, that personal >>>> data always only belongs to the person it identifies. >>>> Recital 7 states: "Natural persons should have control of their own >>>> personal data." And it ties this directly to "the importance of >>>> creating trust that will allow the digital economy to develop across >>>> the internal [EU] market." >>>> I recently attended an event in which Telefonica presented their >>>> "Aura" personal data management platform. It clearly does not adhere >>>> to each of the six core principles, but it does express the notion >>>> that people should control their own data. I asked two EU data >>>> protection authorities what they thought of it. Naturally, they would >>>> not give a definitive judgement. But they did both say that they like >>>> the innovative approach to putting people in charge of their data, >>>> even if it did not accord with every one of the principles. >>>> Cheers, >>>> tw >>>> On Sat, Apr 1, 2017 at 8:27 PM, Adrian Gropper >>>> <agropper(a)healthurl.com> wrote: >>>> >>>> Is'nt it important to be able to signal that the entity seeking >>>> consent must register with and contact a standard authorization >>>> server? >>>> This particular term ought to be a profile of UMA labeled and >>>> documented for GDPR. >>>> Adrian >>>> On Sat, Apr 1, 2017 at 10:26 AM Mike O'Neill >>>> <michael.oneill(a)baycloud.com> wrote: >>>> >>>> Hi Doc, >>>> The GDPR does not have much in terms of signalling from the user >>>> (aka the Data Subject), other than the ability to give or revoke >>>> consent, and the right to object. >>>> Article 4.11 defines consent, Article 6.1(a) says it is one of the >>>> legal bases for processing, Recital 32 further describes it, plus >>>> other Recitals refer to it. >>>> Article 21 deals with the right to object, especially A21.5 which >>>> says it can be expressed by "automated means". This applies when >>>> another basis for processing (other than consent) is claimed. >>>> In terms of information required to be given by companies i.e. >>>> website (the Data Controller), this is spread throughout but >>>> Article 13 covers most of it. >>>> The other place which deals with user signalling, i.e. consent, >>>> ability to revoke at any time etc. is the proposed ePrivacy >>>> Regulation which is supposed to come into force at the same time >>>> as the GDPR, though it is still being debated. Here is a link to >>>> the proposal: >>>> >>>> https://ec.europa.eu/digital-single-market/en/news/proposal- >>>> regulation-privacy-and-electronic-communications >>>> >>>> [1] >>>> Mike >>>> >>>> -----Original Message----- >>>> From: Doc Searls [mailto:doc@searls.com] >>>> Sent: 01 April 2017 14:34 >>>> To: ProjectVRM list <projectvrm(a)eon.law.harvard.edu> >>>> Subject: [projectvrm] GDPR and individuals as first parties >>>> Customer Commons and its partners are working on terms >>>> >>>> individuals proffer as >>>> >>>> first parties in dealings with sites and services acting as >>>> >>>> second parties can >>>> >>>> satisfy both the letter and the spirit of the GDPR—or at least >>>> >>>> some of its >>>> >>>> requirements. >>>> Since there are people on this list who know the GDPR better >>>> >>>> than I, it would be >>>> >>>> good if we could get pointed to the parts of the GDPR that >>>> >>>> justify this claim. I >>>> >>>> believe somebody here (Iain?) has done this before, but I >>>> >>>> can’t find anything >>>> >>>> right now, so help would be welcome. >>>> Thanks! >>>> Documents: >>>> The GDPR in English HTML— >>>> <http://eur-lex.europa.eu/legal- [2] >>>> content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN <http://eur- >>>> lex.europa.eu/legal- [3] >>>> content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN>> >>>> The Wikipedia page on the GDPR— >>>> >>>> <https://en.wikipedia.org/wiki/General_Data_Protection_Regulation >>>> [4]> >>>> >>>> Doc >>>> >>>> -- >>>> 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/ [5] >>>> >>>> Links: >>>> ------ >>>> [1] >>>> https://ec.europa.eu/digital-single-market/en/news/proposal- >>>> regulation-privacy-and-electronic-communications >>>> [2] http://eur-lex.europa.eu/legal- >>>> [3] http://lex.europa.eu/legal- >>>> [4] https://en.wikipedia.org/wiki/General_Data_Protection_Regulation >>>> [5] 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/ >>> >>> >>> >> > -- 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

No WG call this week (Thu, Apr 6); proposing a discretionary ad hoc call next Tuesday
by Eve Maler 05 Apr '17

05 Apr '17

Instead, I'd like to ask people to review the specs and open issues, and prepare final comments in preparation for next week; we said our "WG last call" would end by Tue, Apr 11. Our current substantive open issues look like this: - *#290 <https://github.com/KantaraInitiative/wg-uma/issues/290> (Generality of RReg spec?) and #296 <https://github.com/KantaraInitiative/wg-uma/issues/296> (Out-of-the-box profiling for tight AS-RS coupling):* This is a biggie. Current proposal (for which I hope to have some more details soon) is to consider a different way of modularizing the specs. A group consisting of me, Mark L, Maciej, Andi, and Cigdem talked about this further in London on Monday and there was a pretty strongly favorable impression. - *#294 <https://github.com/KantaraInitiative/wg-uma/issues/294> (Consider a proof-of-possession option for the RPT):* This topic is broader by now, including token binding etc., and we suspect this all might "just work". This just needs to be analyzed a bit. *Prabath*, you were going to take a look -- can you, please, and write up? - *#295 <https://github.com/KantaraInitiative/wg-uma/issues/295> (When a requesting party needs to withdraw their access):* This touches on downscoping and token revocation, and thus could use some analysis. *Justin*, this could use your eyeballs in particular, but it's really for *everyone*. - *#298 <https://github.com/KantaraInitiative/wg-uma/issues/298> (Reconsider whether ticket should be on all redirect-back AS responses):* Justin and Cigdem have been commenting on this one and seem to have consensus so far that we're okay, but it could use more eyeballs. But another related issue has come up about the appropriateness of not_authorized as an error that we could consider. For anyone interested, I'd like to propose an ad hoc meeting next *Tue, Apr 11* at 9am PT to discuss these issues (and any others people report), in addition to our regular *Thu, Apr 13* call. I'll make the changes to the calendar right now. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Re: [WG-UMA] [projectvrm] GDPR and individuals as first parties
by Adrian Gropper 03 Apr '17

03 Apr '17

Doc's original post is about Terms in Customer Commons. My comment about GDPR and UMA is related to how Customer Commons decides to threat a term for Transparency and a term for Consumer-Directed Sharing of data. As a starting point, I propose that we link some Customer Commons Terms directly to GDPR as follows: A *Transparency Term* tells the customer how and where they will be notified when their data is used. Apple, for example, notifies me every time some of my data is modified (sign-in from a new machine, a charge of $0.99 for a song) by sending an email to an address that I specify. This Transparency Term is a cousin to consent receipts but, last time I looked, the consent receipt did not actually address _contemporaneous_ transparency of data use or the means by which a customer specifies where the consent receipts are to be sent. This may have been fixed in later versions - if so, my apologies in advance. A *Customer-Directed Sharing Term* tells the customer how they will be able to direct a data controller to share data with a requesting party. Tim Walters starts to point out where this intersects with GDPR in his comment 10 hours ago. This is also where UMA comes in. I hope that UMA can directly address this GDPR issue and that Customer Commons will figure out how to make it clear to customers if they have a right to authorize sharing using UMA or any other standard automated agent that does that. As far as advertising is concerned, data uses need to be at least transparent and hopefully specifically authorized by may authorization server _every time_. If I then decide that I only want aggregate notifications once a quarter from the data controllers, then that should be my choice. I don't think advertising is fundamentally different from any other data uses in GDPR or anywhere else. If my data is used to target an add for diapers, I expect Google to notify me that my data was shared with a named broker that presented a Depends ad to me and I expect Google to give me an opportunity to introduce an (UMA) Authorization Server to be consulted the every time they decide to share my data with any other business unit in Alphabet or with an outside party. Adrian On Sun, Apr 2, 2017 at 8:28 PM, Iain Henderson <iainhenderson(a)mac.com> wrote: > The post below is how I see some practical implications of GDPR > > https://www.jlinclabs.com/you-want-my-data-sure-can-i-have- > a-receipt-for-that/ > > That post was on the back of the recent ICO (UK) consent guidance. I was > surprised to see it so directly set out that most current consents held > will not meet the necessary standard, so re-permissioning will be required > at mass scale. > > We should not be thinking in black and white terms, there will be a range > of organisational responses, with only a small proportion taking the high > ground. I suspect that will pay off nicely for them. > > And yes, there will be many in the ad tech space that try to utilise > ‘legitimate interest’ as an excuse to carry on business as usual. But there > are also at least a couple already that regard their platform as illegal > come 25th May 18, and taking steps accordingly. Interesting times ahead in > adtech. > > As a community, my suggestion is that we get behind the concept of the > personal data receipt, aka consent receipt. I think if that story is told > well, the individual can inherently get that idea - ‘i give you my data, > you give me a receipt’. They don’t have to buy into that they can then use > that receipt, merely having one would get the ball rolling. > > Thoughts on personal data receipts as something to get behind? > > Cheers > > Iain > > > > > On 2 Apr 2017, at 19:37, Marcin Betkier <Marcin.Betkier(a)vuw.ac.nz> wrote: > > Dear All, > > Just a couple of comments from (yet another) technology lawyer. > > The question about the relation between VRM and GDPR is an excellent one. > I just wanted to draw your attention to Article 29 Working Party’s > opinions: about data portability (end of last year, linked below by Manon), > and about “legitimate interest” grounds (April (?) 2014). They both shed > some light on the possible scope and limitations of data portability right. > > As per the relation in question, I think that VRM (as I understand it) is > simply more advanced concept than GDPR. GDPR is limited by thinking based > on OECD principles and, even deeper into the past, on FIPs from 1973. So, > instead of individual/customer right to independence (informational > self-determination, or autonomy, if you prefer) you have a number of > procedural provisions which, taken together, may not really do the job. As > a result, we need to look for VRM ideas in institutions like revocable > consent, right to object, data portability, or maybe privacy by design & > default. > > > Best regards, > > Marcin > > *From:* Iain Henderson [mailto:iainhenderson@mac.com > <iainhenderson(a)mac.com>] > *Sent:* Monday, 3 April 2017 8:27 a.m. > *To:* Tim Walters <walterswdf2(a)gmail.com> > *Cc:* Manon Molins <mmolins(a)fing.org>; ProjectVRM list < > projectvrm(a)eon.law.harvard.edu> > *Subject:* Re: [projectvrm] GDPR and individuals as first parties > > Hi Doc, I think what we discussed before was having the individual point > to GDPR as at least one of the terms they propose. In addition we'd need to > create a formal Guidance doc that sets out the Customer Commons > interpretation of each of the key areas. So, as mentioned below, 'industry' > will wish to use their own interpretations; for example marketers (e.g. > through IAB 'guidance') might (i.e. are already) argue that digital > advertising is permitted as a legitimate interest of the recipient. That's > pretty dubious in most cases, but that's what's being argued, and without a > strong counter point could win. The Customer Commons Guidance would be much > more overtly on the side of the customer. So what the individual would be > pointing to in their terms offer would be 'GDPR, subject to Customer > Commons interpretation. > > Lots of detail to build in there, but I think the approach is solid. > > Iain > > > On 2 Apr 2017, at 16:06, Tim Walters <walterswdf2(a)gmail.com> wrote: > > Manon - > > Thanks for the information. I'm very interested in attending Mydata and > will seriously consider submitting a proposal. > > Concerning data portability: Zbynek is right that this is the most direct > connection to VRM in the GDPR. However, it is important to be aware of the > conditions or restrictions. Article 20 states: > > "The data subject shall have the right to receive the personal data > concerning him or her, which he or she has provided to a controller, in a > structured, commonly used and machine-readable format and have the right to > transmit those data to another controller without hindrance from the > controller to which the personal data have been provided, where [and I > stress, *only* where]: > > (a) the processing is based on consent pursuant to point (a) of Article > 6(1) or point (a) of Article 9(2) or on a contract pursuant to point (b) of > Article 6(1); and > (b) the processing is carried out by automated means." > > The provisions listed in (a) refer to consent provided by the data subject > (Article 6(1) and Article 9(2)) or data required for the performance of a > contract (Article 6(1)(b).) > > Consent and performance of a contract are two of the six legal grounds for > data collection and processing. Of the remaining four, the most > interesting/troubling is "legitimate interest." I won't go into the many > details here -- in fact this could be the subject of a presentation at > Mydata -- but suffice to say that businesses have multiple incentives to > use the legitimate interest ground (thus excluding data from the > portability requirements) and for the purview of that ground to be a broad > as possible (thus legitimizing wide(r) spread data collection). > > I recently witnessed industry representatives and EU data protection > authorities (DPAs) playing handball with legitimate interest in a joint > meeting. I was pleased to see that the DPAs resisted all efforts to make > legitimate interests a "get out of jail free card" for intrusive marketing. > But continued vigilance will certainly be necessary. > Cheers, > tw > > > > On Sun, Apr 2, 2017 at 11:58 AM, Manon Molins <mmolins(a)fing.org> wrote: > > Hello, > > +1 Zbynek, the data portability right is indeed the VRM core of the GDPR. > > "The data subject shall have the right to receive the personal data > concerning him or her, which he or she has provided to a controller, in a > structured, commonly used and machine-readable format and have the right to > transmit those data to another controller without hindrance from the > controller to which the data have been provided" > > Maybe you have already seen the G29’s Guidelines on the right to data > portability > <http://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp2…> > . > > - The Midata project in United Kingdom + the MesInfos project (Fing) > <http://mydata2016.org/2016/07/27/if-i-can-use-your-data-you-can-too-however…> in > France are listed examples of those guidelines on how this portability > right can foster innovation in Europe. > - Individuals will be able to transmit their data from a controller to > another (this other controller can be another competing organisation or a > third-party service, a Pims - as Zbynek said : « VRM tools (private clouds, > personal assistants, etc.) » > - Data concerned by this right is the one provided by the individual - > see p7 - and this term cover so much more than just address, name, etc. > It’s the data resulting in the relationship between the individual and the > data controller/organisation. Ex: consumption data from smart meters, from > loyalty programs, from IoT, browsing history, geolocation, list of calls > (telco), bank data, etc. > > > Companies will need to be GDPR compliant by may 2018, they are positioning > themselves as we speak to see how (creating API, download functionalities, > etc.). > > You may know this too, but just a reminder: the main European event on the > subject (on VRM, My Data, Self Data, Pims economy, etc. - so many names to > speak of individual empowerment through data!) is called Mydata2017 - > Advancing Human Centric Personal Data <http://mydata2017.org/> (end of > August/beginning of September in Helsinki and Tallinn). > > - It will have a specific track on GDPR > <http://mydata2017.org/programme/tracks/#gdpr>. At Mydata2016 (in > which Doc spoke) we had a presentation of the GDPR by Edouard Geffray the > General Secretary of the National Commission for Information Technology and > Civil Liberties (CNIL). Now that it is « out » we will be able to go even > deeper. > - It’s a collaborative event, in which anyone can contribute to the > program, and we need your input for our 12 tracks :) > - We can contribute through the call for proposals > <http://mydata2017.org/programme/call-for-proposals/>(if you think of > a speaker, a session, a use case, …), it is open till mid-april! > - If you want to come, the registration opens up mid-april: > http://mydata2017.org/registration/ > <http://mydata2017.org/registration/> > > > > Best to all, > > Manon on behalf of the MesInfos project team > ———————————————————————————————— > *FING - association pour la Fondation Internet Nouvelle Génération * > Manon Molins - mmolins(a)fing.org <dkaplan(a)fing.org> - 06 85 86 47 05 > http://www.fing.org / http://www.internetactu.net > *Soutenez les actions et travaux de la Fing, *adhérez ! > <http://fing.org/?-Adhesion-> > > > Le 2 avr. 2017 à 10:34, zbynek(a)loebl.info a écrit : > > Dear Doc and others, > > I rarely contribute to your discussion. I am a technology lawyer from > Czechia and in this capacity I deal with GDPR in detail. I agree with Tim > that GDPR has a VRM core. In addition to what Tim mentions in his email I > would add data portability (Art. 20). This Article contains a totally new > right of data subjects to request transfer of their data provided to the > data controller based on consent or contract in a standard format. > > Data subjects can transfer their data to a new data controller or control > them themselves using - VRM tools (private clouds, personal assistants > etc.). This is a direct link to what you are preparing - via such VRM tools > data subjects can negotiate contract terms with service providers, they can > provide them with necessary authenticity checks regarding data subjects or > their childern etc. > > Best personal wishes, > > Zbynek > > Dne 2017-04-01 23:47, Tim Walters napsal: > > I'm not sure if this is useful, but: > Article 5 spells out the fundamental principles of personal data > collection/processing. these are (more detail upon request): > * lawfulness, fairness, and transparency > * purpose limitation [i.e., the controller must state precisely what > the collected data will be used for, and use it only for the purpose] > * data minimization [i.e., use only what is necessary for the stated > purpose] > * accuracy [i.e., controller has an obligation to ensure that data is > accurate and up to date] > * storage limitation [i.e., kept no longer than necessary for the > stated purpose] > * integrity and confidentiality [i.e., data is secure] > This if followed by a "behavioral" requirement for "accountability" -- > i.e., not only must you follow all of these principles, you must be > able to demonstrate and document that you do so. > However -- I think these stated principles are based in and in certain > ways trumped by a more fundamental conviction: namely, that personal > data always only belongs to the person it identifies. > Recital 7 states: "Natural persons should have control of their own > personal data." And it ties this directly to "the importance of > creating trust that will allow the digital economy to develop across > the internal [EU] market." > I recently attended an event in which Telefonica presented their > "Aura" personal data management platform. It clearly does not adhere > to each of the six core principles, but it does express the notion > that people should control their own data. I asked two EU data > protection authorities what they thought of it. Naturally, they would > not give a definitive judgement. But they did both say that they like > the innovative approach to putting people in charge of their data, > even if it did not accord with every one of the principles. > Cheers, > tw > On Sat, Apr 1, 2017 at 8:27 PM, Adrian Gropper > <agropper(a)healthurl.com> wrote: > > Is'nt it important to be able to signal that the entity seeking > consent must register with and contact a standard authorization > server? > This particular term ought to be a profile of UMA labeled and > documented for GDPR. > Adrian > On Sat, Apr 1, 2017 at 10:26 AM Mike O'Neill > <michael.oneill(a)baycloud.com> wrote: > > Hi Doc, > The GDPR does not have much in terms of signalling from the user > (aka the Data Subject), other than the ability to give or revoke > consent, and the right to object. > Article 4.11 defines consent, Article 6.1(a) says it is one of the > legal bases for processing, Recital 32 further describes it, plus > other Recitals refer to it. > Article 21 deals with the right to object, especially A21.5 which > says it can be expressed by "automated means". This applies when > another basis for processing (other than consent) is claimed. > In terms of information required to be given by companies i.e. > website (the Data Controller), this is spread throughout but > Article 13 covers most of it. > The other place which deals with user signalling, i.e. consent, > ability to revoke at any time etc. is the proposed ePrivacy > Regulation which is supposed to come into force at the same time > as the GDPR, though it is still being debated. Here is a link to > the proposal: > > https://ec.europa.eu/digital-single-market/en/news/ > proposal-regulation-privacy-and-electronic-communications > > [1] > Mike > > -----Original Message----- > From: Doc Searls [mailto:doc@searls.com] > Sent: 01 April 2017 14:34 > To: ProjectVRM list <projectvrm(a)eon.law.harvard.edu> > Subject: [projectvrm] GDPR and individuals as first parties > Customer Commons and its partners are working on terms > > individuals proffer as > > first parties in dealings with sites and services acting as > > second parties can > > satisfy both the letter and the spirit of the GDPR—or at least > > some of its > > requirements. > Since there are people on this list who know the GDPR better > > than I, it would be > > good if we could get pointed to the parts of the GDPR that > > justify this claim. I > > believe somebody here (Iain?) has done this before, but I > > can’t find anything > > right now, so help would be welcome. > Thanks! > Documents: > The GDPR in English HTML— > <http://eur-lex.europa.eu/legal- [2] > content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN <http://eur- > lex.europa.eu/legal- [3] > content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN>> > The Wikipedia page on the GDPR— > > <https://en.wikipedia.org/wiki/General_Data_Protection_Regulation > [4]> > > Doc > > -- > 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/ [5] > > Links: > ------ > [1] > https://ec.europa.eu/digital-single-market/en/news/ > proposal-regulation-privacy-and-electronic-communications > [2] http://eur-lex.europa.eu/legal- > [3] http://lex.europa.eu/legal- > [4] https://en.wikipedia.org/wiki/General_Data_Protection_Regulation > [5] 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/

2 1

Re: [WG-UMA] [projectvrm] GDPR and individuals as first parties
by Adrian Gropper 01 Apr '17

01 Apr '17

Is'nt it important to be able to signal that the entity seeking consent must register with and contact a standard authorization server? This particular term ought to be a profile of UMA labeled and documented for GDPR. Adrian On Sat, Apr 1, 2017 at 10:26 AM Mike O'Neill <michael.oneill(a)baycloud.com> wrote: > Hi Doc, > > The GDPR does not have much in terms of signalling from the user (aka the > Data Subject), other than the ability to give or revoke consent, and the > right to object. > > Article 4.11 defines consent, Article 6.1(a) says it is one of the legal > bases for processing, Recital 32 further describes it, plus other Recitals > refer to it. > > Article 21 deals with the right to object, especially A21.5 which says it > can be expressed by "automated means". This applies when another basis for > processing (other than consent) is claimed. > > In terms of information required to be given by companies i.e. website > (the Data Controller), this is spread throughout but Article 13 covers most > of it. > > > The other place which deals with user signalling, i.e. consent, ability to > revoke at any time etc. is the proposed ePrivacy Regulation which is > supposed to come into force at the same time as the GDPR, though it is > still being debated. Here is a link to the proposal: > > > https://ec.europa.eu/digital-single-market/en/news/proposal-regulation-priv… > > Mike > > > > > -----Original Message----- > > From: Doc Searls [mailto:doc@searls.com] > > Sent: 01 April 2017 14:34 > > To: ProjectVRM list <projectvrm(a)eon.law.harvard.edu> > > Subject: [projectvrm] GDPR and individuals as first parties > > > > Customer Commons and its partners are working on terms individuals > proffer as > > first parties in dealings with sites and services acting as second > parties can > > satisfy both the letter and the spirit of the GDPR—or at least some of > its > > requirements. > > > > Since there are people on this list who know the GDPR better than I, it > would be > > good if we could get pointed to the parts of the GDPR that justify this > claim. I > > believe somebody here (Iain?) has done this before, but I can’t find > anything > > right now, so help would be welcome. > > > > Thanks! > > > > Documents: > > > > The GDPR in English HTML— > > <http://eur-lex.europa.eu/legal- > > content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN <http://eur- > > lex.europa.eu/legal- > > content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN>> > > > > The Wikipedia page on the GDPR— > > <https://en.wikipedia.org/wiki/General_Data_Protection_Regulation> > > > > Doc > > > > > > > > > > > -- 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