[Openid-specs-risc] RISC Agenda for today

Adam Dawes adawes at google.com
Sat May 2 06:55:19 UTC 2015


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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20150501/d78b2c04/attachment.html>


More information about the Openid-specs-risc mailing list