I'm in the #1 camp from a simplicity standpoint. Even if you're able to discover an API endpoint (ala #2), you're still going to need to know more than just how to authorize in order to make successful API requests. This isn't to say that we won't get there, but I think we're still a ways off.
--David On Wed, Jan 27, 2010 at 7:11 PM, Eran Hammer-Lahav <[email protected]>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
