[OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

[Julian Reschke <[e-mail]>]

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

The text change was caused by both the early interactions with OAuth 
(mainly thanks to James), and the fact that we see that was defined for 
Realm isn't implemented in practice 
(<http://greenbytes.de/tech/tc/httpauth/#simplebasictok>).

(Note: we had a working feedback loop between WG's here; that's a feature)

If you disagree with what HTTPbis P7 now says than you really really 
ought to come over to the HTTPbis WG's mailing list (*) and argue your 
point.

(*) Similarly to how I'm arguing my point over here.

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

Yes, there is. As the test case above shows, all UA recipients accept 
both forms; none of them rejects the token syntax. This is a problem as 
people frequently do not code against specs but just do "what works".

I'm pretty sure that changing a UA's behavior here would cause breakage 
in practice.

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

3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined 
in HTTPbis. Just state the names of the parameters, their syntax *after* 
parsing and their semantics.

Best regards, Julian