[Openid-specs-risc] RISC Agenda (Monday 9:30am PST)
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:
> I think you miss my point. Your rush is primarily due to the fact that you
> want to pilot sharing of live data correct?
> 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.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:
>> 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.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.
>> Adam Dawes, Marius Scurtescu, Dick Hardt, Phil Hunt, Adam Migus, John
>> Bradley, George Fletcher
>> - 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
>> - 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
>>> 1. Please join my meeting.
>>> 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
>> Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
>> Openid-specs-risc mailing list
>> Openid-specs-risc at lists.openid.net
> Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-risc