Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

[Eran Hammer-Lahav <[e-mail]>]

Re: client assertion credentials

The actual  decision to move the section out and call for someone to edit a new document was made by the chair. I will not put it back unless instructed by the chair based on working group consensus and a revised language that addresses my concerns. And you are still ignoring all the issues I raised...

Re: WWW-Authenticate header

You have made no arguments to retain this header or scheme. As -12 clearly shows, it has no place in the document since at no point is it necessary to return an OAuth2 authentication challenge (and what does it even mean?). As currently defined, each token type uses its own authentication scheme which comes with its own WWW-Authenticate header. The bearer token specification should define its own challenge and as I commented earlier, should not use 'OAuth2' as its scheme because it is confusing and prejudicial. I will not put it back unless instructed by the chair based on working group consensus on a new proposed language that fits the new organization of -12.

EHL


> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Friday, January 21, 2011 10:38 AM
> To: Eran Hammer-Lahav; [e-mail]
> Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> Please (re-)add my comments into your queue that the client assertion
> credentials and WWW-Authenticate header should be retained.  Also, per
> Marius' note of January 20th, Google has plans to use the client assertion
> credentials as well.
> 
> You argue that interop is not hindered by removing features that could be
> defined as extensions.  And that since additional knowledge is required to
> use these features that is outside the scope of the specification, that there is
> no value in retaining them.
> 
> The problem with those lines of reasoning is that the same arguments could
> be applied to the whole specification.  People *could* implement OAuth
> flows with no OAuth specification at all.  So why not get rid of all of it?
> Simply, that interop is enhanced by having common ways to do common
> things -- even if some additional knowledge is required to do them.
> 
> Please retain these features.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Thursday, January 20, 2011 9:42 PM
> To: [e-mail]
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> Forgot to mention that I don't have any outstanding comments in my queue
> so if your feedback was not incorporated into -12, and you feel strongly
> about it, bring it up again.
> 
> EHL
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Eran Hammer-Lahav
> > Sent: Thursday, January 20, 2011 4:57 PM
> > To: [e-mail]
> > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> >
> > Draft -12 is finally out.
> >
> > This is almost a complete rewrite of the entire document, with the
> > primary goal of moving it back to a similar structure used in -05. I
> > have been thinking about this for a few months and finally came up
> > with a structure that combines the two approaches.
> >
> > The draft includes some major cleanups, significantly simpler
> > language, reduces repeated prose, and tried to keep prose to the
> > introduction and normative language in the rest of the specification.
> > I took out sections that broke the flow, and did my best to give this
> > a linear narrative that is easy to follow.
> >
> > The draft includes the following normative changes:
> >
> >    o  Clarified 'token_type' as case insensitive.
> >    o  Authorization endpoint requires TLS when an access token is issued.
> >    o  Removed client assertion credentials, mandatory HTTP Basic
> > authentication support for client credentials, WWW-Authenticate
> > header, and the OAuth2 authentication scheme.
> >    o  Changed implicit grant (aka user-agent flow) error response from
> > query to fragment.
> >    o  Removed the 'redirect_uri_mismatch' error code since in such a
> > case, the authorization server must not send the error back to the client.
> >    o  Defined access token type registry.
> >
> > I would like to spend the coming week receiving and applying feedback
> > before requesting a WGLC for everything but the security
> > considerations section (missing) 2/1.
> >
> > EHL
> >
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of [e-mail]
> > > Sent: Thursday, January 20, 2011 4:45 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > This draft is a work item of the Open Authentication Protocol
> > > Working Group of the IETF.
> > >
> > >
> > > 	Title           : The OAuth 2.0 Authorization Protocol
> > > 	Author(s)       : E. Hammer-Lahav, et al.
> > > 	Filename        : draft-ietf-oauth-v2-12.txt
> > > 	Pages           : 46
> > > 	Date            : 2011-01-20
> > >
> > > This specification describes the OAuth 2.0 authorization protocol.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet- Draft.
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth