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

[Mike Jones <[e-mail]>]

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:[e-mail]] 
Sent: Monday, December 12, 2011 9:42 AM
To: Mike Jones
Cc: Mark Nottingham; Stephen Farrell; [e-mail]
Subject: Re: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

On 2011-12-12 18:28, Mike Jones wrote:
> 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".

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