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

From: Brian Eaton <[email-masked]>
Date: Sat, 10 Jul 2010 23:55:46 -0700

On Sun, Jun 27, 2010 at 6:51 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> 1. Leave it as required under the definition of RFC 2617 (i.e. provide no
> help, developers will need to ready 2617 and figure out what to do with it).
>
> 2. Update 2617 to remove the requirement – this is not going to be easy or
> possible to predict success.
>
> 3. Provide specific guidance as to what to do with the realm parameter.
>
> 4. Something else.

Let's do something else.

We've made great progress on simplifying the spec and unifying the
different formats to minimize the number of parsers and serializers
that are needed.  The www-authenticate header is one of the bits of
nastiness left.

Let's use a format like this:

WWW-Authenticate: OAuth2 base64(<json>)

Or even just:

WWW-Authenticate: OAuth2

Seriously.

There is some precedent for this.  The Negotiate and NTLM schemes
ditched the name="value" syntax, and they are widely implemented.
This demonstrates two things:
1) dropping the name="value" syntax won't break the internet, because
widely deployed schemes have already done it.
2) "realm" is not necessary in order to have a successful
authentication protocol.

As far as I can tell, there is no good reason for RFC 2617 to specify
the syntax it does.  It's convenient for digest auth, and kind of a
pain everywhere else.

So let's just drop it.

Cheers,
Brian

---

From: Robert Sayre <[email-masked]>
Date: Sun, 11 Jul 2010 00:11:43 -0700

> WWW-Authenticate: OAuth2 base64(<json>)

Looks good. Doesn't matter which the WG picks.

> widely deployed schemes have already done it.

Fully agree.

> 2) "realm" is not necessary in order to have a successful

Indeed. So far, it looks like "realm" is necessary to have an
unsuccessful authentication protocol.

> the syntax it does.

RFC 2617 adopts constraints that predate widespread Unicode adoption.

> It's convenient for digest auth, and kind of a
> pain everywhere else.
>

It's not convenient for Digest, and Digest doesn't work anyway.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 11 Jul 2010 06:01:43 -0700

You mean the syntax used by most HTTP headers? There is clearly a need for adding extensions.

EHL

---

From: "Manger, James H" <[email-masked]>
Date: Sun, 11 Jul 2010 23:12:09 +1000

Brian,

> Seriously.

I seriously hope not.
It gives no chance for a client to work with a service without being pre-configured with a whole lot of service-specific knowledge -- in addition to an app-id/password.

I don't think a realm parameter adds much value to a "WWW-Auth.: OAuth2" header, other than complying with RFC2617. The header does need to provide an end-user authorization endpoint. Ideally, that one URI would be sufficient for the protocol to succeed (though currently you need to separately provide a token endpoint as well).

--
James Manger

---

From: Eve Maler <[email-masked]>
Date: Sun, 11 Jul 2010 06:46:25 -0700

+1. James states two important requirements (don't stand in the way of dynamic config, provide end-user authz endpoint at a minimum) we need to meet, whatever we pick.

	Eve

On 11 Jul 2010, at 6:12 AM, Manger, James H wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 11 Jul 2010 12:27:58 -0700

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

- Human-friendly - I think being able to look at the header and immediately see what it means is useful. 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.

On top of that, I am still not sure about the best way to accommodate both a signed and unsigned requests, but the idea of a two separately defined schemes isn't appealing (not having two, just defining them in two different places).

As for the scheme name, I have changed my mind about using 'Token' and am now proposing 'OAuth'. The reason for that is that the current scheme extensibility is directly linked to the OAuth protocol (for example, 'scope' parameter). This voids my claim that it is a completely orthogonal scheme. Because we are not using the 'oauth_' prefix, telling the difference is trivial and there is no need to include a version parameter (since 2.0 is marking 1.0 as obsolete).

So if you can suggest a scheme syntax that accommodates the above, and is based on JSON, I'm very supportive.

EHL

On 7/10/10 11:55 PM, "Brian Eaton" <[email-masked]> wrote:

On Sun, Jun 27, 2010 at 6:51 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> 2. Update 2617 to remove the requirement - this is not going to be easy or

Let's do something else.

Or even just:

WWW-Authenticate: OAuth2

Seriously.

So let's just drop it.

Cheers,
Brian

---

From: Robert Sayre <[email-masked]>
Date: Sun, 11 Jul 2010 15:32:01 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 11 Jul 2010 20:29:20 -0700

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

>> - Extensible  we removed the few discovery parameters from the core spec

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

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.

> so it's probably best to avoid it, because most of the bits will be

Works for me.

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

> 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

---

From: "William Mills" <[email-masked]>
Date: Sun, 11 Jul 2010 22:53:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Eaton
> Sent: Saturday, July 10, 2010 11:56 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] What to do about 'realm'
> 
> > 1. Leave it as required under the definition of RFC 2617 
> (i.e. provide 
> > no help, developers will need to ready 2617 and figure out 
> what to do with it).
> >
> > 2. Update 2617 to remove the requirement - this is not going to be 
> > easy or possible to predict success.
> >
> We've made great progress on simplifying the spec and 
> unifying the different formats to minimize the number of 
> parsers and serializers that are needed.  The 
> www-authenticate header is one of the bits of nastiness left.
> 

