There is not intention to bring the openID Connect work to the OAuth WG. It like many other protocols rely on OAuth 2.0 but are not part of it.
However if there are some things that we are doing as OAuth 2.0 extensions that are more general and can be standardized in the IETF, we should understand what they are. We are having a openID Connect meeting on Sunday prior to IETF. People are encouraged to attend and refine opinions about the appropriate homes for some of this new(to IETF) work. Registration is at: http://www.eventbrite.com/event/3064019565 The account chooser WG that Blaine mentioned at OIDF is up and running now, with a online meeting happening Thursday for those that are interested. https://sites.google.com/site/oidfacwg/ http://acwg2012march-estw.eventbrite.com So +1 for composition. John B. On 2012-03-19, at 12:24 PM, Blaine Cook wrote: > On 15 March 2012 17:31, Zeltsan, Zachary (Zachary) > <[email protected]> wrote: >> ... Considering OpenID Connect as a motivating use case for OAuth, SWD is >> the one spec that would then be missing for this OAuth use case. > > I worry that bringing OpenID Connect into OAuth (rather than building > upon OAuth) will have detrimental effects for both efforts. OAuth is > successful in part because we chose not to push OAuth-like > functionality into the OpenID umbrella (which at the time was focused > on shipping OpenID 2.0). > > It seems prudent to learn from the experience of WS-*, where > everything was combined into one huge ball of standards-wax. The > result was both impenetrable and not fit for purpose due to the many > interdependencies (both social and technical) involved. > > Composition has served the IETF and the internet well, and nothing > prevents the OpenID standards from being created in the context of a > new working group, or from within the OpenID foundation. Indeed, it's > been working quite well, and projects like the Account Chooser are > showing great promise and focusing on the important things (UX) rather > than specifications-for-specification's sake. > > b. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
