HTTP Signatures

The section on the use of HTTP Message Signing (https://openid.bitbucket.io/fapi/fapi-2_0-advanced.html#name-http-message-signing) is difficult to follow for an implementor. I would suggest the following changes to improve both its effectiveness and security:

split both the “client” and “RS” sections into “signer” and “verifier” roles for each. Right now it’s confusing that the client would need to pull the RS’s key when the rest of the requirements are for signing.
Alternatively, split into “requests from the client to the RS” and “responses from the RS to the client”, and give requirements for both the signer and verifier in each case.
don’t sign the “date” header – it’s often not available to higher level applications. Instead use the “created” signature parameter and require it to be within a reasonably short time window
define a value for “tag” parameter (new parameter in the signatures draft) for both requests and responses. Can be a fixed string or pattern to detect, but recommend a fixed string of “fapi-2-advanced-request” and “fapi-2-advanced-response” or something like that (note: this used to be named “context”)
Require signing the “authorization” header with the token value
Require signing the “dpop” header if present
suggest the use of a “nonce” signature parameter with a random value to prevent replay
recommend signing of other headers or items relevant to the RS’s API

‌

Comments (12)