[Openid-specs-risc] RISC Agenda for today

Henrik Biering hb at peercraft.com
Sun May 3 11:48:39 UTC 2015

Here is my tentative elaboration on our options regarding the EU 
Dataprotection Regulation.

Also IANAL, but I have agreement from at least one legal privacy expert 
for a meeting to get a professional opinion on the musings below. When I 
have this, I will post any relevant findings to the RISC list.

The drafts for the upcoming EU Data Protection Regulation increasingly 
consider the providers common responsibility to conceive and implement 
measures to raise the bar for security related incidents which may 
affect their users. Service providers may face accountability and severe 
financial sanctions if data breaches can be attributed to not using new 
technologies that are available at reasonable cost.

When comparing this to our charter, draft press release, and group 
discussions, I think the most obvious argument for the processing is:
* Art. 6(c) processing is necessary for compliance with a legal 
obligation to which the controller is subject;

Using the "legitimate interests that may overide the interests of the 
user" approach (6f) will probably cause much more worry (e.g. suspicion 
of profiling) with users and authorities. It also involves extended 
requirements for user notifications and complaint handling.

As I see it, the legal obligations relevant to our use cases are 
primarily based on:

* Art. 22(1,3): Obligations of the controller
* Art. 23(1): Data Protection by design and by default
* Art. 30: Security of processing
(= extension of the current 1995 DP Directive Article 17)
... as regards the prevention of fraudulous access to accounts

* Art. 5(d): Principles relating to personal data processing
(= the current 1995 DP Directive Article 6(d))
... as regards ensuring that data that are not up-to-date, valid or 
appropriate (such as email addresses, phone numbers, passwords) can be 
erased or updated/replaced

The new regulation also adds other articles that may be relevant for our 
work, such as

* Art. 24: Joint Controllers
... covering the cooperation of two or more collaborating data controllers

* Art. 33: Data Protection Impact Assessment
... which is more or less a formalized writeup and assessment of the 
arguments provided by Adam and others for taking the initiative to start 
this WG. It will be the starting point (w/wo RISC), if we should decide 
to submit our recommendations and specs as an "EU code of conduct".

* Art. 38: Codes of conduct
... on how EU data protection authorities shall encourage associations 
and other bodies representing categories of controllers or processors to 
prepare "codes of conduct" for measures and procedures to ensure (e.g.) 
security of processing. Such codes of conduct shall be submitted to a 
(national) supervisory authority for review. If the processing involves 
several EU Member States, the supervisory authority shall forward the 
proposal to the European Data Protection Board for approval and publication.

For anyone interested, a link to the latest Draft Data Protection 
Regulation is here:
The existing specific e-Privacy Directive will remain in force along 
with the new regulation, but basically they will be very well aligned as 
regards our purposes (security):


Den 02-05-2015 kl. 17:40 skrev Nat Sakimura:
> From the privacy regulation point of view, each region has its limits.
> I am not a lawyer and the following is not a legal advice but just a 
> general comment, but it may be a useful view. The privacy regulation 
> situation may be better than you think.
> In case of EU, we could justify the sharing of the data through the 
> conditions of processing of EU Directive and the forthcoming 
> regulation. There are handful of those conditions, but for our case, 
> we could tap specifically into these:
>   * The processing is necessary:
>       o in relation to a contract which the individual has entered

