What about the idea that the code is only used as a hand-off mechanism between 
service components (e.g. authorization manager vs, resource access manager).  
In that case, the code would not be usable for anything except to get an access 
token (which still requires client auth).  A code might have a very short 
expiration period with a limited number of uses (e.g. ONE). 

The frames timing issue is interesting, but doesn't it suggest a profile where 
the whole code step is bypassed (e.g. by receiving code and token)?

In general I perceive a code as being relatively simple (e.g. like an 
artifact), short lived, and having almost no rights (except to obtain a an 
access/refresh token).

Phil
phil.h...@oracle.com




On 2011-01-10, at 3:06 PM, Eran Hammer-Lahav wrote:

> 
>> -----Original Message-----
>> From: Brian Eaton [mailto:bea...@google.com]
>> Sent: Monday, January 10, 2011 2:53 PM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Proposal to drop/relocate
>> response_type=code_and_token
>> 
>> On Mon, Jan 10, 2011 at 2:39 PM, Eran Hammer-Lahav
>> <e...@hueniverse.com> wrote:
>>> This explains why you want the code returned in the fragment, but not
>>> why you need both code and token in the same response, as well as any
>>> differences in the token attributes,
>> 
>> The token in the same response is a latency optimization.  It is used to 
>> start
>> rendering iframes and script with interesting content while the code is still
>> being processed.
>> 
>> The code is used as a short-lived token that can be swapped for a long-lived
>> (refresh token).
>> 
>> I would expect the attributes of the refresh token and access tokens to be
>> equivalent.  The primary difference is credential lifetime.
> 
> What about the difference between the two access tokens? The one issued 
> directly and the one via the code? Are those the same? Same scope? Same 
> duration?
> 
> I think this needs to be presented as a separate profile from the user-agent 
> one because it will make it easier to better describe the security 
> consideration of each. Can you offer a 1-2 paragraphs introduction of this 
> profile, maybe as reference to the user-agent and server profiles?
> 
> EHL
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to