This description of realm doesn't really fit into the OAuth model, as OAuth 
challenges are not meant for end users, but for clients. The problem with realm 
is that the existing experience (i.e. Basic) does not match OAuth. Realm does 
not improve interop because we can't figure out how to use it properly. Note 
that 'realm' will still be allowed if someone can figure out a useful way to 
use it. Currently, if you drop 'realm', nothing happens - that's not a good 
sign.

EHL

> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of John Kemp
> Sent: Wednesday, November 24, 2010 8:23 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Fwd: Dropping 'realm' parameter
> 
> Forgot to reply to all...
> 
> ---------- Forwarded message ----------
> From: John Kemp <j...@jkemp.net>
> Date: Wed, Nov 24, 2010 at 11:22 AM
> Subject: Re: [OAUTH-WG] Dropping 'realm' parameter
> To: Eran Hammer-Lahav <e...@hueniverse.com>
> 
> 
> Hi Eran,
> 
> On Wed, Nov 24, 2010 at 2:57 AM, Eran Hammer-Lahav
> <e...@hueniverse.com> wrote:
> > Over the past year we had consensus that the WWW-Authenticate header
> field 'realm' parameter is both poorly defined and useless in OAuth. Realm
> does not provide a useful mechanism for the complexity of OAuth tokens
> and the relationship between the protected resource and authorization
> server.
> >
> > RFC 2617 language is cryptic at best with regard to when 'realm' is 
> > required.
> HTTPbis has an open issue (#177 [1]) for deciding what to do with 'realm'.
> >
> > Since 'realm' does not provide value for OAuth, and is only adding noise
> and confusion, I am removing it from -11. I'm passing the ball to the HTTPbis
> WG to figure out how to deal with it.
> 
> RFC2617 (section 3.2.1 of http://tools.ietf.org/html/rfc2617) says this when
> describing the realm parameter:
> 
>    'A string to be displayed to users so they know which username and
>     password to use. This string should contain at least the name of
>     the host performing the authentication and might additionally
>     indicate the collection of users who might have access. An example
>     might be "registered_us...@gotham.news.com".'
> 
> Is it true then that realm provides no value for OAuth? The information
> contained there could be passed to users in some other way of course, if we
> assume that it will be done so by the authz service, and not by the client...
> But probably it would be nice if there was some interop around the display of
> the name of the service which is asking the user to grant access to protected
> resources.
> 
> Regards,
> 
> - John
> 
> >
> > My schedule has been very busy over the past few months and I was
> unable to complete -11 as planned. I will be publishing -11 this week no
> matter what shape the draft is in as it now includes many normative changes
> collected over the past few months.
> >
> > EHL
> >
> > [1] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/177
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to