Couple of other observations:
Only if you consider the 'recipient' and 'sender' to be the actual machines talking to the raw sockets. But fewer and fewer people are doing that today. Everyone is at least relying on an HTTP library (so the chunked encoding details are hidden from you), and most everybody is sitting on top of a stack or embedded within a framework that they can't easily change. E.g., by the time a message goes through Apache and to a JSP servlet container, it may well have already normalized data and converted character sets (by default you definitely get data converted to UCS-2 of course).
That's a fair point, and one of the main challenges for figuring out what to sign ...
And then of course there are proxies :).
... this being the other :)
The Magic Signature spec is unabashedly an enveloping system that takes the bytes and armors them. If you are dealing with a system that MUST understand your signature algorithm, you then don't have any need to send the original bytes, just the armored ones. (And do you really want someone relying on unsigned bytes?) At which point, if you're doing HTTP requests, you're effectively tunneling an HTTP request (the important part) inside a request payload. It's very, very ugly, and (it seems to me) is basically replicating SSL but at the wrong layer.
Beyond the ugliness, if you send both the armored and unarmored bytes, you're introducing a security risk. Namely, the recipient might validate the signature over the armored bytes, then go on to use the unarmored request, which could be completely unrelated.
I do hope that the key discovery process (starting from an identifier for an author/sender identifier) is something that is re- usable and generic. And specifically, if I have an OAuth public key signed message, along with an identifier for the service that signed it, I would very much like to use this mechanism for discovering public key(s) for the service. Since we can represent both services and people as URIs this seems fairly straightforward and reasonable.
But it still seems separable from the authentication system. As usual, there's a "find the key for the client" step before the verification. That step is deliberately unspecified in order to allow for multiple key management systems to be used with the same authentication protocol.
--Richard _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
