<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Here is my tentative elaboration on our
options regarding the EU Dataprotection Regulation.<br>
<br>
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.<br>
<br>
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.<br>
<br>
When comparing this to our charter, draft press release, and group
discussions, I think the most obvious argument for the processing
is:<br>
* Art. 6(c) processing is necessary for compliance with a legal
obligation to which the controller is subject;<br>
<br>
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.<br>
<br>
As I see it, the legal obligations relevant to our use cases are
primarily based on:<br>
<br>
* Art. 22(1,3): Obligations of the controller<br>
* Art. 23(1): Data Protection by design and by default<br>
* Art. 30: Security of processing<br>
(= extension of the current 1995 DP Directive Article 17)<br>
... as regards the prevention of fraudulous access to accounts<br>
<br>
* Art. 5(d): Principles relating to personal data processing<br>
(= the current 1995 DP Directive Article 6(d))<br>
... 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<br>
<br>
The new regulation also adds other articles that may be relevant
for our work, such as<br>
<br>
* Art. 24: Joint Controllers<br>
... covering the cooperation of two or more collaborating data
controllers<br>
<br>
* Art. 33: Data Protection Impact Assessment<br>
... 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".<br>
<br>
* Art. 38: Codes of conduct<br>
... 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.<br>
<br>
For anyone interested, a link to the latest Draft Data Protection
Regulation is here:<br>
<a
href="http://data.consilium.europa.eu/doc/document/ST-15395-2014-INIT/en/pdf">http://data.consilium.europa.eu/doc/document/ST-15395-2014-INIT/en/pdf</a><br>
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):<br>
<a
href="http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32002L0058&from=EN">http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32002L0058&from=EN</a><br>
<br>
/Henrik<br>
<br>
<br>
Den 02-05-2015 kl. 17:40 skrev Nat Sakimura:<br>
</div>
<blockquote
cite="mid:CABzCy2DUWJSvQXf+Hzf8UL18gV2swZwgv=+bUQs17MVks8sKHg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>From the privacy regulation point of view, each region has
its limits. <br>
</div>
<div>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. </div>
<div><br>
<div>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: </div>
<div>
<ul>
<li>The processing is necessary:<br>
</li>
<ul>
<li>in relation to a contract which the individual has
entered into; or</li>
<li>because the individual has asked for something to be
done so they can enter into a contract.</li>
</ul>
<li>The processing is in accordance with the “legitimate
interests” condition.</li>
</ul>
<u><b>The Processing is necessary</b></u> -- 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 <b><u>deemed trustworthy</u></b>,
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. <br>
<br>
<u><b>Legitimate interest</b></u> -- 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. <br>
</div>
<br>
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. <br>
<br>
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. <br>
</div>
<div><br>
</div>
<div>Cheers, </div>
<div><br>
</div>
<div>Nat @ Kuching, Malaysia</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-05-02 15:55 GMT+09:00 Adam Dawes <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:adawes@google.com" target="_blank">adawes@google.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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. </div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 1, 2015 at 5:13
PM, Nat Sakimura <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>+1 </div>
<div><br>
</div>
<div>Just a few points. <br>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
</div>
<div><br>
</div>
<div>Nat </div>
<div>
<br>
—<br>
<a moz-do-not-send="true"
href="https://www.dropbox.com/mailbox"
target="_blank">Mailbox</a> から送信</div>
<br>
<br>
<div class="gmail_quote">
<div>
<div>
<p>On Sat, May 2, 2015 at 8:36 AM, Brad Hill
<span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:hillbrad@gmail.com"
target="_blank">hillbrad@gmail.com</a>></span>
wrote:<br>
</p>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div>
<div>
<div dir="ltr">Regarding today's
discussion on establishing trust
relationships and bootstrapping for
already established accounts. I would
argue for a two-tiered approach.<br>
<br>
<div>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@Y",
you'd believe them, and have
contractual recourse if they were
lying.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>-Brad</div>
</div>
<br>
<div class="gmail_quote">On Fri, May 1,
2015 at 7:14 AM 'Adam Dawes' via Abuse
and ATO Coordination <<a
moz-do-not-send="true"
href="mailto:aatoc@googlegroups.com"
target="_blank">aatoc@googlegroups.com</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr"><span>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="color:rgb(0,0,0);font-family:Arial;font-size:15px;font-weight:bold;white-space:pre-wrap;line-height:1.38;background-color:transparent">Agenda</span><br>
</p>
<ul
style="margin-top:0pt;margin-bottom:0pt">
<li
style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent">
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">IPR
update</span></p>
</li>
<li
style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent">
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">OASIS
group STIX/TAXII next
steps</span></p>
</li>
<li
style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent">
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent"><a
moz-do-not-send="true"
href="https://docs.google.com/document/d/16QrQo5O1Afj4sZBZhJDHr9HxTtWERGHdle-0a4B6UT8/edit"
style="text-decoration:none" target="_blank">PR release</a></span></p>
</li>
<li
style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent">
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt">Weekly
call times</p>
</li>
<li
style="list-style-type:disc;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent">
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Technical
Discussion</span></p>
</li>
<ul
style="margin-top:0pt;margin-bottom:0pt">
<li
style="list-style-type:circle;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;background-color:transparent"><span
style="vertical-align:baseline;white-space:pre-wrap;background-color:transparent">How
do we operationalize
trust relationships.
Going forward, looking
backward</span></li>
</ul>
</ul>
<div><font color="#000000"
face="Arial"><span
style="font-size:15px;white-space:pre-wrap"><br>
</span></font></div>
<div>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Where:
</span><a
moz-do-not-send="true"
href="https://global.gotomeeting.com/join/764054389"
style="text-decoration:none" target="_blank"><span
style="font-size:15px;font-family:Arial;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">https://global.gotomeeting.com/join/764054389</span></a></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Use
your microphone and
speakers (VoIP) – a
headset is recommended.
Or, call in using your
telephone.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">US
phone number: <a
moz-do-not-send="true"
href="tel:%2B1%20%28312%29%20878-3080"
value="+13128783080"
target="_blank">+1 (312)
878-3080</a>. </span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">International
Numbers:</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:36pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Australia:
<a moz-do-not-send="true"
href="tel:%2B61%202%208355%201034" value="+61283551034" target="_blank">+61
2 8355 1034</a></span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:36pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Canada:
<a moz-do-not-send="true"
href="tel:%2B1%20%28647%29%20497-9376" value="+16474979376"
target="_blank">+1 (647)
497-9376</a></span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:36pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">France:
+33 (0) 170 950 586</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:36pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Germany:
<a moz-do-not-send="true"
href="tel:%2B49%20%280%29%20811%208899%206931" value="+4981188996931"
target="_blank">+49 (0)
811 8899 6931</a></span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:36pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Spain:
<a moz-do-not-send="true"
href="tel:%2B34%20932%2020%200506" value="+34932200506" target="_blank">+34
932 20 0506</a></span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-left:36pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">United
Kingdom: <a
moz-do-not-send="true"
href="tel:%2B44%20%280%29%20330%20221%200098"
value="+443302210098"
target="_blank">+44 (0)
330 221 0098</a></span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Access
Code: 736-042-757</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Audio
PIN: Shown after joining
the meeting</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Meeting
ID: 764-054-389</span></p>
</div>
</span></div>
-- <br>
You received this message because
you are subscribed to the Google
Groups "Abuse and ATO Coordination"
group.<br>
To unsubscribe from this group and
stop receiving emails from it, send
an email to <a
moz-do-not-send="true"
href="mailto:aatoc+unsubscribe@googlegroups.com"
target="_blank">aatoc+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to
<a moz-do-not-send="true"
href="mailto:aatoc@googlegroups.com"
target="_blank">aatoc@googlegroups.com</a>.<br>
To view this discussion on the web
visit <a moz-do-not-send="true"
href="https://groups.google.com/d/msgid/aatoc/CAOJhRMa9_G4gET-V0hNm7O%3Ddyq-4cwka_0fKwZKZqijwy91vMg%40mail.gmail.com?utm_medium=email&utm_source=footer"
target="_blank">https://groups.google.com/d/msgid/aatoc/CAOJhRMa9_G4gET-V0hNm7O%3Ddyq-4cwka_0fKwZKZqijwy91vMg%40mail.gmail.com</a>.<br>
For more options, visit <a
moz-do-not-send="true"
href="https://groups.google.com/d/optout"
target="_blank">https://groups.google.com/d/optout</a>.<br>
</blockquote>
</div>
-- <br>
You received this message because you
are subscribed to the Google Groups
"Abuse and ATO Coordination" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email
to <a moz-do-not-send="true"
href="mailto:aatoc+unsubscribe@googlegroups.com"
target="_blank">aatoc+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a
moz-do-not-send="true"
href="mailto:aatoc@googlegroups.com"
target="_blank">aatoc@googlegroups.com</a>.<br>
</div>
</div>
To view this discussion on the web visit <a
moz-do-not-send="true"
href="https://groups.google.com/d/msgid/aatoc/CAEeYn8geYEo5h%2By0Me19vZZ52vTKkp%2BJXOetq7%3DENv1vv-nawA%40mail.gmail.com?utm_medium=email&utm_source=footer"
target="_blank">https://groups.google.com/d/msgid/aatoc/CAEeYn8geYEo5h%2By0Me19vZZ52vTKkp%2BJXOetq7%3DENv1vv-nawA%40mail.gmail.com</a>.<span><br>
For more options, visit <a
moz-do-not-send="true"
href="https://groups.google.com/d/optout"
target="_blank">https://groups.google.com/d/optout</a>.<br>
</span></div>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a moz-do-not-send="true" href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-risc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-risc@lists.openid.net">Openid-specs-risc@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-risc">http://lists.openid.net/mailman/listinfo/openid-specs-risc</a>
</pre>
</blockquote>
<br>
</body>
</html>