Re: [OAUTH-WG] What to do about 'realm'

[Eran Hammer-Lahav <[e-mail]>]

On 7/11/10 3:32 PM, "Robert Sayre" <[e-mail]> wrote:

> On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav <[e-mail]>
> 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.

Yes. We need a format that can be extended. Of course, using JSON means much
richer extensibility which needs some adjustment in the registry (maybe only
require registration for top level object names?).

>> - 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.

I think being able to curl a site and work your way manually is useful and
something that was a stated goal when we started collecting 2.0
requirements. This was one of the reasons why the bearer token approach was
so attractive to so many people.

>> 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.

Works for me.

> 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]

I am not worried about client requests because there is less to debug on
that side (most issues are when the client is trying to debug on its side
and can easily add helpful information locally). I want to make sure that
the server response using the WWW-Authenticate header is plain-text and not
some encoded blob.

However, we still need to worry about HTTP header restrictions and I am not
sure what a browser will do when you try to set an HTTP header with
non-ascii characters.

> 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.

It would be great to avoid having to use stuff like
draft-reschke-rfc2231-in-http, but that seems to be the current solution.

EHL

> 
> [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."
>