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

[Mike Jones <[e-mail]>]

Thanks for your comments, Mark.  Here are my thoughts on the issues that you see as being outstanding.  I'd also welcome additional input from the working group on these topics:

ON THE URI QUERY PARAMETER METHOD:

It seems like your objection to this is based on it using a standard query parameter name.  It therefore seems like there are four possible resolutions to this issue:

1.  Delete the query parameter method, as you suggested in your initial comments.  Given that I know this method is in widespread use in certain contexts, I doubt that there would be working group consensus for this resolution.

2.  Use a method for discovering the query parameter name.  It's my understanding that discovery work is presently out of scope for the OAuth working group as currently chartered.  The chairs and area directors could obviously change this, but it's my sense that developing a discovery spec for this purpose would delay the approval of this spec by a significant period of time.  I also question whether working group consensus could be developed for this resolution.

3.  Change the normative requirement for using the name access_token to a recommendation.  Specifically, we could change the text "When sending the access token in the HTTP request URI, the client adds the access token to the request URI query component ... using the 'access_token' parameter" to "When sending the access token in the HTTP request URI, the client adds the access token to the request URI query component ... using a query parameter.  It is RECOMMENDED that the query parameter name 'access_token' be used".  (If we change this to RECOMMENDED, I suspect we'd also do the same for the name of the form-encoded body parameter.)  This would seem to resolve your core objection, while still providing clear guidance to aid interoperability.  What would people think of this?

4.  Leave the specification as-is.

I'd like to hear working group opinions on which of these potential resolutions members support.

ON THE WWW-AUTHENTICATE RESPONSE HEADER FIELD:  

See the follow-up discussion with Julian.

ON THE REALM AND SCOPE DEFINITIONS:

You wrote "That's not a great story for interop. How are people actually supposed to use them? Can you at least give an example?"  I agree with you that that's not a great story for interop but it's also the current reality of OAuth usage.  Indeed, I know that different deployments use them in different ways for different things.  There's a bunch of information that currently needs to be exchanged in a manner not covered by the specifications to use OAuth between parties.  Among other things, this includes the endpoint addresses, the ways that realm and scope are used, and (when not opaque) the format of the access token.

(Profiles of OAuth such as OpenID Connect address this by providing specific guidance, but that guidance, I believe, is too specific to add to the OAuth specs themselves.)

Given that both scope and realm are used in practice in different ways by different deployments, I don't see a clear resolution to this issue other than to leave the spec as-is.  I'd welcome specific alternative wording proposals, however.

ON SPECIFYING ONLY A QUOTED-STRING SERIALIZATION:

I understand and agree with your desire to promote code reuse.  You cite HTTPbis P7 2.3.1 to support adding a requirement for supporting token serialization in addition to quoted-string serialization for all parameters.  I believe that the relevant text there is:
      When the auth-param syntax is used, all parameters ought
      to support both token and quoted-string syntax, and syntactical
      constraints ought to be defined on the field value after parsing
      (i.e., quoted-string processing).  This is necessary so that
      recipients can use a generic parser that applies to all
      authentication schemes.

      Note: the fact that the value syntax for the "realm" parameter is
      restricted to quoted-string was a bad design choice not to be
      repeated for new parameters.

First, it's my understanding that this text was added between -16 and -17 explicitly to try to force a change the definitions used in the Bearer spec.  While this seems heavy-handed, be that as it may.   Assuming the specification remains as-is, I think there are two code reusability cases to consider:

Recipient Case:  Recipients are able to use code capable of parsing both token and quoted-string syntax to parse fields that may only contain quoted string syntax.  Thus, the rationale for this requirement given in P7 is actually incorrect; recipients *can* use a generic parser that applies to all authentication schemes.  (Perhaps P7 should be corrected?)  There is no code-reuse problem for recipients.

Producer Case:  I will grant that it is possible for generic parameter producer code to exist that does not give the caller control over how the parameter is serialized.  If such code is used, it would be possible for a parameter value such as "xyz" to be erroneously serialized as xyz, thus creating an interoperability problem.  Note however, that serialization of the HTTP-defined realm parameter MUST occur using quoted-string serialization.  Thus, in practice, it would seem that generic frameworks still need to enable callers to control the serialization formats of specific parameters.  Hence, I doubt that this problem-in-theory is actually a problem-in-practice.  I'd be interested in data points from the working group about whether HTTP frameworks they use would have his problem in practice or not.

It seems that there are two possible resolutions to this issue:

1.  Change the spec to allow both quoted-string and token serialization for these parameters.

2.  Leave the specification as-is.

I'd like to hear working group opinions on which of these potential resolutions members support.

ON SUITABILITY AS A PROXY AUTHENTICATION SCHEME:

Could someone who is a member of [e-mail] volunteer to ask that list whether they would like to make any review comments on http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15 as to its suitability for use as a proxy authentication scheme (and to cc: me when you ask the question)?  I'm not a member of this list.

				Thanks all,
				-- Mike

-----Original Message-----
From: Mark Nottingham [mailto:[e-mail]] 
Sent: Wednesday, December 14, 2011 6:37 PM
To: Mike Jones
Cc: Stephen Farrell; Hannes Tschofenig; Peter Saint-Andre; Barry Leiba; OAuth WG
Subject: Re: OK to post OAuth Bearer draft 15?

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/