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 [email protected] 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:[email protected]]
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'; [email protected]
> 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 [email protected] mailing list; there
are several intermediary implementers active there.
Regards,
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
