Last call comments on draft-ietf-oauth-v2-bearer-03: Section 2.1:
- ABNF includes '1#auth-param', but no prose is provided about how new parameters may be defined. There is no reason for this scheme to be extensible, given its designed simplicity and limitations. If more attributes are needed in the future, a new scheme must be defined. - RWS should be replaces with SP since the header has no other attributes (and should not have any). This will make parsing easier by mandating a single space (unless HTTPbis has other guidelines). Section 2.4: - Realm is a required attribute per RFC 2617. While discussions about this are on-going in HTTPbis (open issue), this document must comply with the current standard. If the WG feels strongly about it, it should engage the HTTPbis working group and provide feedback. - ABNF includes '( token "=" ( token / quoted-string ) )', but no prose is provided about how new parameters may be defined. Retained this extensibility point must be justified with actual use cases. Section 2.4.1: - Why are the HTTP error code suggested and not required? Section 4.1.1: - There is no 'Additional Resource Request Parameters' in the template - remove. - Missing 'Additional Token Endpoint Response Parameters: None'. Section 4.2: - The entire registry is ridiculous. Protected resource endpoints are completely within the authority of the resource provider. The fact that this document defines the 'oauth_token' parameter which infringes on the provider's namespace is bad enough. To suggest that this document has any authority over other parameters defined and used by the resource server is overreaching. No single use cases has been suggested for this registry in over three years of OAuth work. Section 4.2.2.2: - There is no 'error' parameter for resource responses. It is not defined anywhere in this specification or elsewhere. There is an 'error' attribute defined for the WWW-Authenticate header, but so is 'error_description' and 'error_uri'. How exactly is this parameter added to the resource response if not in the header? If it is in the header, there is no such location in the registry (nor is header extensibility discussed see 2.4). Section 4.3: - This registry is unnecessary and adds no value here (namespace collision is unlikely in general, and unlikely to cause problems). No use cases where suggested to justify it, and no additional error codes were proposed in over a year of discussions. Error codes were intentionally left non-extensible to increase interoperability. If addition color is needed for existing error codes, additional response parameters may be registered. Otherwise, if new error codes are needed, a new RFC must be published updating draft-ietf-oauth-v2. - The only way to define such a registry is to bring it up as a comment for draft-ietf-oauth-v2. Otherwise, it is limited to the Bearer token header only (and since this document is not extensible, not needed even here). This document is not ready for publication. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Wednesday, March 02, 2011 12:32 AM > To: OAuth WG > Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-bearer-03.txt > > This is a Last Call for comments on > > http://www.ietf.org/id/draft-ietf-oauth-v2-bearer-03.txt > > Please have your comments in no later than March 25 (extended deadline > because of the ongoing OAuth base specification WGLC). > > Do remember to send a note in if you have read the document and have no > other comments other than "its ready to go" - we need those as much as we > need "I found a problem". > > Thanks! > Hannes & Blaine > _______________________________________________ > 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
