[apps-discuss] Fwd: Re: [OAUTH-WG] FW: APPS Area review of draft-ietf-oauth-v2-bearer-14

[S Moonesamy <[e-mail]>]

I am forwarding the response to the review posted 
at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html

Regards,
S. Moonesamy

>From: Mike Jones <[e-mail]>
>
>
>Thanks for the detailed review, Mark.
>
>Preliminary draft 15 of the OAuth Bearer 
>specification is attached.  It resolves the form 
>encoding issues raised by Julian Reschke in the 
>manner discussed at the working group meeting in 
>Taipei, incorporates the consensus text on TLS 
>version requirements, and contains several 
>improvements suggested by Mark Nottingham during APPS area review.
>
>Mark, comments on all your proposed changes follow below:
>
>* Section 2.3 URI Query Parameter
>
>This section effectively reserves a URI query 
>parameter for the draft's use. This should not 
>be done lightly, since this would be a precedent 
>for the IETF encroaching upon a server's URIs 
>(done previously in RFC5785, but in a much more 
>limited fashion, as a tactic to prevent further, uncontrolled encroachment).
>
>Given that the draft already discourages the use 
>of this mechanism, I'd recommend dropping it 
>altogether. If the Working Group wishes it to 
>remain, this issues should be vetted both 
>through the APPS area and the W3C liaison.
>
>(The same criticism could be leveled at Section 
>2.2 Form-Encoded Body Parameter, but that at 
>least isn't surfaced in an identifier)
>
>There are some contexts, especially limited 
>browsers and/or development environments, where 
>query parameters are usable but the other 
>methods are not.  Thus, the query parameter 
>method must be retained.  Also, Justin Richter's 
>comments describing the value to him of the 
>query parameter method are pertinent:  A URL 
>with all parameters including authorization is a 
>powerful artifact which can be passed around between systems as a unit.
>
>As to using a standard parameter name, this is 
>essential for interoperability.  It is not 
>reserved in any contexts other than when the 
>Bearer spec is employed, which is a voluntary 
>act by both parties.  Thus, this poses no undue 
>burdens or namespace restrictions on implementations in practice.
>
>Finally, you'll find that OAuth 1.0 [RFC 5849] 
>similarly defined, not one, but two standard 
>query parameter values:  oauth_token and 
>oauth_verifier.  As this didn't cause any 
>problems in practice then, I'm sure that 
>defining an access_token parameter within the 
>Bearer spec for interoperability purposes won't cause a problem either.
>
>* Section 3 The WWW-Authenticate Response Header Field
>
>The draft references the quoted-string ABNF from 
>HTTP, but changes its processing in a later paragraph:
>
>"""In all these cases, no character quoting will 
>occur, as senders are prohibited from using the %5C ('\') character."""
>
>This is at best surprising (as many readers will 
>reasonably surmise that using the quoted-string 
>ABNF implies that the same code can be used).
>Please either use quoted-string as defined (i.e., with escaping).
>
>This parameter definition was a result of 
>significant working group discussion and 
>reflects a solid consensus position.  Using the 
>quoted string BNF makes it clear, per Julian 
>Reschk's suggestions, that generic parameter 
>parsing code can be safely used.  Whereas 
>prohibiting the use of backslash quoting by 
>senders also makes it clear that custom 
>implementations can directly utilize the 
>parameter values as transmitted without performing any quote processing.
>
>In short, the spec doesn't change the processing 
>of quoted strings.  It simply restricts the set 
>of legal input characters within the quoted strings.
>
>* Section 1: Introduction
>
>The introduction explains oauth, but it doesn't 
>fully explain the relationship of this 
>specification to OAuth 2.0. E.g., can it be used 
>independently from the rest of OAuth? Likewise, the overview (section
>1.3) seems more specific to the OAuth specification than this document.
>As I read it, this mechanism could be used for 
>ANY bearer token, not just one generated through OAuth flows.
>
>If it is indeed more general, I'd recommend 
>minimising the discussion of OAuth, perhaps even 
>removing it from the document title.
>
>Per your suggestion, I've made it clear in the 
>introduction that bearer tokens from any source 
>can be used to access associated protected 
>resources.  The new language in the introduction is:
>
>This specification defines the use of bearer 
>tokens over HTTP/1.1 
>[I-D.ietf-httpbis-p1-messaging] using TLS 
>[RFC5246] to access protected resources. … While 
>designed for use with access tokens resulting 
>from OAuth 2.0 Authorization [I-D.ietf-oauth-v2] 
>flows to access OAuth protected resources, this 
>specification actually defines a general HTTP 
>authorization method that can be used with 
>bearer tokens from any source to access any 
>resources protected by those bearer tokens.
>
>* Section 3 The WWW-Authenticate Response Header Field
>
>The difference between a realm and a scope is 
>not explained. Are the functionally equivalent, 
>just a single value vs. a list?
>
>Realm is as defined by HTTPbis.  It says that 
>The realm value is a string, generally assigned 
>by the origin server, which can have additional 
>semantics specific to the authentication 
>scheme.  The Bearer specification intentionally 
>adds no extra semantics to the realm 
>definition.  Whereas the scope parameter is 
>defined as an order-independent space-separated 
>list of scope values.  The contextual meaning of 
>both the realm and scope parameters is deployment-dependent.
>
>Do you really intend to disallow *all* extension parameters on the challenge?
>
>Yes.  There was an explicit working group consensus decision to do so.
>
>Also, the scope, error, error_description and 
>error_uri parameters all specify only a 
>quoted-string serialisation. HTTPbis strongly 
>suggests that new schemes allow both forms, 
>because implementation experience has shown that 
>implementations will likely support both, no 
>matter how defined; this improves interoperability (see p7 2.3.1).
>
>Once again, the current text reflects a 
>consensus decision of the working group.  It was 
>viewed that requiring support for multiple ways 
>of doing the same thing unnecessarily 
>complicated implementations without any 
>compensating benefit; better to support one 
>syntax for each semantic operation and require all implementations to use it.
>
>Finally, the error_description parameter can 
>carry only ASCII characters. While I understand 
>a tradeoff has been made here (and, in my 
>judgement, an appropriate one), it's appropriate to highlight this in review.
>
>Noted
>
>* General
>
>The draft currently doesn't mention whether 
>Bearer is suitable for use as a proxy 
>authentication scheme. I suspect it *may*; it 
>would be worth discussing this with some proxy 
>implementers to gauge their interest (e.g., Squid).
>
>Who would you recommend review the draft from this perspective?
>
>Finally, Mark, I applied all the editorial 
>suggestions you made.  Thanks for those.
>
>Mark, Stephen, and chairs, please let me know 
>whether to now post this draft as an actual submission.
>
>                                                             Thanks all,
>                                                             -- Mike
>
>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of 
>Tschofenig, Hannes (NSN - FI/Espoo)
>Sent: Wednesday, November 23, 2011 11:51 PM
>To: [e-mail]
>Subject: [OAUTH-WG] FW: [apps-discuss] APPS Area 
>review of draft-ietf-oauth-v2-bearer-14
>
>FYI
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of ext Mark Nottingham
>Sent: Thursday, November 24, 2011 8:22 AM
>To: IETF Apps Discuss; [e-mail]
>Cc: The IESG
>Subject: [apps-discuss] APPS Area review of
>draft-ietf-oauth-v2-bearer-14
>
>I have been selected as the Applications Area 
>Review Team reviewer for this draft (for 
>background on apps-review, please see 
><http://www.apps.ietf.org/content/applications-area-review-team>).
>
>Please resolve these comments along with any 
>other Last Call comments you may receive. Please 
>wait for direction from your document shepherd 
>or AD before posting a new version of the draft.
>
>Document: draft-ietf-oauth-v2-bearer-14
>Title: OAuth 2.0 Bearer Tokens
>Reviewer: Mark Nottingham
>Review Date: 24/11/2011
>
>Summary: This draft is almost ready for 
>publication as a Proposed Standard, but has a few issues that should be fixed.
>
>Major Issues
>------------
>
>* Section 2.3 URI Query Parameter
>
>This section effectively reserves a URI query 
>parameter for the draft's use. This should not 
>be done lightly, since this would be a precedent 
>for the IETF encroaching upon a server's URIs 
>(done previously in RFC5785, but in a much more 
>limited fashion, as a tactic to prevent further, uncontrolled encroachment).
>
>Given that the draft already discourages the use 
>of this mechanism, I'd recommend dropping it 
>altogether. If the Working Group wishes it to 
>remain, this issues should be vetted both 
>through the APPS area and the W3C liaison.
>
>(The same criticism could be leveled at Section 
>2.2 Form-Encoded Body Parameter, but that at 
>least isn't surfaced in an identifier)
>
>* Section 3 The WWW-Authenticate Response Header Field
>
>The draft references the quoted-string ABNF from 
>HTTP, but changes its processing in a later paragraph:
>
>"""In all these cases, no character quoting will 
>occur, as senders are prohibited from using the %5C ('\') character."""
>
>This is at best surprising (as many readers will 
>reasonably surmise that using the quoted-string 
>ABNF implies that the same code can be used).
>Please either use quoted-string as defined (i.e., with escaping).
>
>
>Minor Issues
>------------
>
>* Section 1: Introduction
>
>The introduction explains oauth, but it doesn't 
>fully explain the relationship of this 
>specification to OAuth 2.0. E.g., can it be used 
>independently from the rest of OAuth? Likewise, the overview (section
>1.3) seems more specific to the OAuth specification than this document.
>As I read it, this mechanism could be used for 
>ANY bearer token, not just one generated through OAuth flows.
>
>If it is indeed more general, I'd recommend 
>minimising the discussion of OAuth, perhaps even 
>removing it from the document title.
>
>* Section 3 The WWW-Authenticate Response Header Field
>
>The difference between a realm and a scope is 
>not explained. Are the functionally equivalent, 
>just a single value vs. a list?
>
>Do you really intend to disallow *all* extension parameters on the challenge?
>
>Also, the scope, error, error_description and 
>error_uri parameters all specify only a 
>quoted-string serialisation. HTTPbis strongly 
>suggests that new schemes allow both forms, 
>because implementation experience has shown that 
>implementations will likely support both, no 
>matter how defined; this improves interoperability (see p7 2.3.1).
>
>Finally, the error_description parameter can 
>carry only ASCII characters. While I understand 
>a tradeoff has been made here (and, in my 
>judgement, an appropriate one), it's appropriate to highlight this in review.
>
>* General
>
>The draft currently doesn't mention whether 
>Bearer is suitable for use as a proxy 
>authentication scheme. I suspect it *may*; it 
>would be worth discussing this with some proxy 
>implementers to gauge their interest (e.g., Squid).
>
>
>Nits
>----
>
>* Section 2.1 Authorization Request Header Field
>
>"simplicity reasons" --> "simplicity"
>
>"If additional parameters are desired in the 
>future, a different scheme could be defined." 
>--> "If additional parameters are needed in the 
>future, a different scheme would need to be defined."
>
>* Section 3 The WWW-Authenticate Response Header Field
>
>The requirement that a resource server MUST 
>include the HTTP WWW-Authenticate response 
>header field is odd; really this is at the 
>discretion of the server. Is it really necessary 
>to use a conformance requirement here?
>
>URI-reference --> URI-Reference
>
>* Section 3.1 Error Codes
>
>405 belongs in the list of typically appropriate status codes as well.
>
>
>Kind regards,
>
>--
>Mark Nottingham   http://www.mnot.net/