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

[Mike Jones <[e-mail]>]

I'll note that in some profiles, the Bearer challenge may be the only one that the application may legally use.  In that case, there's no need to be able parse other challenges that the application can't fulfill in the first place.  The application would fail if an unsupported challenge type was used in either case.

As editor, I'll note that it doesn't seem like this discussion is moving the process forward anymore.  I believe that we've sufficiently clarified that you hold a different position than the working group consensus (which I realize is your right to do).  I also believe that the issues have been sufficiently well discussed on the list for all parties to be well informed.

Therefore, it seems that my earlier observation still holds:  In the New Year, the chairs and area directors (and possibly the OAuth design committee) will need to decide how to proceed on this issue.  It would be good to see the spec finished shortly.

				All the best,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[e-mail]] 
Sent: Sunday, January 01, 2012 11:15 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?

On 2011-12-31 20:40, Mike Jones wrote:
> Maybe I misunderstood your position.  If you agree that '\' may not occur in the INPUT string, then that issue can be closed.  That was the working group consensus position, per the cited e-mails.  I thought that you were arguing that syntax restrictions on the parameters should only be placed upon the OUTPUT string - which forces all implementations to support unnecessary encodings like "\a\b\c" for "abc".  Please let me know whether you're fine with the working group prohibiting the use of '\' in the input string as the spec presently currently does.

I'm not ok with that; because it's totally besides the point.

A recipient of WWW-Authenticate needs to use a proper parser for that header field. And if you use a proper parser, it doesn't matter.

I'm not saying anybody should send something like that. What I'm saying is that you shouldn't create an illusion that a recipient doesn't need to deal with it.

A recipient that can't handle quoted-string syntax in auth-params is broken. A recipient that can't handle token syntax in auth-params is broken as well.

Finally, please re-read what I said: the syntax of the challenge is defined by HTTP. The bearer spec can't change the parsing rules, because you need a generic parser to properly handle header fields containing multiple challenges. Once that generic parser has done it's job, it should not matter anymore whether a value used the token syntax or the quoted-string syntax, and also it shouldn't matter anymore where unescaping has taken place or not.

What you're trying to do is comparable with defining an XML vocabulary where you profile how an attribute is serialized (' vs  ", character encoding, escaping). Don't.

Best regards, Julian