[Openid-specs-ab] More thoughts on the Federation Spec Vote...

[Mike Schwartz]

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

- Mike


------------------------
Michael Schwartz
Gluu
Founder / CEO
mike at gluu.org
https://www.linkedin.com/in/nynymike/

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.
> 
> Nick
> 
>> 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 
>>> https://openid.net/specs/openid-connect-federation-1_0-04.html#rfc.appendix.C!
>> 
>> 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
>> Gluu
>> Founder / CEO
>> mike at gluu.org
>> https://www.linkedin.com/in/nynymike/
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab