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

From: Mike Jones <[email-masked]>
Date: Mon, 12 Dec 2011 16:51:06 +0000

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<http://tools.ietf.org/html/rfc5849>] 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 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.

* 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: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Wednesday, November 23, 2011 11:51 PM
To: [email-masked]
Subject: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

FYI

-----Original Message-----

From: [email-masked]<mailto:[email-masked]>

[mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of ext Mark Nottingham

Sent: Thursday, November 24, 2011 8:22 AM

To: IETF Apps Discuss; [email-masked]<mailto:[email-masked]>

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/

_______________________________________________

apps-discuss mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/apps-discuss

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Dec 2011 18:07:42 +0100

Mike,

On 2011-12-12 17:51, Mike Jones wrote:
> ...
> This parameter definition was a result of significant working group
> discussion and reflects a solid consensus position. Using the quoted
 > ...

I have to object to this summary. If there was consensus, it was rough 
at best.

Essentially, the two of us disagreed, and nobody else said anything. So 
I'd characterize the current text as the editor's preference, not any 
kind of WG consensus.

Further note that the current text is at odds with recommendations from 
a spec it normatively references (HTTPbis P7), so this issue will come 
up again during IETF Last Call.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Mon, 12 Dec 2011 17:28:54 +0000

Julian, you should reread the (substantial) mailing list threads on this topic.  As an example demonstrating the consensus, I've attached a pair of messages from a thread on this topic in which several people supported the input restriction to preclude character quoting.

For instance, in this thread Eran Hammer-Lahav wrote:  "All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever."

You'll also find that all of these people then explicitly agreed with this restriction:
John Bradley
William Mills
Phil Hunt
Mike Jones

I believe that there were others as well.  Therefore, it is inaccurate to characterize this consensus decision as "essentially, the two of us disagreed".

				Best wishes,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, December 12, 2011 9:08 AM
To: Mike Jones
Cc: Mark Nottingham; Stephen Farrell; [email-masked]
Subject: Re: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

Mike,

> discussion and reflects a solid consensus position. Using the quoted

I have to object to this summary. If there was consensus, it was rough at best.

Essentially, the two of us disagreed, and nobody else said anything. So I'd characterize the current text as the editor's preference, not any kind of WG consensus.

Further note that the current text is at odds with recommendations from a spec it normatively references (HTTPbis P7), so this issue will come up again during IETF Last Call.

Best regards, Julian

Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions
From: Mike Jones <[email-masked]>
To: William Mills <[email-masked]>, John Bradley <[email-masked]>, Eran Hammer-Lahav <[email-masked]>
Cc: OAuth WG <[email-masked]>
Date: Mon, 17 Oct 2011 22:25:26 +0000
List-Id: OAUTH WG <oauth.ietf.org>

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Monday, October 17, 2011 1:53 PM
To: John Bradley; Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

+1

  _____

From: John Bradley <[email-masked]<mailto:[email-masked]>>
To: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
Cc: OAuth WG <[email-masked]<mailto:[email-masked]>>
Sent: Monday, October 17, 2011 12:13 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

+1

On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote:

> All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever.
>
> EHL
>
>> From: Hannes Tschofenig [mailto:[email-masked]<mailto:[email-masked]>]
>> Sent: Monday, October 17, 2011 8:25 AM
>> To: Eran Hammer-Lahav
>> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG
>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>> Proposed Resolutions
>>
>> It is good that we have an agreement among a few people that more text
>> needs to be provided in the core specification on the issue of the scope
>> element.
>>
>> Now, there is still the question of what the text should say. The questions
>> from my earlier mails are therefore still applicable and need an answer.
>>
>> Ciao
>> Hannes
>>
>> On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote:
>>
>>> I agree.
>>>
>>> EHL
>>>
>>>> From: John Bradley [mailto:[email-masked]<mailto:[email-masked]>]
>>>> Sent: Monday, October 17, 2011 6:07 AM
>>>> To: Richer, Justin P.
>>>> Cc: Eran Hammer-Lahav; OAuth WG
>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>>>> Proposed Resolutions
>>>>
>>>> The scopes cross all of the profiles.
>>>>
>>>> I expect that restricting the character sets for bearer tokens, MAC,
>>>> and other future variants should be dealt with in those profiles.
>>>>
>>>> Without restricting scope in core, we leave the possibility of coming
>>>> up with different rules in different profiles e.g. MAC vs Bearer.
>>>>
>>>> It is probably best to have one rule in core that works across all the
>> profiles.
>>>>
>>>> John B.
>>>> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote:
>>>>
>>>>> I think the limit makes sense, but then are tokens limited by the
>>>>> same
>>>> rules? They need to live in all the same places (query parameters,
>>>> headers,
>>>> forms) that scopes do and would be subject to the same kinds of
>>>> encoding woes that scopes will. Or am I missing something obvious as
>>>> to why this isn't a problem for tokens (both bearer tokens and the
>>>> public part of MAC tokens) but is a problem for scope strings?
>>>>>
>>>>> -- Justin
>>>>> ________________________________________
>>>>> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of
>>>>> John Bradley [[email-masked]<mailto:[email-masked]>]
>>>>> Sent: Sunday, October 16, 2011 8:11 PM
>>>>> To: Eran Hammer-Lahav
>>>>> Cc: OAuth WG
>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>>>> Proposed Resolutions
>>>>>
>>>>> Restricting it now in the core spec is going to save a lot of headaches
>> later.
>>>>>
>>>>> John B.
>>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote:
>>>>>
>>>>>> It's an open question for the list.
>>>>>>
>>>>>> EHL
>>>>>>
>>>>>>> From: Julian Reschke [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>>> Sent: Sunday, October 16, 2011 11:00 AM
>>>>>>> To: Mike Jones
>>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth
>>>>>>> WG; Eran Hammer-Lahav
>>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues
>>>>>>> & Proposed Resolutions
>>>>>>>
>>>>>>> On 2011-10-16 18:44, Mike Jones wrote:
>>>>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide
>>>>>>>> range of
>>>>>>> characters in scope was unintentional. The design was limited to
>>>>>>> allow simple ASCII strings and URIs."
>>>>>>>> ...
>>>>>>>
>>>>>>> I see. Thanks.
>>>>>>>
>>>>>>> Is this going to be clarified in -23?
>>>>>>>
>>>>>>> Best regards, Julian

Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions
From: Phil Hunt <[email-masked]>
To: OAuth WG <[email-masked]>
Date: Mon, 17 Oct 2011 22:40:04 +0000
List-Id: OAUTH WG <oauth.ietf.org>

+1

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote:

> All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever.
>
> EHL
>
>> From: Hannes Tschofenig [mailto:[email-masked]]
>> Sent: Monday, October 17, 2011 8:25 AM
>> To: Eran Hammer-Lahav
>> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG
>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>> Proposed Resolutions
>>
>> It is good that we have an agreement among a few people that more text
>> needs to be provided in the core specification on the issue of the scope
>> element.
>>
>> Now, there is still the question of what the text should say. The questions
>> from my earlier mails are therefore still applicable and need an answer.
>>
>> Ciao
>> Hannes
>>
>> On Oct 17, 2011, at 7:27 AM, Eran Hammer-Lahav wrote:
>>
>>> I agree.
>>>
>>> EHL
>>>
>>>> From: John Bradley [mailto:[email-masked]]
>>>> Sent: Monday, October 17, 2011 6:07 AM
>>>> To: Richer, Justin P.
>>>> Cc: Eran Hammer-Lahav; OAuth WG
>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>>>> Proposed Resolutions
>>>>
>>>> The scopes cross all of the profiles.
>>>>
>>>> I expect that restricting the character sets for bearer tokens, MAC,
>>>> and other future variants should be dealt with in those profiles.
>>>>
>>>> Without restricting scope in core, we leave the possibility of coming
>>>> up with different rules in different profiles e.g. MAC vs Bearer.
>>>>
>>>> It is probably best to have one rule in core that works across all the
>> profiles.
>>>>
>>>> John B.
>>>> On 2011-10-16, at 7:19 PM, Richer, Justin P. wrote:
>>>>
>>>>> I think the limit makes sense, but then are tokens limited by the
>>>>> same
>>>> rules? They need to live in all the same places (query parameters,
>>>> headers,
>>>> forms) that scopes do and would be subject to the same kinds of
>>>> encoding woes that scopes will. Or am I missing something obvious as
>>>> to why this isn't a problem for tokens (both bearer tokens and the
>>>> public part of MAC tokens) but is a problem for scope strings?
>>>>>
>>>>> -- Justin
>>>>> ________________________________________
>>>>> From: [email-masked] [[email-masked]] on behalf of
>>>>> John Bradley [[email-masked]]
>>>>> Sent: Sunday, October 16, 2011 8:11 PM
>>>>> To: Eran Hammer-Lahav
>>>>> Cc: OAuth WG
>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
>>>> Proposed Resolutions
>>>>>
>>>>> Restricting it now in the core spec is going to save a lot of headaches
>> later.
>>>>>
>>>>> John B.
>>>>> On 2011-10-16, at 3:54 PM, Eran Hammer-Lahav wrote:
>>>>>
>>>>>> It's an open question for the list.
>>>>>>
>>>>>> EHL
>>>>>>
>>>>>>> From: Julian Reschke [mailto:[email-masked]]
>>>>>>> Sent: Sunday, October 16, 2011 11:00 AM
>>>>>>> To: Mike Jones
>>>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth
>>>>>>> WG; Eran Hammer-Lahav
>>>>>>> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues
>>>>>>> & Proposed Resolutions
>>>>>>>
>>>>>>> On 2011-10-16 18:44, Mike Jones wrote:
>>>>>>>> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide
>>>>>>>> range of
>>>>>>> characters in scope was unintentional. The design was limited to
>>>>>>> allow simple ASCII strings and URIs."
>>>>>>>> ...
>>>>>>>
>>>>>>> I see. Thanks.
>>>>>>>
>>>>>>> Is this going to be clarified in -23?
>>>>>>>
>>>>>>> Best regards, Julian
>>>>>> [email-masked]
>>>>> [email-masked]
>>> [email-masked]
> [email-masked]

