I remember one scenario in the discussion "why signatures" in the
context of pro/con HTTPS.
In this scenario, "normal" requests would be performed over HTTPS with
bearer tokens, which is easy to implement and secure. But some requests
(e.g. download large video files), where the penalty for encrypting the
whole traffic would be to high, would be performed over a HTTP
connection (probably with a signed request).
Would that be a conclusive example for different cryptographical
properties for access tokens based on the same refresh token?
regards,
Torsten.
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
