That definitely seems like a viable option.
Thanks,
George
On 1/27/10 11:44 PM, Paul C. Bryan wrote:
I'm in the #1 camp too. Is it wrong for me to think that discovering
what type(s) of token are acceptable and how to obtain them should be
the domain of XRD?
Paul
On Wed, 2010-01-27 at 20:11 -0700, 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
