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

[Mike Jones]

What's being done is promoting the spec to Implementer's Draft status, which locks in the IPR commitments of the contributors and suggests that implementers use that draft for interop testing and prototype deployments.  That's a wholly different status than Final Specification, which is not the current goal.

I believe that there were three different sets of Implementer's Drafts of the OpenID Connect specs before we promoted them to Final Specifications.  And I agree with you, Mike, the developer feedback from testing and deploying these Implementer's Drafts was critical to getting solid and deployable Final Specifications.  We're aiming for the same level of developer feedback on the Federation spec - in part enabled by taking it to Implementer's Draft status.

I expect lots more changes, additions, removals, and refinements before Federation is final - just like there with Connect.  Thanks for being part of the process.

				-- Mike

P.S.  A vote against Implementer's Draft status essentially boils down to "I do not want developers to have IPR protections when implementing this draft".

-----Original Message-----
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Mike Schwartz via Openid-specs-ab
Sent: Saturday, June 9, 2018 2:30 PM
To: Openid-specs Ab <openid-specs-ab at lists.openid.net>
Subject: [Openid-specs-ab] OpenID Federation: more problems with this draft


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/
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab