>> 401 Unauthenticated >> WWW-Authentication: BASIC realm="User access" >> WWW-Authentication: BASIC realm="Delegated app access" > How is a client supposed to know what to do with this? This is not enough to trigger a web-delegation flow -- we need another WWW-Auth header for that. Once a client has an id and shared-secret (whether from a web delegation flow, a configuration file, prompting a user operating the client...) the above header tells it to retry the request with a "Authorization: BASIC Zm9vOmJhcg==" header. If the client was given a realm value when it got the id and shared-secret, then the two headers above indicate if those credentials can be used for this protected resource. If the client has its own id/secret and another id/secret as a delegate for another user, then the multiple realms can tell it which set the server is asking for. > Digest has failed adoption Fine, so we should be wary about reinventing it with "Token HMAC" unless that offers something significantly different. The ability to put the signature in the URI or body is different (but you want to drop that); simplicity may be different enough. Getting the credentials from a delegation flow is not a difference as it should be orthogonal. > Basic provides practically zero value I don't understand how "Token Plain" can offer any more value than BASIC. (Personally I think BASIC is massively useful over HTTPS) The "Token Plain" and "Token HMAC" WWW-Auth schemes look like a deliberate attempt to keep authentication and web-delegation tightly coupled. This must be unnecessary. I though the whole idea of splitting OAuth into authentication and web-delegation specs was that these are separate concerns. The authentication part is useful even if you didn't get the credentials via delegation. The delegation part is useful whatever authentication mechanism is subsequently used. It seems like bad design to keep the authentication spec bound to web-delegation (though there will need to be some links in the other direction). 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.