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
On Mar 26, 2010, at 13:50 PM, Raffi Krikorian wrote:
> 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?)
Wh
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 en
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:ra...@twitter.com]
Sent: Friday
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) th
Why do you need to change the cryptographic properties of a token during
refresh?
EHL
From: Raffi Krikorian [mailto:ra...@twitter.com]
Sent: Friday, March 26, 2010 10:46 AM
To: Torsten Lodderstedt
Cc: Eran Hammer-Lahav; oa...@core3.amsl.com; WG
Subject: Re: [OAUTH-WG] Thinking about our secrets
Hi,
One of the features of the existing OAuth Session Extension is a method
by which a client can request additional authorizations/scopes to those
it's already been granted by the user, and receive a single access token
that embodies the intersection of the approved scopes.
An example use c
>
> 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 thi
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 po
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 agree with that approach, but in this case (where I read that we are
effectively binding tokens to resource access methods) I think we need
some indications during the delegation flow as far as what method the
token is meant to be used with. Possibly a parameter
oauth_token_method when a client r
i concur that it should be the client that decides -- the client knows what
its access requirements are, and can (possibly) be trusted to better make
the choice. of course, it could be possibly be the server's decision
whether to support signatures or not.
by "when the token is issued", do you me
The client can ask for a specific token type, but it is the server's decision.
Either way, that decision should happen when the token is issued, not when
using it to access a resource.
EHL
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Friday,
An interesting question is, who decides what kind of token to issue? 1)
Is it the authorization server because it knows what tokens and
signature algorithms are used by the targeted protected resource? 2) Or
is it the client? I would tend to #2 because I can imagine protected
resources with mu
14 matches
Mail list logo
