Re: [OAUTH-WG] What to do about 'realm'
Eran Hammer-Lahav <eran@hueniverse.com> Sun, 11 July 2010 19:28 UTC
Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C283A69FD for <oauth@core3.amsl.com>; Sun, 11 Jul 2010 12:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level:
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QcyDD4IgZ1v for <oauth@core3.amsl.com>; Sun, 11 Jul 2010 12:28:16 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 931EF3A67FC for <oauth@ietf.org>; Sun, 11 Jul 2010 12:28:16 -0700 (PDT)
Received: (qmail 4099 invoked from network); 11 Jul 2010 19:28:22 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jul 2010 19:28:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 11 Jul 2010 12:28:01 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Eaton <beaton@google.com>
Date: Sun, 11 Jul 2010 12:27:58 -0700
Thread-Topic: [OAUTH-WG] What to do about 'realm'
Thread-Index: Acsgxhn8bBr78OcyQIyiiGuV6BDzdQAaREVM
Message-ID: <C85F694F.36FF1%eran@hueniverse.com>
In-Reply-To: <AANLkTikLogvJAhE9LF60MDyEiqvpDM8WD8tSUr4fZLjP@mail.gmail.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C85F694F36FF1eranhueniversecom_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] What to do about 'realm'
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Jul 2010 19:28:23 -0000
[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" <beaton@google.com> wrote: On Sun, Jun 27, 2010 at 6:51 PM, Eran Hammer-Lahav <eran@hueniverse.com> 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
- Re: [OAUTH-WG] What to do about 'realm' Eran Hammer-Lahav
- Re: [OAUTH-WG] What to do about 'realm' Dick Hardt
- [OAUTH-WG] What to do about 'realm' Eran Hammer-Lahav
- Re: [OAUTH-WG] What to do about 'realm' Lukas Rosenstock
- Re: [OAUTH-WG] What to do about 'realm' Pid
- Re: [OAUTH-WG] What to do about 'realm' William Mills
- Re: [OAUTH-WG] What to do about 'realm' Torsten Lodderstedt
- Re: [OAUTH-WG] What to do about 'realm' Yaron Goland
- Re: [OAUTH-WG] What to do about 'realm' Brian Eaton
- Re: [OAUTH-WG] What to do about 'realm' Robert Sayre
- Re: [OAUTH-WG] What to do about 'realm' Eran Hammer-Lahav
- Re: [OAUTH-WG] What to do about 'realm' Manger, James H
- Re: [OAUTH-WG] What to do about 'realm' Eve Maler
- Re: [OAUTH-WG] What to do about 'realm' Robert Sayre
- Re: [OAUTH-WG] What to do about 'realm' Eran Hammer-Lahav
- Re: [OAUTH-WG] What to do about 'realm' William Mills
- Re: [OAUTH-WG] What to do about 'realm' Yaron Goland
- Re: [OAUTH-WG] What to do about 'realm' Robert Sayre
- Re: [OAUTH-WG] What to do about 'realm' Yaron Goland
- Re: [OAUTH-WG] What to do about 'realm' Brian Eaton
- Re: [OAUTH-WG] What to do about 'realm' Eran Hammer-Lahav