All but a handful of OAuth WG participants participated in developing OpenID Connect.
Yes some companies chose not to participate for whatever reasons and have not committed to the mutual non assert IPR agreement, and that is unfortunate, but not a reason to start again from scratch. Changing the OIDF IPR policy of totally open specifications based on non asserts is also not a option. I have made comments on the current draft of a4c. I think a profile of Connect introducing a grant_type returning only an id_token would be simpler than trying to do this as a separate spec. I do note that you can do effectively the same thing now by using a code response_type and a scope of openID. This doesn't result in any extra user consent other than consenting to login to the RP the first time (though that consent can be given in advance out of band in a enterprise scenario. When developing Connect we debated having a token endpoint response with only a id_token but decided that it was not in the spirit of being a OAuth 2 profile. So we decided to return a access token even if the user info endpoint contains no claims other then sub. People almost always want more claims as they roll out a real deployment. It is easy to add them if you have designed to be able to talk to a RS. OAuth without a RS is a touch not OAuth. a4c also completely ignores modern development environments like node.js where the client is in the user agent, that OAuth 2 and Connect support. By the time the OAuth WG is done with a4c it will likely be a similar size as Connect if it addresses the same use cases. I still don't see the problem with having a deployment profile of Connect that can meet 100% of the current stated use case for a4c. I expect that the people here involved in Connect will form there own opinions on comments regarding the number of participants and the quantity of the work and review. Regards John B. On Jun 12, 2014, at 4:38 PM, Hans Zandbelt <hzandb...@pingidentity.com> wrote: > +1, after implementing OIDC I will support the claim that any SSO protocol > with a minimal set of required features smaller than OIDC is insecure and any > protocol with similar features but with different parameter names is just > creating confusion and will increase chances of non-interoperable and > insecure implementations > > Hans. > > On 6/12/14, 9:50 PM, Bill Burke wrote: >> >> >> On 6/12/2014 12:49 PM, Prateek Mishra wrote: >>> The OpenID Connect 2.0 COre specification alone is 86 pages. It has >>> received review from maybe a dozen engineers within the OpenID community. >>> >> >> The OpenID Connect spec is 86 pages because it pretty much rehashes the >> OAuth2 spec walking through each flow and how Open ID Connect expands on >> that flow. A4c looks like a subset of this work minus some additional >> claims and, IMO, is incomplete compared to OIDC. >> >> FWIW, add 5 Red Hat engineers to the "dozen" of reviewers. We >> originally were creating our own oauth2 extension using JWT, but found >> that any feature we wanted to define already existed in OpenID Connect. >> These guys have done great work. Aren't many of you here authors of >> this spec and/or the same companies?!? I think your energies are better >> focused on lobbying OIDC to join the IETF and this WG. >> >> > > -- > Hans Zandbelt | Sr. Technical Architect > hzandb...@pingidentity.com | Ping Identity > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
