On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav <[email protected]> wrote: > [this has noting to do with realm] > > Any solution should be: > > - Extensible – we removed the few discovery parameters from the core spec > due to lack of maturity and consensus. However, we clearly have enough > strong interest in reintroducing them as extensions. The WWW-Authenticate > header is the natural place to include them.
This is true. I thought it obvious that implementations would be required to deal with text after the "OAuth2" string. > > - Human-friendly – I think being able to look at the header and immediately > see what it means is useful. I'm not sure this is valuable, but it is possible to accomodate the concern anyway. I use a protocol analyzer, like WireShark. > Is there a JSON profile suitable for inclusion > in HTTP headers? I would like to avoid BASE64 when a person is likely to > take a look at the header. Otherwise debugging and command line interaction > become impractical. The WG could specify that all control characters and non-ASCII text within the JSON text be escaped. base64 adds overhead to the endeavor, so it's probably best to avoid it, because most of the bits will be ASCII anyway. If browser clients need to set headers in the same manner, this could be more inconvenient, because the JSON serializers shipping in browsers today don't support requiring that the produced text be escaped. This can be done as a follow-up pass, though. [0] Using a JSON serialization neatly sidesteps several i18n issues. If you go with traditional HTTP header syntax, you'll need to deal with that some other way. btw, it just so happens that internationalization of Realm values is a bug in most RFC2617 implemenations. [0] (I happen to be on the ECMAScript committee, and I can be blamed for Mozilla's native JSON object. It would be technically easy to add a JSON.stringifyAsASCII() method, and I think the committee will go for it.) -- Robert Sayre "I would have written a shorter letter, but I did not have the time." _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
