> My point is only that the existing deployment of Basic > prevents it from being used in the way you proposed because > it is more likely to break things and does not offer any real benefit > (other than a theoretical cleaner architecture), > and less work for the spec editor. One very real benefit is that established authentication schemes, such as BASIC, are already supported by frameworks/libraries/systems/infrastructure/plumbing. I think Eran stated that one aim of the current OAuth work was to get OAuth supported in those contexts, not just as app-layer libraries. Consider a networking library (eg java.net.URLConnection) that adds support for TOKEN XXX WWW-Auth schemes (in addition to existing support for BASIC etc). The library has no way of knowing if a caller is making a request in a "direct" or a "delegated" context so it has no way of knowing if it should react to BASIC or TOKEN XXX. All it can do is ask the caller (eg via a caller-supplied java.net.Authenticator), "Have you got a username/password for this address/port/protocol/realm/scheme"? If both a BASIC and a TOKEN PLAIN WWW-Auth header are present in a 401 response, java.net.URLConnection will ask java.net.Authenticator about both in turn (probably in the order they appear) until it gets some credentials. The process is the same if two BASIC headers are present -- it asks about both until it gets an answer. If BASIC and MAC (TOKEN HMAC) headers are present it might ask about the MAC header first as it is the stronger algorithm. [P.S. I assume this is how Java works, but I haven't confirmed all the details yet] > Direct access by clients does work well with existing username-based schemes > because that's what it is - direct access. > We have two distinct cases: direct access and delegated access. > The issue is to have both direct access and delegated access coexist on the same resource. I don't think this divide works. People have made lots of use of the OAuth 1.0 request signing mechanism for delegated access and for "2-legged" direct access. If TOKEN HMAC is not usable for "2-legged" direct access then it misses half the proven use cases. Is removing support for "2-legged" request signing intentional? 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.