On 6/13/2014 12:24 PM, Prateek Mishra wrote:
Excellent, now you have put your finger on the precise issue with OIDC - lots of optional extensions and shiny trinkets and lack of a clear definition of a core subset for servers.
OIDC is a very clear specification. Your phrase "shiny trinkets" hints that there are a lot of silly features in OIDC. I disagree with your assessment. I just see features that I want to implement and are on our roadmap. At the same time, I'm relieved that I can call myself an OIDC compliant implementation and put off implementing these features for a later date.
Also, you make it sound like OIDC is this big bloated specification. I completely disagree with your assessment. Personally I see OIDC as a specification driven by real-world requirements and experience.
I realize its exciting for consultants, software and toolkit vendors to have that sort of optionality, but in practice, its NOT A GOOD THING in a protocol.
I disagree. If OIDC core was instead broken up into a set of smaller optional specifications, you would run the risk of having zero interoperability. Maybe that is your end-goal, but it certainly isn't mine. Most of the language around optional features states that "if you don't implement this, your implementation needs to handle it gracefully". All *GOOD* things for a protocol.
But, IMO, there is no difference in having a complete, robust specification like OIDC that has a lot of optional parts from re-hashing OIDC at the IETF with a lot of optional specifications. Other than causing confusion in the community, of course.
Let me further say that my experience as an OAuth 2.0 implementor was difficult as it was hard to put a finger on what exact OAuth 2 extensions people were gravitating towards. OIDC, for me at least, gave a much more complete direction for my project.
-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
