> > 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
