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
