Just to be clear, I was referring to the case where a client can figure out how to obtain authorization and then authenticate without any pre-configuration. This means giving a discovery flow for each type of authorization option (desktop, mobile, web, etc.) with all the parameters needed for each (pop-up size, redirection URIs, extension parameters, digital TOS).
EHL > -----Original Message----- > From: John Panzer [mailto:[email protected]] > Sent: Wednesday, February 03, 2010 9:23 PM > To: Eran Hammer-Lahav > Cc: Manger, James H; OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an > authentication challenge? > > 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
