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

As defined in section 4.2 of RFC 2616 the only characters legally allowed in a HTTP header are a fairly small subset of ASCII. So if we want to shove in Unicode characters they will have to be encoded in a form that only uses characters that are legal in the subset of ASCII supported by HTTP.

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, July 11, 2010 8:29 PM
> To: Robert Sayre
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] What to do about 'realm'
> 
> 
> 
> 
> On 7/11/10 3:32 PM, "Robert Sayre" <sayrer@gmail.com> wrote:
> 
> > On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav
> > <eran@hueniverse.com>
> > 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."
> >
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth