- WG-UMA - mailman.kantarainitiative.org

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 11 Apr '17

11 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