I think OAuth needs:
1. A WWW-Auth scheme indicating that requests can be signed with a shared-secret key.
2. A WWW-Auth scheme indicating that a web delegation flow can be used to get user authorization.
The two are quite separate.
The first would be defined in draft-ietf-oauth-authentication and would make no reference to delegation at all. "MAC" would be a good name.
<- WWW-Authenticate: MAC realm="whatever"; algorithm="HMAC-SHA1 HMAC-SHA256 CMAC-AES";
mode="HEADER URI POST" <perhaps some more parameters>
-> Authorization: MAC realm="whatever"; algorithm="HMAC-SHA256"; sig="65dFM…"; nonce…
The option to encode the signature in a URI is worthwhile (eg a client can sign a URI then give it to another party to access, eg another party to click in a browser). Hence, the "mode" parameter above. I am less convinced by POST, but it is a small step from URI to POST so it is probably worth having.
[HEADER = can put signature in HTTP Authorization request header;
URI = can put signature in URI query string;
POST = can put signature in HTML <form> POST]
> WWW-Authenticate: Token Plain realm=""
> Authorization: Token Plain <token> <secret>
This isn't necessary. Just use BASIC.
A server may need to ensure usernames and tokens can be distinguished, but that is easy enough.
If an RSA-based mechanism is required a separate WWW-Auth scheme would be the best approach.
A WWW-Auth scheme to trigger the delegation flow is more interesting, but that is for a separate thread.
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.