[Openid-specs-risc] [RISC] Agenda for call (9:30am PDT)

Phil Hunt phil.hunt at oracle.com
Mon Apr 3 17:45:11 UTC 2017


Regarding distribution, I think the key point missed in the minutes was that no individual draft can solve all problems and make everyone happy - there are 3 areas of diverging opinion AFAIK (see my email earlier today).

Phil

Oracle Corporation, Identity Cloud Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>











> On Apr 3, 2017, at 10:30 AM, Adam Dawes <adawes at google.com> wrote:
> 
> April 3
> Adam Dawes, George Fletcher, Dick Hardt, Phil Hunt, Henrik Biering
> 
> Recap of IETF 98. 
> SET spec had some good comments and feedback at the meeting. Mike Jones has action items to move those issues forward. 
> Distribution spec is far from consensus. 
> Phil is still advocating that SCIM manage the control plane as SCIM already defines a control plane and would also be one of the profiling specs for SecEvents. Doing anything else would be redundant. Back channel logout has already defined a mechanism and RISC’s requirements are different. 
> Dick has pointed out that the Distribution draft has not been adopted by the workgroup so there is still a lot of room to be able to propose different options. Phil has welcomed others taking a stab at this.
> RISC and Sec Events
> Since RISC is dependent on Sec Events, there is a desire to accelerate the work of that WG. 
> AI: Adam to propose on the Sec Events list to start with regular calls and F2F meetings.
> Do we need two days for the next RISC F2F if all the control plane discussion is happening with Sec Events? We’ll see what the path forward is on distribution draft and whether it ends up in RISC or Sec Events to figure out whether this makes sense.
> 
> Semantics of RISC messages
> Future RISC meetings, we’ll focus more on the sematics of the RISC signals. 
> AI: Marius to publish to the list or bitbucket the set of RISC events that Google supports now.
> Legal update
> Adam talked to lawyers and they are going to take a look at not having to specifically enumerate signals that need to be sent and make that a matter of internal process based on how data is to be handled. They will circle back on that issue. There was interest in participating in a lawyerfest to hammer out a more general agreement in May timeframe.
> AI: Dick to circle with Amazon legal and work to pull together lawyerfest.
> 
> On Mon, Apr 3, 2017 at 8:07 AM, Phil Hunt <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>> wrote:
> I’m not going to say much on the call. I will say that as co-author of the individual contribution for the distribution spec that we are at an impasse.
> 
> The problem is summed up as follows:
> 
> 1. There are many profiling standards groups all intending to share the spec. 
> 
> - SCIM which originated SECEVENTs does not need a control-pane because it is the control pane. Therefore, endpoint discovery is already solved and they will not want a new protocol.
> - RISC - while many members overlap SCIM members, others do not. They object to SCIM because it is a new protocol. I do not understand, but they seem to think a new protocol is simpler. RISC however seems to have the most complex data requirements in order to handle consent management.
> 
> - OpenID Connect had already decided they were doing their own protocol to align with connect (this is being debated)
> 
> Currently I do not see a possible consensus for common management of distribution endpoints.
> 
> 2.  Enterprise vs. Consumer - Strong push back on supporting multi-tenancy and RBAC style administration. Concepts like monitoring by shared security centers vs. individual event transmissions per enterprise customer.  In short, orgs with enterprise customers have complex legal and administrative issues that must be accounted for.
> 
> There is no consensus on administration.
> 
> 3.  IETF and Old vs New - During the chartering, members of the IESG raised strong objection to new management protocols. The IETF has too many now. In particular there was upset about NETCONF not being used.  Yaron has continued to raise this issue.  Others I respect also raised concern at yet another pub-sub protocol and are perplexed at this WG’s efforts.  We must address this.  One way is to profile existing specifications rather than invent.
> 
> This suggests a long uphill climb to publication.
> 
> Conclusion:
> 
> I’ve tried to warn the community but these impasses remain. Unless the group aligns strongly in it consensus on a solution, it is likely the work will end or not move forwards.
> 
> I do not believe that endless re-writes of the drafts will fix the underlying problems. We are shifting deck-chairs and bike shedding. Pick an analogy.
> 
> I admit, I’ve pushed too hard on this and the issues have now been attributed to me.  As a result, I plan to take myself out of the equation and let the group simply resolve the problem on its own.
> 
> Best Regards,
>  
> Phil
> 
> Oracle Corporation, Identity Cloud Architect & Standards
> @independentid
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=c2q9rDV8g3VqfGfMzDggNEfKyICKJDN36ZHZOY5oXhU&s=T98iYToBIFH5yOu6L0WNr6RsM5ATrNraFLN8cXFSetE&e=>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Apr 2, 2017, at 10:55 PM, Adam Dawes <adawes at google.com <mailto:adawes at google.com>> wrote:
>> 
>> Hi all,
>> 
>> For tomorrow's call, I thought we would try to do a recap of IETF 98. 
>> SET spec
>> Distribution spec
>> I also wanted to discuss meeting logistics going forward. As a lot of our discussion has been focused on the mechanics of the SET and distribution, those are actually largely in the charter for the Sec Events WG and where most discussion should be. So, if Dick can make the call, I wanted to propose splitting our current call time into half Sec Events and half RISC.  Also, given this dynamic, I wanted to potentially re-frame our upcoming F2F as at least part Sec Events.
>> 
>> thanks,
>> AD
>> 
>> Please join my meeting from your computer, tablet or smartphone.
>> 
>> https://global.gotomeeting.com/join/576653581 <https://urldefense.proofpoint.com/v2/url?u=https-3A__global.gotomeeting.com_join_576653581&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Zi6LyD7j7xNl_RBd8oAEGF1sjnstS0aWPPkGKd31sAA&s=un9pCeqkkW_OrFrynup5giSTu4omgp3X0qhIO0tXWd8&e=>
>> You can also dial in using your phone.
>> 
>> United States +1 (786) 358-5410 <tel:(786)%20358-5410>
>> 
>> Access Code: 576-653-581 
>> 
>> More phone numbers
>> 
>> Australia (Long distance): +61 2 9087 3604 <tel:+61%202%209087%203604>
>> 
>> Austria (Long distance): +43 7 2088 1400
>> 
>> Belgium (Long distance): +32 (0) 92 98 0592
>> 
>> Canada (Long distance): +1 (647) 497-9350 <tel:(647)%20497-9350>
>> 
>> Denmark (Long distance): +45 69 91 88 62 <tel:+45%2069%2091%2088%2062>
>> 
>> Finland (Long distance): +358 (0) 942 41 5778
>> 
>> France (Long distance): +33 (0) 182 880 456
>> 
>> Germany (Long distance): +49 (0) 692 5736 7211 <tel:+49%2069%20257367211>
>> 
>> Ireland (Long distance): +353 (0) 14 845 976
>> 
>> Italy (Long distance): +39 0 247 92 12 39
>> 
>> Netherlands (Long distance): +31 (0) 208 080 379
>> 
>> New Zealand (Long distance): +64 4 974 7215 <tel:+64%204-974%207215>
>> 
>> Norway (Long distance): +47 21 03 58 96 <tel:+47%2021%2003%2058%2096>
>> 
>> Spain (Long distance): +34 911 82 9782 <tel:+34%20911%2082%2097%2082>
>> 
>> Sweden (Long distance): +46 (0) 313 613 558
>> 
>> Switzerland (Long distance): +41 (0) 225 3314 51
>> 
>> United Kingdom (Long distance): +44 (0) 20 3535 0621 <tel:+44%2020%203535%200621>
>> 
>> -- 
>> Adam Dawes | Sr. Product Manager | adawes at google.com <mailto:adawes at google.com> | +1 650-214-2410 <tel:(650)%20214-2410>
>> _______________________________________________
>> Openid-specs-risc mailing list
>> Openid-specs-risc at lists.openid.net <mailto:Openid-specs-risc at lists.openid.net>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Zi6LyD7j7xNl_RBd8oAEGF1sjnstS0aWPPkGKd31sAA&s=TYrrr7cg9BG_oeYXym9v7JCKBKaGzzGWzMxVevMv0DM&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Zi6LyD7j7xNl_RBd8oAEGF1sjnstS0aWPPkGKd31sAA&s=TYrrr7cg9BG_oeYXym9v7JCKBKaGzzGWzMxVevMv0DM&e=> 
> 
> 
> 
> 
> -- 
> Adam Dawes | Sr. Product Manager | adawes at google.com <mailto: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/20170403/c18bb0d6/attachment-0001.html>


More information about the Openid-specs-risc mailing list