Re: [OAUTH-WG] OAuth WG Re-Chartering

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-bounces@ietf.org [mailto:oauth-bounces@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-bounces@ietf.org [mailto:oauth-bounces@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.tschofenig@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