[Openid-specs-risc] RISC Agenda (Monday 9:30am PST)

Adam Dawes adawes at google.com
Tue Dec 6 18:51:14 UTC 2016


On Tue, Dec 6, 2016 at 9:28 AM, Phil Hunt <phil.hunt at oracle.com> wrote:

> Adam,
>
> I think you miss my point. Your rush is primarily due to the fact that you
> want to pilot sharing of live data correct?
>

Indeed.

>
> I agree that it is reasonable to set a deadline on the pilot agreement.
>
> We still have to have a general agreement that will be used more
> typically. From the standards process, this document sets the privacy,
> regulatory and legal requirements we must meet with RISC.
>
>
Let's set up time to talk more. I think it would be good for me to
understand your perspective on this.


> Phil
>
> @independentid
> www.independentid.com
> phil.hunt at oracle.com
>
>
>
>
>
> On Dec 6, 2016, at 1:08 AM, Adam Dawes <adawes at google.com> wrote:
>
>
>
> On Mon, Dec 5, 2016 at 11:19 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
>
>> Adam,
>>
>> My comments were more that the “standards” approach to legal operational
>> business information sharing agreement is a new thing and that this will
>> take some time for many organizations to get their heads around.
>>
>> For Oracle, no decisions have been made on any preferred method or
>> provided comments. The comments I shared were my “gut” reaction.
>>
>> RISC’s operational requirements is not a matter of technical protocol
>> standards it is an operational service. Because of this, most, if not all,
>> of us will at some point have to engage not only with legal, but also
>> privacy and potentially regulatory offices. I caution that it is reasonable
>> to expect that this will slow down the normal standards process.
>>
>
> With the RISC WG calls, we are blending the operational along with the
> spec. I agree that these are different domains but to the aim of forward
> progress I think it is most efficient to handle them together. So, my notes
> on each company's status wrt to the agreement were definitely intended to
> be around the operational aspect.
>
>
>>
>> With that said, I understand the need for pilot agreements. *That is
>> more specific and easily addressed. We should proceed with those as
>> temporary information sharing agreements.*
>>
>> *I have a strong objection to implying these “pilot” agreements are in
>> any way going to reflect the final agreements we would “standardize” on as
>> this may serve to “lock-out” future participants before any true consensus
>> has been achieved. *
>>
>
> I can't predict how this will evolve. My intention has been to make this
> as easy to scale as is reasonably possible but I don't have a strong
> feeling about actual standardization of the agreement. From my perspective,
> the ideal is to do all of this via OAuth where no agreement is necessary.
> The agreement is a bit of a primer for the system and a way for providers
> with large numbers of mutual users to get started sharing signals quickly.
>
> My must have goal is that Google gets to a consistent agreement that
> allows us to make this very low friction to make with other parties. Since
> we are trying to stimulate the ecosystem by sharing with a multiple
> parties, it makes sense for us to get to a consistent agreement quickly. We
> don't have legal resource to do otherwise.
>
> I'm expecting most players interested in RISC will want an agreement with
> us and therefore they will be willing to sign-on to this agreement after
> going through the process with a few players. If they are willing to sign
> with Google, then chances are they would be willing to sign the same
> agreement with others by simply changing the parties on the agreement. Of
> course companies can choose to negotiate bilaterally all over again if they
> choose but I would guess it is going to start from the same template. So,
> we begin to have something like a standardized contract (even if not
> codified as a standard).
>
> We're certainly happy with this outcome because I think it will help users
> if Microsoft and Amazon can easily start exchanging signals and we're happy
> to have funded the writing of this initial agreement to make that happen.
> But it's purely up to Microsoft and Amazon to use that or not. After some
> amount of time in this mode, I'd expect we either determine we are happy
> sharing with whom we're sharing or more substantive standardization through
> OIX or the like would be beneficial. I have interest in that but want to
> see specific pull from the players before we add that kind of complexity.
>
>>
>> From a OpenID Foundation perspective, these template agreements should
>> probably go through the same community consensus building process as the
>> technical documents.
>>
>> I think we're being pretty open about it now. But we don't want this to
> be open-ended forever and we're trying to drive prospective partners to
> contribute now.
>
>
>> With that said, I get the need to apply pressure on our various
>> organizations to move quickly.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.hunt at oracle.com
>>
>>
>>
>>
>>
>> On Dec 5, 2016, at 10:31 AM, Adam Dawes <adawes at google.com> wrote:
>>
>> Notes from Dec 5 meeting. Please update with any corrections or omissions.
>>
>> Attendees
>> Adam Dawes, Marius Scurtescu, Dick Hardt, Phil Hunt, Adam Migus, John
>> Bradley, George Fletcher
>>
>> Agenda
>>
>>    - Sharing agreement
>>    - Amazon thinks that they’ll be ready in mid January. Agreement
>>       generally looks okay but they are most concerned with the actual info that
>>       will be shared.
>>       - AoL gotten prelim ok from legal but need to get buy-in from CISO.
>>       - Confyrm want to participate, need to talk to Andrew for details
>>       - Oracle doesn’t quite know how to digest this from a legal
>>       process standpoint, coming up with a general template instead of an actual
>>       agreement. There may be more comfort to join an industry consortium,
>>       perhaps one hosted at OIX instead of a common bi-lateral agreement.
>>       - Ping doesn’t have a great use case and not likely to participate.
>>       - Conclusion: for Google data, Google will wait to get feedback
>>       from interested parties until the end of January. We’ll then work through
>>       once with the parties that have given feedback to get to the preferred
>>       agreement. Further asks for changes will be very difficult. [Dick] thinks
>>       that there won’t be that many direct agreements.
>>       - Another use case around account recovery, leveraging credit card
>>    details. RISC would be very helpful here. [Bruce Schneier article
>>    <https://www.schneier.com/blog/archives/2016/12/guessing_credit.html>]
>>    - IETF summary
>>    - Formal meeting not too eventful. Some feedback on the name. Follow
>>       up to incorporate Justin’s suggestion on payload.
>>       - Dick and Yaron Shefer are chairs for the Security Events WG.
>>       AI: Dick needs to nominate current draft
>>       <https://tools.ietf.org/html/draft-hunt-idevent-token-07> for the
>>       WG to adopt.
>>       - Transport
>>       - Subscription management. Sorting out control plane from
>>          transmission into possibly two documents. Phil sorting out different
>>          requirements from different use cases (RISC, SCIM, OIDC). The transport
>>          seems quite different with RISC so need to factor out what should go into
>>          general spec and what into the RISC profile.
>>          - Phil will split the transport into control plane and
>>          messaging. We’ll take some time to figure out control plane but let’s not
>>          slow down data sharing for it.
>>          - SETs
>>       - Google is working on events for: All sessions terminated, All
>>          tokens revoked, Account Locked and Account Restored. Google will propose
>>          some common definitions based on the properties of their system and we can
>>          work towards more general definitions based on other companies’ systems.
>>          - Google Pubsub and Event Pipeline
>>    - Will be ready to go with manually configured data plane whenever we
>>       can get another party to work with.
>>       AI: Adam to reach out to MSFT to get things coordinated. When the
>>       agreeement is baked, we’ll have more that we can work with.
>>       - For future discussion: Domain based relationships (Microsoft
>>    enterprise - Google enterprise)
>>
>>
>> On Sun, Dec 4, 2016 at 11:53 PM, Adam Dawes <adawes at google.com> wrote:
>>
>>> Hi all,
>>>
>>> Wanted to follow up from conversations at IETF around token spec and
>>> transport.
>>>
>>> 1.  Please join my meeting.
>>> https://global.gotomeeting.com/join/576653581
>>>
>>> 2.  Use your microphone and speakers (VoIP) - a headset is recommended.
>>> Or, call in using your telephone.
>>>
>>> United States: +1 (312) 757-3119 <(312)%20757-3119>
>>> Australia: +61 2 9091 7603 <+61%202%209091%207603>
>>> Austria: +43 (0) 7 2088 0716
>>> Belgium: +32 (0) 28 08 4372
>>> Canada: +1 (647) 497-9380 <(647)%20497-9380>
>>> Denmark: +45 (0) 69 91 84 58
>>> Finland: +358 (0) 931 58 1773
>>> France: +33 (0) 170 950 590
>>> Germany: +49 (0) 692 5736 7300 <+49%2069%20257367300>
>>> Ireland: +353 (0) 15 133 006
>>> Italy: +39 0 699 26 68 65
>>> Netherlands: +31 (0) 208 080 759
>>> New Zealand: +64 9 974 9579 <+64%209-974%209579>
>>> Norway: +47 21 04 30 59 <+47%2021%2004%2030%2059>
>>> Spain: +34 931 76 1534 <+34%20931%2076%2015%2034>
>>> Sweden: +46 (0) 852 500 691
>>> Switzerland: +41 (0) 435 0026 89
>>> United Kingdom: +44 (0) 20 3713 5011 <+44%2020%203713%205011>
>>>
>>> Access Code: 576-653-581
>>> Audio PIN: Shown after joining the meeting
>>>
>>> Meeting ID: 576-653-581
>>>
>>> --
>>> Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
>>> <(650)%20214-2410>
>>>
>>>
>>
>>
>> --
>> Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
>> <(650)%20214-2410>
>>
>> _______________________________________________
>> Openid-specs-risc mailing list
>> Openid-specs-risc at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>>
>>
>>
>
>
> --
> Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
> <(650)%20214-2410>
>
>
>


-- 
Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20161206/f9f4c8f3/attachment-0001.html>


More information about the Openid-specs-risc mailing list