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

Adam Dawes adawes at google.com
Tue Dec 6 09:08:06 UTC 2016


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


More information about the Openid-specs-risc mailing list