Please consider my position retracted. -- j On Feb 3, 2010, at 8:16 PM, Eran Hammer-Lahav wrote:
> You are going too far. I meant the people on this list. That's the only group > that matters. > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Joseph Anthony Pasquale Holsten >> Sent: Wednesday, February 03, 2010 6:12 PM >> To: OAuth WG (oauth@ietf.org) >> 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: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 >> >> _______________________________________________ >> 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
