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:julian.resc...@gmx.de]
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
