Re: [OAUTH-WG] Partially standardized format for access tokens?

Luke Shepard <lshepard@facebook.com> Tue, 08 June 2010 13:59 UTC

Return-Path: <lshepard@facebook.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 66AB528C1D0 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 06:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.128
X-Spam-Level:
X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1]
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 w491gM2jIk+H for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 06:59:17 -0700 (PDT)
Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 66A8F28C1AB for <oauth@ietf.org>; Tue, 8 Jun 2010 06:59:17 -0700 (PDT)
Received: from mail.thefacebook.com ([192.168.18.212]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o58DwjLm019047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jun 2010 06:58:49 -0700
Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Tue, 8 Jun 2010 06:58:25 -0700
Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Tue, 8 Jun 2010 06:58:09 -0700
From: Luke Shepard <lshepard@facebook.com>
To: John Kemp <john@jkemp.net>
Date: Tue, 08 Jun 2010 06:58:07 -0700
Thread-Topic: [OAUTH-WG] Partially standardized format for access tokens?
Thread-Index: AcsHEqAoUJ4Q5/txRsClQjeZil3+sA==
Message-ID: <6E69B6CE-FACA-4428-B6BA-48CF5B1E15C9@facebook.com>
References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <AANLkTilj0xG6SjHrzkd9Ca-N67J7IlsTNAOkyFdjQ62I@mail.gmail.com> <ED86A2AA-56D5-4DC6-B896-48A850EED3B2@facebook.com> <4C0930B2.80802@aol.com> <AANLkTimupEDpBUjg4iwwhPQ41ZKcryMcpVjJumXNIjP0@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> <255B9BB34FB7D647A506DC292726F6E11263EBF638@WSMSG3153V.srv.dir.telstra.com> <50227268-61DB-401E-A2AA-F8A984C1B6B3@jkemp.net>
In-Reply-To: <50227268-61DB-401E-A2AA-F8A984C1B6B3@jkemp.net>
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
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-08_05:2010-02-06, 2010-06-08, 2010-06-08 signatures=0
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Partially standardized format for access tokens?
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, 08 Jun 2010 13:59:18 -0000

>> Client simplicity (code and mental model).
> 
> I think the difference in simplicity between one parameter and two is not such that it requires munging the two together.
> 
> The token_string and the token_format are two different parts of the token.

If you look through my emails, I provided code samples to illustrate that two parameters is in fact more complex than one. Much of the simplicity of OAuth 2.0 is achieved by unifying myriad parameters into a single access token. Much of that is lost by splitting it apart again.

We can't even agree what we want or how to split it - some want origin, some want format, still others probably want something else. No, the whole point is it's up to the provider and the resource to unify them and it's opaque to the client.

Again: can you provide a specific, real-world example where this is necessary? I'd rather not deal in hypotheticals. I've already answered the case of a hypothetical endpoint that accepts both SAML and JSON-encoded tokens.