Re: [OAUTH-WG] Signatures spec proposal, take 2

["Richard L. Barnes" <[e-mail]>]

> I think it's more robust to verify than to generate. In option 2,  
> you have to "guess" what the signer actually signed. To be fair, you  
> have pretty good signals, like the HTTP request line, the Host:  
> header, etc., but in the end, you don't _know_ that the signer  
> really saw the same thing when they generated the signature. I can't  
> help but feeling that that's a bit of a hack. In option 1, you  
> always know what the signer saw when they generated the signature,  
> and it's up to you (the verifier) to decide whether that matches  
> your idea of what your endpoint looks like.

Generating does not imply guessing: The signer can specify what he  
signed without providing the data directly.  Quoting from another  
thread:
"
1. Signer computes signature sig_val over data object:
   { user_agent: "Mozilla", method: "GET" }
2. Signer sends { signed_fields: ['user_agent', 'method'], sig:  
sig_val }
3. Recipient reconstructs data object using signed_fields
4. Recipient verifies sig_val == sign(reconstructed_object)
"

If the spec is written properly, the recipient should be able to look  
at the names of the fields ('user_agent', 'method') and use them to  
reconstruct the original object.

The idea of allowing signed fields to change en route to the server  
strikes me as a little odd.  Sure, you could ignore the method, path,  
and host values in HTTP and just act on the enveloped data, but at  
that point, why not just do away with the overhead of HTTP and run the  
whole thing over TCP?

--Richard