<hat type='individual'/> If James is interested in this then he can write an Internet-Draft. That's how the IETF works. :)
IMHO such a WWW-Authenticate header might be quite useful, if we think that random entities might try to access a resource that is protected and therefore might need a way to know that they can access the resource via a delegation flow. I'm not sure how likely that is, though. On 2/3/10 9: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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
