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

Phil Hunt phil.hunt at oracle.com
Mon Dec 5 19:19:11 UTC 2016


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 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. 

From a OpenID Foundation perspective, these template agreements should probably go through the same community consensus building process as the technical documents.

With that said, I get the need to apply pressure on our various organizations to move quickly.


www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto: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 <mailto: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 <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 <tel:(312)%20757-3119>
> Australia: +61 2 9091 7603 <tel:+61%202%209091%207603>
> Austria: +43 (0) 7 2088 0716
> Belgium: +32 (0) 28 08 4372
> Canada: +1 (647) 497-9380 <tel:(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 <tel:+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 <tel:+64%209-974%209579>
> Norway: +47 21 04 30 59 <tel:+47%2021%2004%2030%2059>
> Spain: +34 931 76 1534 <tel:+34%20931%2076%2015%2034>
> Sweden: +46 (0) 852 500 691
> Switzerland: +41 (0) 435 0026 89
> United Kingdom: +44 (0) 20 3713 5011 <tel:+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 <mailto:adawes at google.com> | +1 650-214-2410 <tel:(650)%20214-2410>
> -- 
> Adam Dawes | Sr. Product Manager | adawes at google.com <mailto:adawes at google.com> | +1 650-214-2410
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net <mailto:Openid-specs-risc at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-risc <http://lists.openid.net/mailman/listinfo/openid-specs-risc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20161205/972d7c27/attachment-0001.html>

More information about the Openid-specs-risc mailing list