Could you clarify how you think it's relevant?
ISTM that the major parts of the document are:
-- Format for encoding a signature on arbitrary binary data
-- Key discovery process
I don't think it really makes sense to use the magic envelope format
for signing HTTP requests, mainly because there's no need to replicate
the data (since TCP guarantees that the recipient gets same sequence
of bytes that was sent). The only things in the signature besides the
data are the encoding/algorithm IDs and the signature, which is a
small enough, constrained enough set of information that the encoding
isn't a huge deal.
In particular, the magic signature system doesn't address what parts
of the HTTP request get signed, and how they get normalized -- the
hard question of OAuth. All it really does is raise the idea of just
blindly signing bytes, which might be a good idea here: Just take the
whole HTTP request with the OAuth header removed and sign/verify it as
a sequence of bytes. That sort of signature probably wouldn't survive
things like proxies, though.
Are you proposing to use the key discovery process? Even there, it
doesn't seem like there's a whole lot of utility, given that the other
major work of this group is defining a key management system.
Just confused,
--Richard
On Feb 9, 2010, at 8:15 AM, Eran Hammer-Lahav wrote:
http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html
This is relevant to our discussion about how to apply signatures to
HTTP requests.
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
