Re: [OAUTH-WG] OAuth2 scheme

"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 08 April 2011 07:15 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 B98053A6A4F for <oauth@core3.amsl.com>; Fri, 8 Apr 2011 00:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.839
X-Spam-Level:
X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, 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 VzCidEbO2dV3 for <oauth@core3.amsl.com>; Fri, 8 Apr 2011 00:15:46 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id DF5753A688F for <oauth@ietf.org>; Fri, 8 Apr 2011 00:15:45 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.63,322,1299416400"; d="scan'208,217"; a="30252892"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 08 Apr 2011 17:17:30 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6309"; a="23241812"
Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 08 Apr 2011 17:17:30 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 8 Apr 2011 17:17:29 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>, OAuth WG <oauth@ietf.org>
Date: Fri, 08 Apr 2011 17:17:28 +1000
Thread-Topic: OAuth2 scheme
Thread-Index: Acv0szxJR54h3FRORpezZ9L8nUeh+gAxRy2gAAXVW8AACmyNEA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E11281D308B0@WSMSG3153V.srv.dir.telstra.com>
References: <90C41DD21FB7C64BB94121FBBC2E7234465664E11D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11281CAB8DB@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E7234465664E3B1@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234465664E3B1@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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11281D308B0WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth2 scheme
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: Fri, 08 Apr 2011 07:15:50 -0000

[Sorry, I didn't see this email before I sent my last one]



> Chairs - I would like to ask that you declare all discovery requirements and use cases out of scope for v2 and the working group at this point.

>

> ---

>

> As for the error code registry and the request Mike posted, I do not think your use case has much to do with the goal Mike has with his registry proposal. Mike's proposal is for v2 to define an error registry for use with an error attribute across different HTTP schemes such as Bearer and MAC, and for that to make sense, we need to define an OAuth2 scheme that *replaces* the Bearer and MAC schemes - something you agree we should not do.





An error code is part of discovery - it lets a client app "discover" what it needs to do next to gain access.



We can have separate discovery of fairly static server capabilities and endpoints and call that out of scope for v2.

However, we still need dynamic discovery of which OAuth2 flow a client should do after a particular HTTP resource request fails. This is related to error codes so needs to be as in-scope as error codes are. Indicating which OAuth2 flow to perform should be OAuth2-specific, not kludged onto every (independent) authentication scheme.



P.S. I still absolutely agree that we should NOT define one OAuth2 scheme that replaces Bearer and MAC.



--

James Manger