So I think that there are two different issues here in regards to
up/down grading an access token.
1. Token re-use:
Does it make sense to use the same access token for a while as a
bearer and then switch to signing? My personal belief is no.
2. Token exchange:
Can tokens be exchanged without the user having to re-authorize. I
think the answer here is yes.
Given the example of using Bearer+SSL for most transactions and
Signing+HTTP for large file downloads, why can't the client present the
existing Bearer token, refresh_token and maybe something else to the AS
and have the AS send back a new access token + secret to use for the
large file download. All scoping would remain the same.
That way we don't mix token uses, but it's possible to seamlessly
exchange one set for another so the user doesn't have to re-authorize
the tokens.
Thanks,
George
On 3/26/10 2:55 PM, Eran Hammer-Lahav wrote:
It boils down to whatever parameter we add to request a token type
being also available when refreshing a token. I am not sure there is a
real justification for that, but I can go either way.
Anyone else with use cases for this?
EHL
*From:* Raffi Krikorian [mailto:[email protected]]
*Sent:* Friday, March 26, 2010 11:50 AM
*To:* Eran Hammer-Lahav
*Cc:* WG
*Subject:* Re: [OAUTH-WG] Thinking about our secrets for signatures
i believe in normal operation an application will choose once, and be
done -- they will either signal that they want to use tokens under
SSL, or use signatures. the only concern i have is if an application
decides at a later date that they would like to use a signature
mechanism (or visa versa) they they should have an upgrade path
(otherwise they would have to deprecate their tokens and re-authorize
their users?). its a (albeit remote) possibility for web based
operations, and i doubt that we'll ever see a native application doing
that.
On Fri, Mar 26, 2010 at 11:46 AM, Eran Hammer-Lahav
<[email protected] <mailto:[email protected]>> wrote:
Why do you need to change the cryptographic properties of a token
during refresh?
EHL
*From:* Raffi Krikorian [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Friday, March 26, 2010 10:46 AM
*To:* Torsten Lodderstedt
*Cc:* Eran Hammer-Lahav; [email protected]
<mailto:[email protected]>; WG
*Subject:* Re: [OAUTH-WG] Thinking about our secrets for signatures
When a token is issued, that’s when a secret should be
provided if the token is to be used with a signature. The
specific mac algorithm can be provided either with the token
or at the resource endpoint (I don’t have a strong feeling
since we are only talking about symmetric secrets at this point).
I don’t think a token should be “upgraded” from bearer to a
secret-enabled using the refresh process.
I agree. Independent of who actually decides the token type, this
type should be constant in authz and refreshment process.
I think the resource endpoint should advertise the supported
methods (e.g. by way of a WWW-Authenticate-Header-Parameter), the
client can ask the authorization server for a specific token type
incl. signature-method and the authorization server may refuse
such a request if it is unable to provide an appropriate token
type/secret.
sure - so at the first request time, you can request. it is still
possible to upgrade and download the token time during refresh (switch
from non signature to signature based on the refresh)?
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
=
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
