Validating the signed data delivered with the request is as much magic as the current 1.0 approach. Go write the validation rules and see.
I'm getting really tired of this argument because it is not grounded in reality. Any attempt to compare the HTTP request to what was signed, whether it is sent with the request or not, is as difficult. Sending the signed data just makes it easier for the server to make bad assumptions and be flexible in an insecure way. EHL On Sep 24, 2010, at 10:51, "Justin Richer" <jric...@mitre.org> wrote: >>> I think that any signature method that we end up using needs to rely >>> less on magic and anecdote and more on explicit declaration. >> >> This is certainly correct ... >> >> >>> I think >>> that Brian Eaton's approach of sending the bare string that was >>> signed, >>> which was also a JSON element that could be parsed and validated, >>> was an >>> essential simplification. >> >> ... but this does not follow. The signer can specify what was signed >> without sending the data... >> >>> Even OpenID states which of the parameters on >>> the request were signed, which makes it easier to validate. >> >> ... as in this pattern. There are some other examples of elements of >> the signed object being conditionally included: >> 1. HTTP Digest authentication [1] >> 2. The IKEv2 key exchange messages [2] > > And I'm marginally OK with either pattern, though I think that the > former is a much cleaner way to do it. I believe either case to be > worlds better than the OAuth 1.0 method, which has caused countless > problems. I actually had to help someone debug between sending that > first email and this one, so I can attest that the problem has not gone > away! :) > >> As has been pointed out before, there is a security risk in sending >> the signed request data itself (as opposed to metadata that allows the >> recipient to reconstruct the data), because the recipient can choose >> not to verify the binding between the signed data and the request. > > Yes, there is certainly a risk if someone just checks the signature and > does not verify the content of the message. This is a bad implementation > of an authorization system, to be sure, and it's an issue that people > need to be aware of. But simply signing metadata doesn't completely > solve the problem, either. In both cases there can be parameters that > are outside of the signed request that need to be checked and treated > appropriately. > > -- Justin > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
