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
