So you're assuming that somewhere in the process of token issuance,
the client gets told what algorithm to use and remembers it.
When is this assumption true? I don't see where it happens in the
OAuth delegation procedure (there's no "use this algorithm" field in
responses that issue tokens/secrets). And if Token auth is being used
as a general authentication mechanism, the token secret might just be
something like a password, which the user remembers, not the UA, so
the UA would need to be informed somehow (by the user or the server)
of what signing algorithm to apply.
--Richard
On Jan 28, 2010, at 1:01 AM, Eran Hammer-Lahav wrote:
Not really. The algorithm is part of the token not the challenge.
Either you have a token for this resource or not, and if you have
one, it tells you which algorithm to use. In other words, when you
get a token, it comes with the algorithms it supports (if more than
one) and whatever secrets required executing it. When the client
gets the challenge, it makes no difference what the challenge
includes because the token attributes dictate the rest.
I am assuming there isn't a need for a server to issue a token with
multiple algorithm and then letting individual resources narrow it
down.
EHL
-----Original Message-----
From: Richard L. Barnes [mailto:[email protected]]
Sent: Wednesday, January 27, 2010 8:55 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email protected])
Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an
authentication challenge?
I'm in the "1.5" camp -- "Use Token with HMAC-SHA256". There's no
point to
specifying acceptable tokens, since from the perspective of the
authentication protocol, the token is an opaque string. But it
would be a
good idea to specify what the parameters for the authentication
should be.
The critical parameter is of course the signature algorithm the
server will
accept (I'm OK with just allowing one), but you might also provide
a valid
range for timestamps.
--Richard
On Jan 27, 2010, at 10:11 PM, Eran Hammer-Lahav wrote:
An authentication challenge (to make sure we are all on the same
page) is something the server sends to the client when denying
access
to a protected resource. The challenge can be as simple as "use
Basic", or complex as "use Digest with the following parameters".
OAuth 1.0 doesn't really use a challenge because it was created for
cases where the API calls are preconfigured and hardcoded into the
client. The client should never receive an OAuth challenge the way
the
protocol was originally designed.
In my token authentication draft I tried to propose multiple
mechanisms (not fully baked yet) for issuing a challenge and
allowing
the client to figure out what to do next. Before producing another
draft, it is important to figure out what challenge model we want to
use. Here are the general options I came up with:
1. Basic / OAuth 1.0 style - Simply say "use Token". The client is
left on its own to figure out what to do next.
2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
need a new token go there". It is still not clear how this will help
the client given that getting a token is likely it include many
different options, and to fully address this we need to dig deep
into
discovery which was left out of scope.
3. Token attributes - the server informs the client of the kind of
tokens accepted (based on their cryptographic properties or the
resource-set/realm they are good for). This is just like #2 but with
the ability for the server to support more than one token type per
resource.
Question: Is the ability for a single token-protected resource to
support more than one token type (say Plain+SSL *and* HMAC-256) part
of our requirements? If not, there is no reason at all for the
challenge to include anything other than #1 or #2 (probably
defined as
a future extension).
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
