Re: [OAUTH-WG] Call for Consensus on Document Split
Eran Hammer-Lahav <eran@hueniverse.com> Tue, 16 November 2010 07:19 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 D23303A6B92 for <oauth@core3.amsl.com>; Mon, 15 Nov 2010 23:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 3BaMa+w73fGu for <oauth@core3.amsl.com>; Mon, 15 Nov 2010 23:19:12 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 64D5A3A6C65 for <oauth@ietf.org>; Mon, 15 Nov 2010 23:06:30 -0800 (PST)
Received: (qmail 5934 invoked from network); 16 Nov 2010 07:06:57 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Nov 2010 07:06:56 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 16 Nov 2010 00:06:55 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>, "oauth@ietf.org" <oauth@ietf.org>
Date: Tue, 16 Nov 2010 00:07:00 -0700
Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split
Thread-Index: ActrN3SADdtlmDJIRsyK9ERucPk/wgAuEXqQAAys2oAAACbDIAABCygQBYLpqRAAyVUlUAABAuag
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D470CC507@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AANLkTik30oVX+AevGCZDHajjyrDnEVB=fp6rAdihkPFz@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1127056337B@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D4691FDFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127062CA94@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343D470CBF28@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11276DACEF1@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11276DACEF1@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Call for Consensus on Document Split
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: Tue, 16 Nov 2010 07:19:14 -0000
Bearer token can fail for more than one reason [1]. Clients are allowed to try more than one authentication scheme. So if we allow clients to try more than one OAuth-related scheme, we need to provide an error that identifies which of the schemes provided by the client the server choked on. Or we can only allow a single scheme per request (which is fine by me but somewhat of a departure from HTTP). We can say that an OAuth2 challenge is always included (fail or first time). Do we keep the current error reporting setup? EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Monday, November 15, 2010 10:52 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split > > Eran, > > > If the challenge uses the OAuth2 scheme, and the client tries > > OAuth2-Bearer to authenticate and fails, which scheme should the > > server use in its reply to include an error message? > > OAuth2, OAuth2-Bearer, both? > > "WWW-Authenticate: OAuth2..." should be included in the response when > an auth error occurs. > "WWW-Authenticate: Bearer..." could be included if it might help, but > probably isn't necessary. > > The Bearer scheme by itself probably doesn't have any error that the client > app can correct. Either the opaque bearer token works or you need a new > one. Getting a new one is an OAuth2 flow so the "WWW-Authenticate: > OAuth2..." response is appropriate. > > > > ...to include an error message > > Are you asking about which response header to include auth error info in, as > opposed to which response header to return? > I don't think it makes sense to include error messages that are specific to the > OAuth2 delegation flow in a "WWW-Authenticate: Bearer..." response > header -- just like it wouldn't make sense to include those details in a > "WWW-Authenticate: BASIC..." response header. > > > -- > James Manger > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Manger, James H > > Sent: Thursday, October 14, 2010 10:10 PM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Call for Consensus on Document Split > > > > Eran, > > > > > How would you suggest we define a general purpose www-authenticate > > > header that does not have a matching request header? > > > > Why would that be a problem? > > We define what a "WWW-Authenticate: OAuth2 ..." response header > means, > > but don't define any meaning for a "Authorization: OAuth2 ..." > > request header. > > No other scheme should define a meaning for "Authorization: OAuth2 ...". > > Consequently, the bearer token spec need to choose a different scheme > > name (eg "BEARER" or "TOKEN" or "EXTERNAL") so it can define request & > > response headers. > > > > There is even some precedent for this. draft-broyer-http-cookie-auth > > defines "WWW-Authenticate: COOKIE ...", without any matching request > > header. > > I think there have also been ideas to define something like "WWW- > > Authenticate: TLS ..." to indicate when authentication at a lower > > layer (TLS, > > IPsec) is required. Again there was no matching "Authorization: TLS ..." > > header. > > > > -- > > James Manger > > > > _______________________________________________ > > 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
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Hannes Tschofenig
- [OAUTH-WG] Call for Consensus on Document Split Blaine Cook
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Mike Jones
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Manger, James H
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Eran Hammer-Lahav
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Manger, James H
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Eran Hammer-Lahav
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Brian Eaton
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Marius Scurtescu
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Eran Hammer-Lahav
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Blaine Cook
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Mike Jones
- [OAUTH-WG] So back to use cases? (was RE: Call fo… Freeman, Tim
- Re: [OAUTH-WG] So back to use cases? (was RE: Cal… William Mills
- Re: [OAUTH-WG] So back to use cases? (was RE: Cal… Zeltsan, Zachary (Zachary)
- Re: [OAUTH-WG] So back to use cases? (was RE: Cal… Skylar Woodward
- Re: [OAUTH-WG] So back to use cases? (was RE: Cal… George Fletcher
- Re: [OAUTH-WG] So back to use cases? (was RE: Cal… Hannes Tschofenig
- Re: [OAUTH-WG] So back to use cases? (was RE: Cal… Eve Maler
- Re: [OAUTH-WG] So back to use cases? (was RE: Cal… Zeltsan, Zachary (Zachary)
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Eran Hammer-Lahav
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Manger, James H
- Re: [OAUTH-WG] Call for Consensus on Document Spl… Eran Hammer-Lahav