[Openid-specs-ab] More thoughts on OpenID Federation Vote
Michael.Jones at microsoft.com
Wed Jul 18 15:29:33 UTC 2018
Yes, we absolutely recommend implementation of this and all other Implementer's Drafts precisely so we can learn what works, what doesn't, what's needed, what's unnecessary, and what could be clearer. The kinds of feedback that come from implementation and deployment are critical to creating solid, usable specifications.
Remember, there are likely to be several progressions of Implementer's Drafts for this spec before we make it a Final Specification, just as there have been with the other OpenID Connect specifications. Feedback from implementing and deploying each one informs the content of the next, with significant changes to be expected between each one. The first Implementer's Draft is typically the start of the feedback cycle from implementers - not the end of it.
Also, recall per the 27-Nov-17 call notes at http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20171127/006690.html, that significant discussion of the specification has been occurring in experienced federation communities worldwide and several implementations in multiple languages have been written and interop tested with one another. This is highly visible and important work. I personally encourage Gluu and others to implement, kick the tires, interop test, and give us your feedback while the spec is still malleable.
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Mike Schwartz via Openid-specs-ab
Sent: Wednesday, July 18, 2018 10:44 AM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] More thoughts on OpenID Federation Vote
>> A vote against Implementer's Draft status essentially boils down to
>> "I do not want developers to have IPR protections when implementing
>> this draft".
Isn't a vote also implying that you recommend that developers start coding client and server implementations of this spec?
And I want to make it clear that I like the direction of this work. I think using something like OAuth software statements to convey trust is a good idea. It aligns with some of the ideas around Trustmarks:
I am also keenly interested to see OIDC solve this problem. That's why I'm commenting here. If I didn't care, I wouldn't say anything...
What I object to is the process and the timing. I think we need to coalesce a more inclusive process, that comes to consensus on major design decisions. I think we need to enlarge the community, which will help with adoption.
As Gluu is a company that is likely an early implementer of this work, my reticence to assign resources is a red flag. I've considered it, and every time I read the spec, I feel like it's out of touch with developers. I imagine explaining this to potential early adopters, and I just can't figure out how I'm going to do that. The federation operators have the skills, but federations also include the IDPs and SPs (or OPs and RPs....), who have less technical chops. I spend a lot of time on the phone with the consumers of this tech... so I have some insights into the challenge.
It seems inefficient to move forward with this design, and hope we'll fix it along the way. When most of the other OpenID Connect specs went to Implementers Draft, large consumer IDPs had already rolled out OAuth authentication API's. So there was much more operational experience. So I don't think it's an apples:apples comparison. We have federations today, but they are significantly different from what is proposed here.
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