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

[Julian Reschke <[e-mail]>]

On 2011-12-19 02:01, Mike Jones wrote:
> 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 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 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).

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

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

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

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