I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS->RS work is probably simpler and more useful at this point.
EH > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Thursday, March 15, 2012 4:47 AM > To: ext Blaine Cook; Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering > > Hi Blaine, > > These are indeed good requirements you stated below. > > When you look at the list of topics do you think that the proposed items > indeed fulfill them? > > Ciao > Hannes > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of ext Blaine Cook > > Sent: Thursday, March 15, 2012 1:31 PM > > To: Hannes Tschofenig > > Cc: oauth@ietf.org WG > > Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering > > > > On 14 March 2012 20:21, Hannes Tschofenig > <hannes.tschofe...@gmx.net> > > wrote: > > > So, here is a proposal: > > > > > > [Editor's Note: New work for the group. 5 items maximum! ] > > > > > > Aug. 2012 Submit 'Token Revocation' to the IESG for consideration > > as a Proposed Standard > > > Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for > > consideration as a Proposed Standard > > > Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for > > OAuth 2.0' to the IESG for consideration > > > Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to > > the IESG for consideration as a Proposed Standard > > > Sep. 2012 Submit 'OAuth Use Cases' to the IESG for consideration > > as an Informational RFC > > > > This looks great to me. > > > > I have serious concerns about feature-creep, and think that the OAuth > > WG should strongly limit its purview to these issues. In general, I > > think it prudent for this working group in particular to consider > > standardisation of work only under the following criteria: > > > > 1. Proposals must have a direct relationship to the mechanism of OAuth > > (and not, specifically, bound to an application-level protocol). > > 2. Proposals must have significant adoption in both enterprise and > > startup environments. > > 3. Any proposal must be driven based on a consideration of the > > different approaches, as adopted in the wild, and strive to be a > > better synthesis of those approaches, not a means to an end. > > > > These are the constraints with which I started the OAuth project, and > > they're more relevant than ever. I'd hate to see OAuth fail in the end > > because of a WS-*-like death by standards-pile-on. > > > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
