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

George Fletcher <gffletch@aol.com> Tue, 08 June 2010 15:41 UTC

Return-Path: <gffletch@aol.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 693BE3A697D for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 08:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.369
X-Spam-Level:
X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, 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 wVUAfLsvm5Pf for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 08:41:56 -0700 (PDT)
Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by core3.amsl.com (Postfix) with ESMTP id 648EF3A6917 for <oauth@ietf.org>; Tue, 8 Jun 2010 08:41:56 -0700 (PDT)
Received: from mtaout-mb01.r1000.mx.aol.com (mtaout-mb01.r1000.mx.aol.com [172.29.41.65]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o58FelrT001707; Tue, 8 Jun 2010 11:41:07 -0400
Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id AC709E0000BF; Tue, 8 Jun 2010 11:41:06 -0400 (EDT)
Message-ID: <4C0E6482.2080109@aol.com>
Date: Tue, 08 Jun 2010 11:40:50 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Brian Eaton <beaton@google.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> <6E69B6CE-FACA-4428-B6BA-48CF5B1E15C9@facebook.com> <4C0E50E7.5040909@aol.com> <AANLkTinnHC3qAl6DEs2Myk-Kp9823T0HsS97n4FLCohr@mail.gmail.com>
In-Reply-To: <AANLkTinnHC3qAl6DEs2Myk-Kp9823T0HsS97n4FLCohr@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020500090804040200000900"
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:443297376:93952408
X-AOL-SCOLL-URL_COUNT: 0
x-aol-sid: 3039ac1d29414c0e6492666e
X-AOL-IP: 10.181.183.108
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 15:41:57 -0000

Here is where I see the differences...

#2 forces "person B" to go through an authentication event at 
photos.example.com

while #3 allows the client "person B" is using to get the access token 
at time of authentication to the client.

So, for #2 "person B" will likely have to do 2 authentication events (1 
to the client and 1 to photos.example.com). While with #3, "person B" 
only has to do 1 authentication event (to the client).

Thanks,
George

On 6/8/10 11:32 AM, Brian Eaton wrote:
> On Tue, Jun 8, 2010 at 7:17 AM, George Fletcher<gffletch@aol.com>  >
> 2. Use OpenID and force Person B to "sign in" to photos.example.com
>    
>> (effectively establishing a relationship with photos.example.com that they
>> might not want)
>>
>> 3. Have photos.example.com be able to accept a token from person B's
>> authorization service saying this is person B when accessing the protected
>> resource.
>>      
> These two options seem equivalent to me.
>
> They certainly bring up the same user experience challenges.
>
>