Au contraire (speaking only for myself). On Wednesday, February 3, 2010, Eran Hammer-Lahav <[email protected]> wrote: > 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:[email protected]] >> Sent: Wednesday, February 03, 2010 5:38 AM >> To: Eran Hammer-Lahav; OAuth WG ([email protected]) >> 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: [email protected] [mailto:[email protected]] On Behalf >> > Of Eran Hammer-Lahav >> > Sent: Thursday, 28 January 2010 2:12 PM >> > To: OAuth WG ([email protected]) >> > 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 >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > ht <https://www.ietf.org/mailman/listinfo/oauth>
-- -- John Panzer / Google [email protected] / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
