IETF Logo Mail Archive

[OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 10 January 2011 22:15 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 026A43A63CA for <oauth@core3.amsl.com>; Mon, 10 Jan 2011 14:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level:
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 gKsKQwzhXONr for <oauth@core3.amsl.com>; Mon, 10 Jan 2011 14:15:39 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1884F3A672E for <oauth@ietf.org>; Mon, 10 Jan 2011 14:15:39 -0800 (PST)
Received: (qmail 29246 invoked from network); 10 Jan 2011 22:17:53 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jan 2011 22:17:53 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 Jan 2011 15:17:50 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Date: Mon, 10 Jan 2011 15:17:47 -0700
Thread-Topic: Proposal to drop/relocate response_type=code_and_token
Thread-Index: AcuxEC5p0+ab5JWUR76Rx/1QINxnNA==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB750CP3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token
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: Mon, 10 Jan 2011 22:15:44 -0000

I'm having some doubts about the code_and_token response type.

The reason why we have both token and code response type is that each has specific security characteristics. However, the mix raises questions about token scope and other properties.

For example, -11 states that the scope in the token request can only be equal or less than the scope requested in the authorization request. This means the token issued in the redirection (which is considered less trusted due to lack of client authentication) can have a greater scope than that issued using the code, but not the other way around which actually makes more sense.

If there is no difference in the properties of the two tokens issued (one directly in the redirection and another via the code), why do we need this complexity? Why can't the client just pass along the same token to the server? If there is a difference, it can only be that the token obtained using the code is "more powerful".

Adding two scope parameter to the authorization request seems complex, but so other ideas on asking for one authorization with two different tokens issued as a result.

Any thoughts?

It would be most useful if someone who deployed this (or is planning to) can explain how they are using it. Mostly if they are issuing tokens with the same or different security properties.

In -12, I am moving back to the -05 specification structure of profiles (flows). This means this code_and_token hybrid needs to be explained beyond just the definition of the extra parameter and response format. But I don't know how to describe such a profile or what the security considerations for such a hybrid look like.

If we can't nail this down quickly, I propose we move this out of the specification and let someone who has implementation experience define it as an extension.

EHL

v2.23.0 | Report a Bug | By Email