Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments

[Julian Reschke <[e-mail]>]

On 2011-09-26 21:03, Mike Jones wrote:
> ...
> No, b64token isn’t always there; the syntax specifies that either a
> b64token OR one or more auth-params will be present. Yes, that’s intended.

OK then; just checking :-)

 > ...
> This was the working group decision at the interim meeting and is used
> in both the core and bearer drafts. I believe that UTF-8 is a reasonable
> outcome. Unless there’s a clear consensus to change both specifications,
> I believe that this should stay as-is.
> ...

This is a serialization issue. Just because one encoding is right in one 
place doesn't mean it's right somewhere else.

>  > There was an explicit working decision not to include language codes.
>
> I didn't ask for language codes :-)
>
> OK. Others had been asking for them before the interim meeting, hence my
> confusion.
>
>  > This is recorded in the meeting minutes sent to the list by Hannes
>
>  > Tschofenig on 6/3/11. The key part of the minutes is:
>
>  >
>
>  > *** Error Description ***
>
>  >
>
>  > Agreement among the participants that the error codes are meant for
>
>  > consumption by the developer rather than the end user. Hence, language
>
>  > codes are not important nor a human readable version that is supposed
>
>  > to be understood by end users.
>
> In which case I recommend to stick to plain ASCII.
>
> Again, the working group explicitly decided to move from plain ASCII to
> UTF-8.
> ...

I think you need to make a conscious decision about the purpose. If it 
needs to support non-ASCII then using raw UTF-8 in the param may cause 
problems as explained above.

>  ...
>  > The reply syntax is intentionally restricted to simplify
> implementations.
>
> Special-casing the syntax *complicates* implementations. Using common
> constructs allows re-using existing parsing code and thus make things
> easier.
>
> Consider a browser seeing the credentials. It needs to parse the field
> value for multiple challenges, and the only way for this to work is to
> have predictable syntax for parameters.
>
> The philosophy behind the syntax restriction is that interoperability is
> often increased if implementations are prepared to handle all the cases
> that may arise. Having these cases be part of a fixed, enumerated set
> helps achieve this. Parsing is the easy part; understanding and
> meaningfully handling the semantics of the messages is the harder part,
> which is why this restriction intentionally imposes boundaries – so as
> to limit the cases that implementations need to be prepared handle.

First of all: it's pretty clear that you haven't written a conforming 
parser for WWW-Authenticate yet; you may want to look at the test cases 
at <http://greenbytes.de/tech/tc/httpauth/>.

Parsing definitively is *not* simple, and adding special cases over the 
generic syntax will make it even harder.

In particular, using double quotes for something that isn't a quoted 
string is incompatible with the base syntax. (Yes, this is a show-stopper).


>  > 4. IANA Considerations
>
>  >
>
>  > -> If you have a dependency on HTTPbis then you should also add the
>
>  >
>
>  > registration for the authentication scheme as defined in HTTPbis P7.
>
>  >
>
>  > Done
>
> Thanks.
>
> Now that you have switched to HTTPbis you probably can get rid of the
> reference to RFC 2617.
>
> The remaining reference is informational – not normative.
> ...

Yes, but what is it for?

Best regards, Julian