Re: [OAUTH-WG] OAuth2 WWW-Authenticate scheme

WFM. I'll apply this to -11 and publish it shortly. This was the last open issue I had with the split. Looks like OAuth2 has consensus as the auth scheme name (I find it gross but lost all interest in any further discussions).

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Manger, James H
> Sent: Tuesday, November 16, 2010 4:13 PM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth2 WWW-Authenticate scheme
> 
> Eran,
> 
> > Clients are allowed to try more than one authentication scheme.
> 
> I don't think so -- at least not in a single request.
> HTTP certainly allows a server to advertise multiple schemes in a *response*
> (via "WWW-Authenticate" headers). This is widely used.
> However, HTTP does not allow multiple schemes in a request (ie it does not
> allow multiple "Authorization" headers).
> The current httpbis draft says (draft-ietf-httpbis-p7-auth-12, section 2):
>   "The user agent MUST choose to use *one* of the challenges
>    with the strongest auth-scheme it understands"
> 
> 
> > Or we can only allow a single scheme per request (which is fine by me
> > but somewhat of a departure from HTTP).
> 
> I don't think this is a departure.
> I can't think of any current systems that use multiple HTTP auth schemes in a
> single request.
> 
> 
> > We can say that an OAuth2 challenge is always included (fail or first time).
> > Do we keep the current error reporting setup?
> 
> It is clear (in my mind) that a server should use a "WWW-Authenticate:
> OAuth2..."
> response header to say to the client:
>   "Hey, you can get access to this resource (or better access)
>    if you first run an OAuth flow: with these endpoints & parameters"
> 
> But there are a number of OAuth flows:
> * user delegation
> * swapping client credentials for a token (or swapping an assertion for a
> token)
> * refreshing an existing token/delegation
> 
> The server needs to give the client enough information for it to know what it
> can do next, eg which OAuth flow to perform.
> A good approach would be for the "WWW-Authenticate: OAuth2..."
> response to explicitly indicate which flows are possible *at this point*.
> If a "WWW-Authenticate: OAuth2..." response includes a refresh=<uri>
> parameter, for instance, then the client knows they can refresh their existing
> token.
> If the "WWW-Authenticate: OAuth2..." response includes a user=<uri>
> parameter, but no refresh parameter, then the client knows they can run a
> user-delegation flow, but they cannot refresh their existing token.
> 
> 
> --
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth