It doesn't feel like we have much interest at this level of interoperability at this point.
EHL > -----Original Message----- > From: Manger, James H [mailto:james.h.man...@team.telstra.com] > Sent: Wednesday, February 03, 2010 5:38 AM > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an > authentication challenge? > > An authentication challenge (WWW-Authenticate header) defined in a spec > for an authentication mechanism should be present, but only with details > specific to that mechanism (eg list of MAC algorithms). > > I think there should be a totally separate WWW-Authenticate header > specifically saying "a delegation flow can be used to access this resource". > It > should include details such as the URI to redirect the user to. > > We really need this if we want to offer a web-style protocol with any > semblance of interoperability. If we omit it because "clients need to know > lots of other API-specific details anyway" then we wont have a path to get > past that limitation in future. > > > -- > James Manger > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Thursday, 28 January 2010 2:12 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: [OAUTH-WG] What are the primary criteria in issuing an > > authentication challenge? > > > > 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