[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Dec 2011 18:41:44 +0100

Mike,

I'm not disagreeing with the decision not to allow "\" in the value. 
What I'm disagreeing with is writing the ABNF in a way that will make it 
likely for implementers to special-case OAuth parameters when they 
should not.

The syntax of WWW-Authenticate is defined by HTTP. You *can* profile 
what senders can put into OAuth-specific parameters, but profiling what 
consumers need to parse is dangerous. Don't. Just use the generic grammar.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Mon, 19 Dec 2011 01:01:07 +0000

Hi Julian,

I'm glad to hear that you're not disagreeing with the decision to disallow '\' in certain parameter values.  I think that knowing that brings us much closer to resolution on this issue.

I'm puzzled by your statement "What I'm disagreeing with is writing the ABNF in a way that will make it likely for implementers to special-case OAuth parameters when they should not", however.  At your suggestion, we changed the ABNF to use the standard HTTPbis quoted-string element (and to stop using a special-case ABNFs for these parameters).  Indeed, in this way, the current definition makes it clear that no special-case parameter processing is needed (unlike the previous definitions).

Likewise, I'm puzzled by this related statement of yours:  "The syntax of WWW-Authenticate is defined by HTTP. You *can* profile what senders can put into OAuth-specific parameters, but profiling what consumers need to parse is dangerous. Don't. Just use the generic grammar."  The reason this puzzles me is that I can find no text in the draft profiling what consumers need to parse.  And indeed, the spec *does* use the generic grammar.  The only statements restricting the contents of these fields profile what *producers* may put in them.  These statements are:

"Producers of scope strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing the scope values and %x20 for the delimiter. Producers of error and error_description strings MUST NOT use characters outside the set %x20-21 / %x23-5B / %x5D-7E for representing these values. Producers of error-uri strings MUST NOT use characters outside the set %x21 / %x23-5B / %x5D-7E for representing these values. Furthermore, error-uri strings MUST conform to the URI-Reference syntax. In all these cases, no character quoting will occur, as senders are prohibited from using the %5C ('\') character."

I'm guessing that you're objecting to the last sentence above about no character quoting occurring.  As I see it, that sentence in no way profiles what consumers need to parse; it is making an observation that directly follows from the restrictions upon producers made in the other sentences of the paragraph.

If that is the text that you are objecting to, I can see two potential resolutions to this issue:

1.  Remove the sentence making the observation that no character quoting will occur.  This would be less clear for developers but doing so would not change the meaning of the specification.

2.  Leave the specification as-is.  Since the specification *is* now using the generic grammar (the quoted-string ABNF element), I'm hoping that you will respond agreeing that no problem remains, thus closing this issue.

If you still disagree with (2), Julian, then I'd like to hear working group opinions on which of these potential resolutions members support.

				Thanks all,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, December 12, 2011 9:42 AM
To: Mike Jones
Cc: Mark Nottingham; Stephen Farrell; [email-masked]
Subject: Re: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

Mike,

I'm not disagreeing with the decision not to allow "\" in the value. 
What I'm disagreeing with is writing the ABNF in a way that will make it likely for implementers to special-case OAuth parameters when they should not.

The syntax of WWW-Authenticate is defined by HTTP. You *can* profile what senders can put into OAuth-specific parameters, but profiling what consumers need to parse is dangerous. Don't. Just use the generic grammar.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Dec 2011 10:04:10 +0100

> I'm glad to hear that you're not disagreeing with the decision to disallow '\' in certain parameter values.  I think that knowing that brings us much closer to resolution on this issue.

I think you misunderstood me. I was referring to the value *after* parsing.

> I'm puzzled by your statement "What I'm disagreeing with is writing the ABNF in a way that will make it likely for implementers to special-case OAuth parameters when they should not", however.  At…

The grammar should allow both token and quoted-string. Actually, it 
shouldn't be there at all, as the header field, including it's ABNF, is 
defined in HTTPbis P7.

> Likewise, I'm puzzled by this related statement of yours:  "The syntax of WWW-Authenticate is defined by HTTP. You *can* profile what senders can put into OAuth-specific parameters, but profiling w…

No, see above. The grammar you specified profiles what HTTPbis P7 (and 
RFC2616/7) allow.

> If you still disagree with (2), Julian, then I'd like to hear working group opinions on which of these potential resolutions members support.

I already disagreed with (2), and I gave my reason in the very mail 
you're replying to:

"The syntax of WWW-Authenticate is defined by HTTP. You *can* profile 
what senders can put into OAuth-specific parameters, but profiling what 
consumers need to parse is dangerous. Don't. Just use the generic grammar."

Best regards, Julian