>         into; or
>       o because the individual has asked for something to be done so
>         they can enter into a contract.
>   * The processing is in accordance with the “legitimate interests”
>     condition.
> _*The Processing is necessary*_ -- It is probably reasonable to assume 
> that the user and the relying party has entered into a relation that 
> the user expects safeguarding of his account at the relying party. To 
> fulfill it, if the relying party regards it is important to share that 
> information with the email or identity provider, it may do so 
> accordingly. The provider side is a little more tricky but as long as 
> the provider has been notified by the relying party, and relying party 
> was *_deemed trustworthy_*, then it would probably be reasonable to 
> think that sharing the account status information with the said 
> relying party is reasonably expected as necessary for executing the 
> safeguarding expectation by the user.
> _*Legitimate interest*_ -- alternatively, we can flip and use 
> legitimate interest as long as we can determine that the benefit that 
> the services obtain is not unreasonable compared to the privacy impact 
> to the user. In this case, we could say that it is a legitimate 
> interest of the services and providers to safeguard the accounts and 
> the negative privacy impact caused by it is minimal because we only 
> share the "signal" etc.
> In the United States, since the legal restrictions are sector 
> specific, we may need to treat each sector accordingly. This can be a 
> bit more tricky, but it could be done. This administration's thinking, 
> as I read from the recent Privacy Bill of Rights proposal, the sharing 
> of the information for the security related purpose is exempt from 
> general restriction. So, we may want to leverage that.
> In Japan, we are a bit out of luck in this respect, but we may be able 
> to come up with something through the consultation to the data 
> protection authority.
> Cheers,
> Nat @ Kuching, Malaysia
> 2015-05-02 15:55 GMT+09:00 Adam Dawes <adawes at google.com 
> <mailto:adawes at google.com>>:
>     I think Brad and Nat's points are both spot on. I agree that this
>     is harder to justify on a go-forward OAuth basis. But with a mass
>     opt-in based on agreement (bi-lateral or trust framework), I'm far
>     less certain I can persuade my organization to go there.
>     I was interested in Anton's comments here. He said he thought that
>     this kind of arrangement would not fly in Germany. Anton, would
>     like to hear if you have more specific thoughts about this. Do you
>     think there is a way to make mass opt-in palatable?
>     I suspect the best I could hope for would be to have a big
>     announcement that Google was joining a trust framework with N
>     other companies to share account security data and the privacy
>     protections require x, y, and z. I'll need to start doing some
>     asking around but my gut tells me that still would be a pretty big
>     ask.
>     On Fri, May 1, 2015 at 5:13 PM, Nat Sakimura <sakimura at gmail.com
>     <mailto:sakimura at gmail.com>> wrote:
>         +1
>         Just a few points.
>         For the first tier, which I label as "mass enrollment", A
>         trust framework where a trust framework operator and other
>         participants get into contracts may work better from the
>         scalability point of view. Mutual legal agreement quickly get
>         us into N^2 agreement explosion whereas a trust framework only
>         has N+1.
>         Also, we should not use the term "opt-in" in this case since
>         we are enrolling the users by default.  we are enrolling the
>         users with opt-out.
>         Nat
>>         Mailbox <https://www.dropbox.com/mailbox> から送信
>         On Sat, May 2, 2015 at 8:36 AM, Brad Hill <hillbrad at gmail.com
>         <mailto:hillbrad at gmail.com>> wrote:
>             Regarding today's discussion on establishing trust
>             relationships and bootstrapping for already established
>             accounts.  I would argue for a two-tiered approach.
>             One tier would be companies that execute mutual legal
>             agreements and are able to opt-in users via their global
>             ToS. This would likely require with an opt-out mechanism
>             as deemed appropriate by each organization's legal counsel
>             and appropriate to the markets they operate in, but this
>             could be transparent to the other side of the
>             relationship.  So long as company X and Y have a mutual
>             agreement executed, all requests for account data would be
>             whitelisted.  If X said "I have an account for user at Y",
>             you'd believe them, and have contractual recourse if they
>             were lying.
>             The second tier would require more explicit opt-in, like
>             an OAuth flow, to connect the accounts, and because it
>             would have direct user approval would not need any
>             prearrangements between the entities holding the accounts
>             on the user's behalf.
>             I think trying to force all existing accounts to go
>             through an explicit consent flow is just too big of an
>             obstacle to ever getting operational at a meaningful
>             scale. Maybe some large organizations in some
>             jurisdictions would prefer or need to use the explicit
>             opt-in flows exclusively, but having a streamlined flow
>             where some large fraction of the top 10 or 100 global
>             account providers can establish mutual trust to bootstrap
>             the first 10e8 connections without an enormous amount of
>             explicit point-to-point bookkeeping and user friction
>             seems absolutely necessary for this to be meaningful in
>             protecting users on any reasonable time scale.
>             If there are tradeoffs to be made in terms of the scope or
>             fidelity of the sharing vs. the ability to automatically
>             provision, I would urge we go as far as we can towards
>             low-fidelity low-friction (while still providing a useful
>             signal) for the same reason.
>             -Brad
>             On Fri, May 1, 2015 at 7:14 AM 'Adam Dawes' via Abuse and
>             ATO Coordination <aatoc at googlegroups.com
>             <mailto:aatoc at googlegroups.com>> wrote:
>                 Agenda
>                  *
>                     IPR update
>                  *
>                     OASIS group STIX/TAXII next steps
>                  *
>                     PR release
>                     <https://docs.google.com/document/d/16QrQo5O1Afj4sZBZhJDHr9HxTtWERGHdle-0a4B6UT8/edit>
>                  *
>                     Weekly call times
>                  *
>                     Technical Discussion
>                       o How do we operationalize trust relationships.
>                         Going forward, looking backward
>                 Where: https://global.gotomeeting.com/join/764054389
>                 Use your microphone and speakers (VoIP) – a headset is
>                 recommended. Or, call in using your telephone.
>                 US phone number: +1 (312) 878-3080
>                 <tel:%2B1%20%28312%29%20878-3080>.
>                 International Numbers:
>                 Australia: +61 2 8355 1034 <tel:%2B61%202%208355%201034>
>                 Canada: +1 (647) 497-9376
>                 <tel:%2B1%20%28647%29%20497-9376>
>                 France: +33 (0) 170 950 586
>                 Germany: +49 (0) 811 8899 6931
>                 <tel:%2B49%20%280%29%20811%208899%206931>
>                 Spain: +34 932 20 0506 <tel:%2B34%20932%2020%200506>
>                 United Kingdom: +44 (0) 330 221 0098
>                 <tel:%2B44%20%280%29%20330%20221%200098>
>                 Access Code: 736-042-757
>                 Audio PIN: Shown after joining the meeting
>                 Meeting ID: 764-054-389
>                 -- 
>                 You received this message because you are subscribed
>                 to the Google Groups "Abuse and ATO Coordination" group.
>                 To unsubscribe from this group and stop receiving
>                 emails from it, send an email to
>                 aatoc+unsubscribe at googlegroups.com
>                 <mailto:aatoc+unsubscribe at googlegroups.com>.
>                 To post to this group, send email to
>                 aatoc at googlegroups.com <mailto:aatoc at googlegroups.com>.
>                 To view this discussion on the web visit
>                 https://groups.google.com/d/msgid/aatoc/CAOJhRMa9_G4gET-V0hNm7O%3Ddyq-4cwka_0fKwZKZqijwy91vMg%40mail.gmail.com
>                 <https://groups.google.com/d/msgid/aatoc/CAOJhRMa9_G4gET-V0hNm7O%3Ddyq-4cwka_0fKwZKZqijwy91vMg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>                 For more options, visit
>                 https://groups.google.com/d/optout.
>             -- 
>             You received this message because you are subscribed to
>             the Google Groups "Abuse and ATO Coordination" group.
>             To unsubscribe from this group and stop receiving emails
>             from it, send an email to
>             aatoc+unsubscribe at googlegroups.com
>             <mailto:aatoc+unsubscribe at googlegroups.com>.
>             To post to this group, send email to
>             aatoc at googlegroups.com <mailto:aatoc at googlegroups.com>.
>             To view this discussion on the web visit
>             https://groups.google.com/d/msgid/aatoc/CAEeYn8geYEo5h%2By0Me19vZZ52vTKkp%2BJXOetq7%3DENv1vv-nawA%40mail.gmail.com
>             <https://groups.google.com/d/msgid/aatoc/CAEeYn8geYEo5h%2By0Me19vZZ52vTKkp%2BJXOetq7%3DENv1vv-nawA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>             For more options, visit https://groups.google.com/d/optout.
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20150503/55fee831/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3687 bytes
Desc: S/MIME-signeret meddelelse
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20150503/55fee831/attachment-0001.p7s>

More information about the Openid-specs-risc mailing list