Re: [OAUTH-WG] Call for Consensus on Document Split

"Manger, James H" <James.H.Manger@team.telstra.com> Tue, 16 November 2010 06:51 UTC

Return-Path: <James.H.Manger@team.telstra.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 162673A6C8B for <oauth@core3.amsl.com>; Mon, 15 Nov 2010 22:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
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 YVMlu8EezMBt for <oauth@core3.amsl.com>; Mon, 15 Nov 2010 22:51:38 -0800 (PST)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 775943A6DA8 for <oauth@ietf.org>; Mon, 15 Nov 2010 22:51:26 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.59,204,1288530000"; d="scan'208";a="18936472"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 16 Nov 2010 17:51:38 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6168"; a="13275754"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcavi.tcif.telstra.com.au with ESMTP; 16 Nov 2010 17:51:38 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 16 Nov 2010 17:51:37 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Tue, 16 Nov 2010 17:51:36 +1100
Thread-Topic: [OAUTH-WG] Call for Consensus on Document Split
Thread-Index: ActrN3SADdtlmDJIRsyK9ERucPk/wgAuEXqQAAys2oAAACbDIAABCygQBYLpqRAAyVUlUA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E11276DACEF1@WSMSG3153V.srv.dir.telstra.com>
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>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D470CBF28@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
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 06:51:42 -0000

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