Thanks, that's a good explanation.
________________________________
From: Eran Hammer <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Wednesday, January 25, 2012 10:12 AM
Subject: [OAUTH-WG] WWW-Authenticate Header (Bearer etc.)
People seems confused about the issue raised by Julian. It is pretty simple.
The HTTP WWW-Authenticate header definition allows each header parameter to
have a quoted string or token value. Token values are very restrictive and not
suitable for scope (no spaces, etc.). Quoted strings allow a wider set of
characters at the cost of requiring escaping for " and \.
The WG decided that in order to avoid escaping, we will restrict scope values
to only those characters legal in quotes string without escaping. This change
was made in –23.
The issue here is different.
The WWW-Authenticate header isn't OAuth-specific and it allows the server to
declare more than one scheme. For example:
WWW-Authenticate: Bearer realm="xyz", Basic realm="123"
This is how HTTP works and this WG doesn't get to change it. The problem is
that the bearer token specification is changing the *general* definition of
the WWW-Authenticate header to only use quoted strings and not tokens. This is
wrong.
It is true that a *generic* parser will be able to parse a bearer token header
without any issues. But a parser written specifically for the bearer token use
case will most likely fail when parsing the WWW-Authenticate header with other
schemes.
OAuth must not define its own WWW-Authenticate handing logic. It should opt
into the HTTP framework without any modifications. It is perfectly fine to
restrict values and by doing so, we made servers simpler by not having to ever
encode scopes but we cannot try to simplify client code by "profiling" HTTP.
My view has not changed and trying to portray it in this fashion shows
ignorance of the issue. I supported restricting the character set of scopes. I
am against changing the HTTP definition of WWW-Authenticate.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
