[Openid-specs-ab] More thoughts on OpenID Federation Vote
mike at gluu.org
Wed Jul 18 14:44:12 UTC 2018
>> 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
More information about the Openid-specs-ab