This will work for me in the SASL stuff for discovery information.

JSON as a name/value construct works as well as anythign else.

> WWW-Authenticate: OAuth2

This won't really, and I'll have to stuff the discovery information
somwehre else.

I don't care what the real specifics of this are as long asn it's
extensible.
> 
> Seriously.
> 
> There is some precedent for this.  The Negotiate and NTLM 
> schemes ditched the name="value" syntax, and they are widely 
> implemented.
> 1) dropping the name="value" syntax won't break the internet, 
> because widely deployed schemes have already done it.
> As far as I can tell, there is no good reason for RFC 2617 to 
> specify the syntax it does.  It's convenient for digest auth, 
> and kind of a pain everywhere else.
> 
> So let's just drop it.
> 
> Cheers,
> Brian

---

From: Yaron Goland <[email-masked]>
Date: Tue, 13 Jul 2010 16:46:40 +0000

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.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, July 11, 2010 8:29 PM
> To: Robert Sayre
> Cc: OAuth WG
> > On Sun, Jul 11, 2010 at 12:27 PM, Eran Hammer-Lahav
> > <[email-masked]>
> > wrote:
> >> - 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.
> >
> 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.
> >
> 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.
> >
> 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.
> 
> sure what a browser will do when you try to set an HTTP header with non-
> ascii characters.
> 
> 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
> 
> >

---

From: Robert Sayre <[email-masked]>
Date: Tue, 13 Jul 2010 16:00:41 -0700

On Tue, Jul 13, 2010 at 9:46 AM, Yaron Goland <[email-masked]> wrote:
> 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.

I don't think that is correct. The definition of the TEXT rule in
section 2.2 allows most octets. It also references RFC 2047, but I
don't think many implementations actually support that RFC.

-- 

Robert Sayre

---

From: Yaron Goland <[email-masked]>
Date: Fri, 16 Jul 2010 18:21:02 +0000

That's my point. The spec says " Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]." But since RFC 2047 is a dead letter as a practical matter the only safe way to move non-ASCII content in a HTTP header is to use some form of ASCII encoding. So, for example, we couldn't use UTF-16 because it produces characters that aren't safe in ASCII.

> From: Robert Sayre [mailto:[email-masked]]
> Sent: Tuesday, July 13, 2010 4:01 PM
> To: Yaron Goland
> Cc: Eran Hammer-Lahav; OAuth WG
> > 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.
> 
> I don't think that is correct. The definition of the TEXT rule in section 2.2
> allows most octets. It also references RFC 2047, but I don't think many
> implementations actually support that RFC.
> 
> 
> --
> 
> Robert Sayre
>

---

From: Brian Eaton <[email-masked]>
Date: Fri, 16 Jul 2010 13:16:22 -0700

> That's my point. The spec says " Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]." But since RFC 2047…

Of course, JSON does support unicode escapes, which will work just
fine in an HTTP header.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jul 2010 14:26:30 -0700

If you specify it. It is supported but not required. 

EHL