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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
