You are going too far. I meant the people on this list. That's the only group that matters.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Joseph Anthony Pasquale Holsten > Sent: Wednesday, February 03, 2010 6:12 PM > To: OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an > authentication challenge? > > A self fulfilling prophecy. > > Who isn't interested? Client authors or service providers with an incentive to > lock people in? If you work at microsoft or google or yahoo or facebook, you > might consider asking people like ping.fm how much they care about > interoperability. And maybe ask why the people who are supposed to be > consuming these services aren't active on these lists. > -- > j > > On Feb 3, 2010, at 10:46 AM, Eran Hammer-Lahav 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] > > 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
