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 [email protected] On 2011-01-10, at 3:06 PM, Eran Hammer-Lahav wrote: > >> -----Original Message----- >> From: Brian Eaton [mailto:[email protected]] >> 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 >> <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
