[Openid-specs-ab] More thoughts on the Federation Spec Vote...
mike at gluu.org
Mon Jul 23 22:54:01 UTC 2018
Edugain has 4906 entities. I agree that one big signed file is a
terrible idea for that! But federations are not a one-size fits all
proposition. What about for a federation of 50 participants? Are
metadata statements still toast?
Also, proxies have been a very scalable trust model (as long as your
trust the federation operator). One could say that proxied federations
have proven to be quite scalable. SecureKey in Canada has been very
successful. 800-63-3 describes a few options for a proxied federations.
And in a way, proxied federations seem more like a typical cloud
solution, where most of the complexity is pushed to the center.
Nested-JWT's may work--the usability by participants is up for debate.
That's the real question. This is an extremely speculative design. You
have no idea if developers are going to be able to consume these
metadata statements. Also, how many IDP's will consume them from RP's?
That is also a question.
Nick, you think you know *FOR SURE* this will work? You want to go on
record stating your level of confidence that this is going to be the
federation mechanism of the future? Let's hear it...
Founder / CEO
mike at gluu.org
On 2018-07-23 16:38, Nick Roy wrote:
> Aggregates are toast. We’ve more than exhausted that path with the
> current scale of eduGAIN.
>> On Jul 23, 2018, at 3:13 PM, Mike Schwartz via Openid-specs-ab
>> <openid-specs-ab at lists.openid.net> wrote:
>>> 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
>> or 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
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab