[Openid-specs-ab] More thoughts on the Federation Spec Vote...
Michael.Jones at microsoft.com
Mon Jul 23 23:58:03 UTC 2018
Again, it's much like the IETF. The chairs are empowered to call consensus on working group decisions, with the goal of maximizing consensus among participants. Typically this happens by asking the "does anyone object" question at a meeting rather than holding a vote. The decision is also then published to the working group mailing list so others can comment. If you have to hold a vote, it's a sign than you probably don't have consensus in the first place.
From: Nick Roy <nroy at internet2.edu>
Sent: Monday, July 23, 2018 4:14 PM
To: Phil Hunt <phil.hunt at oracle.com>
Cc: Mike Jones <Michael.Jones at microsoft.com>; Mike Schwartz <mike at gluu.org>; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] More thoughts on the Federation Spec Vote...
Does consensus mean >50% of those present support an implementation draft with IPR protections, or something more than that?
> On Jul 23, 2018, at 5:05 PM, Phil Hunt via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> No. I am asking for the wg to have consensus before the implementor call is made which is a vote.
> That means calling for consensus.
>> On Jul 23, 2018, at 4:00 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>> We don't vote in OpenID working groups, just like we don't vote in IETF working groups, because the goal is to achieve rough consensus, rather than just a majority opinion.
>> Despite your doubts about the ability to change decisions in Implementer's Drafts, history shows that this happens in the OpenID Connect working group often. There were five rounds of interops leading to OpenID Connect and breaking changes were made as a result of all of them - some of them major design changes, like deleting the former introspection endpoint. Likewise, there were several sets of Implementation Drafts, with significant changes between them.
>> So if you want to propose specific changes for the working group to consider, have at it. If your proposals are backed by implementation experience, all the better. We try to have people implement early and often (and grant IPR rights enabling people to safely do so).
>> To Phil's point about working group feedback, yes, in general, we seek working group feedback before calling for Implementer's Drafts. In this specific case, the working group was aware that many developers were already voting with their feet and implementing for purpose of interop testing. For instance, the many existing and planned implementations were discussed on the November 27, 2017 working group call, per https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dab_Week-2Dof-2DMon-2D20171127_006690.html&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7ahBfdTvtXLmoKkfdL_w2Idlh_MQ_kPCd5K0s08UwzY&s=rAdCs8QhcB0uxKqV6tNh8NpW5Mjx6T33_wIwiR4RC-0&e=. We owed it to these implementers to protect their rights to implement.
>> As to whether the current design is the best one, we have obviously been having that discussion for the past year plus - including at two workshops of academic federation professionals devoted to this very topic. I believe that Roland and the other contributors have done a good job learning from large-scale SAML federations - keeping the good parts and simplifying the problematic parts. (Scott Cantor is on record, for instance of having said "If I were designing SAML metadata again, I'd do it this way.") But improvements are always possible with specific proposals describing them. We welcome that continued discussion.
>> Best wishes,
>> -- Mike
>> -----Original Message-----
>> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On
>> Behalf Of Mike Schwartz via Openid-specs-ab
>> Sent: Monday, July 23, 2018 2:14 PM
>> To: openid-specs-ab at lists.openid.net
>> Subject: [Openid-specs-ab] More thoughts on the Federation Spec Vote...
>>> The concerns I'm hearing, Mike Schwartz, sound more like you're
>>> worried that the spec isn't done and not ready to be final than that
>>> you're worried that people will learn from implementing early drafts.
>>> You're right that this spec isn't done. Heck the spec itself makes
>>> that clear in the Open Issues section at
>> My thinking evolved on this over the past few days... I figured out more clearly why this is bugging me.
>> What other designs for federation will be considered? Current federations use metadata aggregates. You may think you have a better design, but what if a federation would prefer to publish a metadata aggregate? Is that not also a "federation"? How about a federation proxy service? It seems to me like these basic design questions are not up for debate. Once we go to Implementers draft, we can raise issues on the use of Metadata Statements, but it will be called "OpenID Federation"--as if there are no other possible federation solutions--without this major design decision being voted on.
>> That's why I said I'd be ok with a more specific title for the spec. It would say: here's a specific way you could form trust among a group of organizations, without saying "here is the way we do federations in OpenID". That would leave the door open for more federation solutions (like logout after session management proved buggy).
>> I seriously doubt a major design change (like moving to an aggregate
>> proxy) will be considered after this draft goes to the next stage. So the only option we have is to vote "OBJECT" on the IP.
>> As Phil points out, it may be time for the OIDF to consider more seriously how consensus is achieved within WG's to avoid issues like this in the future, especially among members of the OIDF, and active community participants. People think the OIDF is a consensus based standards organization. Is it? Or we just have consensus on the IP?
>> - Mike
>> Michael Schwartz
>> Founder / CEO
>> mike at gluu.org
>> e= _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab