> It is important to make sure a server can reply to a protected resource request > with more than one auth header to indicate that both usernames and tokens are welcomed. > This is why we cannot use Basic or Digest to send token credentials, > even if the two protocols provide all the necessary technical coverage. I think that reasoning is wrong. Different "realm" values can indicate different credential groups if necessary (username vs token) while using the same scheme. RFC 2617 "HTTP Authentication" explicitly states: "Note that there may be multiple challenges with the same auth-scheme but different realms." A server can quite legitimately return: 401 Unauthenticated WWW-Authentication: BASIC realm="User access" WWW-Authentication: BASIC realm="Delegated app access" Web browsers (at least IE8 and FF3) just act on the first of these header -- which is what we want. When issuing a token, OAuth could indicate the realm to which the token applies so a client knows which WWW-Authentication header is appropriate. When issuing a token, OAuth should indicate the authentication mechanism(s) allowed with the token, which also helps the client pick an appropriate WWW-Authentication header. Accepting usernames and tokens will not generally be a problem as any caller (a user's browser or an OAuth client) will only have one or the other -- it just uses what it has. It may be trickier if servers need to indicate that OAuth client credentials (eg app-id/app-secret) and delegation credentials (token/secret) can both be used to access a given protected resource. Different realms are one solution. Often the client will know which credentials are appropriate as it knows the context in which it is making the call. If it is too hard, servers can just use different URIs for access by users, clients-as-themselves, and clients-on-behalf-of-users. James Manger James.H.Manger at team.telstra.com Identity and security team — Chief Technology Office — Telstra
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.