Re: [OAUTH-WG] OK to post OAuth Bearer draft 15?

[Mark Nottingham <[e-mail]>]

Hi Mike -

It's not my function to object (or not) to the publication of the draft; I merely provided the APPS review, which will be considered by the responsible AD (like all other Last Call comments), and potentially the IESG.

If you're asking whether my concerns have been addressed, see some specifics below.

Regards,


On 15/12/2011, at 1:13 PM, Mike Jones wrote:

> Mark, Stephen, Hannes, and Barry,
>  
> Any objections to posting the updated Bearer draft incorporating the results of the APPS Area review and the TLS requirements?
>  
>                                                             -- Mike
>  
> From: Mike Jones 
> Sent: Monday, December 12, 2011 8:51 AM
> To: Mark Nottingham; 'Stephen Farrell'; [e-mail]
> Subject: RE: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14
>  
> 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

What does "developmental environments" mean here?

> , 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.

I find it hard to believe that you could not find or design a mechanism to discover a URI.


> 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.

The fact that a non-standards-track document did something that's potentially harmful doesn't make it OK. Saying that problems won't occur based upon such short-term implementation experience with this type of issue is ludicrous; the nature of the issue is long-term encroachment and setting precedent.


>>  * 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 Reschke’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.

See follow-up discussion with Julian.


>> * 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.”

Yes...

> 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.

That's not a great story for interop. How are people actually supposed to use them? Can you at least give an example?


>>  Do you really intend to disallow *all* extension parameters on the challenge?
>  
> Yes.  There was an explicit working group consensus decision to do so.

It would be good to note this.


>> 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.

And I'm sure you're aware that the goal of this text in HTTPbis is to encourage reuse of code, rather than having multiple implementations of slightly different things. This is doubly true when you're not actually defining the syntax, but instead reusing syntax from elsewhere (HTTP), which already has parsers and generators implemented. 


>> * 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?

The easiest way would be to ask on the [e-mail] mailing list; there are several intermediary implementers active there.

Regards,

--
Mark Nottingham   http://www.mnot.net/