[Openid-specs-risc] RISC Agenda for today

Nat Sakimura sakimura at gmail.com
Sat May 2 15:40:01 UTC 2015

>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:
   - in relation to a contract which the individual has entered into; or
      - 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”

*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


Nat @ Kuching, Malaysia

2015-05-02 15:55 GMT+09:00 Adam Dawes <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> 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> 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> 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
>>>>    - 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.
>>>> International Numbers:
>>>> Australia: +61 2 8355 1034
>>>> Canada: +1 (647) 497-9376
>>>> France: +33 (0) 170 950 586
>>>> Germany: +49 (0) 811 8899 6931
>>>> Spain: +34 932 20 0506
>>>> United Kingdom: +44 (0) 330 221 0098
>>>> 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.
>>>> To post to this group, send email to 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.
>>> To post to this group, send email to 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20150503/fabec7c6/attachment.html>

More information about the Openid-specs-risc mailing list