JWT and SWD are the highest priority to find a home. We are doing token introspection and dynamic registration. Those are larger tasks to generalize, though probably worthwhile.
John B. On 2012-03-19, at 2:30 PM, Phil Hunt wrote: > I would support those features of connect that are more general being part of > the general spec family under the WG. > > Phil > > On 2012-03-19, at 9:31, John Bradley <ve7...@ve7jtb.com> wrote: > >> 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) >>> <zachary.zelt...@alcatel-lucent.com> 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
