[Openid-specs-ab] OpenID Federation: more problems with this draft

[Mike Schwartz]

One more comment on the federation spec: I think it's less clear then 
the previous version.  The line is blurred between what are claims of a 
metadata statement, what claims OP's should publish as additional OP 
configuration, and what claims clients should post during dynamic 
registration. That was crystal clear to me in the previous version, and 
it is less so now.

(I'm saying "claims" here because if I say "metadata" one more time, it 
will destroy its meaning entirely).

I also think the use of Python code in Section 4.4 makes this spec even 
more recondite then I originally thought. And I'm pretty good at Python.

I don't really understand the rush to push this spec to final status. 
Clearly, there has been very little feedback from the community (or the 
acknowledgements would be longer).

This spec is not just bringing what was done in SAML into OAuth-land. It 
is proposing a whole new cultural solution that will have to be 
coordinated between developers and organizational leadership.

One of the great things about OpenID Connect is that developer feedback 
was sought, and prioritized. This federation spec has a very top down 
feel--here is this great crytpo solution, and all you stupid developers 
will just have to learn it, because it's so "basic" and "simple".

I'm all for creating OpenID Federation--it's important work. And the WG 
that I host at Kantara (OTTO), is relying on this part to be figured out 
at the OIDF.  But I don't think this spec represents the level of broad 
community conversation that needs to happen.

I also don't think that it communicates well enough the context needed 
by developers, federation operators, participants, and the hosting 
companies that manage federations.

As it stands right now, I'd vote against it.

- Mike


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