[Openid-specs-fapi] HTTP Signing
Dave Tonge
dave.tonge at momentumft.co.uk
Wed Jan 6 15:15:35 UTC 2021
Dear WG
The FAPI2 Advanced spec requires a mechanism for HTTP signing.
Brian and I have worked on the following spec based on DPoP that could be
used to enable this:
https://bitbucket.org/openid/fapi/src/581a0350bca97240f104fa27f4e9f0d9d851aab0/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md
(SHIMP)
There has been some discussion in this issue
<https://bitbucket.org/openid/fapi/issues/309/decision-on-message-signing-for-fapi-2>
I'll provide some more info below, but my ask of the WG is:
*Should the FAPI WG adopt this document as a WG draft and start working on
it?*
I would be grateful for any feedback. If there is not support to work on
such a spec within the WG then we can leave it and potentially in FAPI2
advanced require http signing but without specifying the method to use.
---
Here is an overview of the spec from the intro:
*The OAuth working group at the IETF has defined the DPOP standard which
"enables a client to demonstrate proof-of-possession of a public/private
key pair by including a DPoP header in an HTTP request". DPOP specifies a
way for a client to sign a proof which contains claims for the HTTP method
and URI. The specification allows DPoP proofs to be extended to protect
additional HTTP data.This specification is an extension to DPoP that
supports the following 1. Signing a digest of the HTTP body data 2. Using
DPoP proofs in HTTP responses 3. Allowing a signed HTTP response to be
cryptographically linked to a signed HTTP requestThe aim of this
specification is to provide a simple, interoperable method of signing HTTP
requests and responses. By utilizing DPOP (which itself utilizes the JOSE
suite of standards) and DIGEST there is no need for custom canonicalization
rules. The DPoP proof is a simple self-contained JWT and is therefore
simple to verify.*
----
I personally think that the ability to have a standards based approach to
link the request and response for http signing will be important for the
non-repudiation use-case.
Issues with other solutions:
1. Draft Cavage - custom (error prone) canonicalization and algorithm
specification
2. OBE / ETSI - same problem as Cavage, but with the addition of a strange
use of detached JWS for signing caoniclisated http headers rather than the
body
3. Detached JWS (used by OB UK) - only signs the body, requires custom JWT
header claims
In contrast SHIMP has these advantages:
- uses simple JWTs, easy to implement, interoperable
- no need for custom JWT header claims
- no error-prone canonicalization
I look forward to receiving your feedback.
Dave
--
Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at https://register.fca.org.uk/
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered
in England & Wales, company registration number 06909772. Moneyhub
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building,
Temple Quay, 1 Friary, Bristol, BS1 6EA.
DISCLAIMER: This email
(including any attachments) is subject to copyright, and the information in
it is confidential. Use of this email or of any information in it other
than by the addressee is unauthorised and unlawful. Whilst reasonable
efforts are made to ensure that any attachments are virus-free, it is the
recipient's sole responsibility to scan all attachments for viruses. All
calls and emails to and from this company may be monitored and recorded for
legitimate purposes relating to this company's business. Any opinions
expressed in this email (or in any attachments) are those of the author and
do not necessarily represent the opinions of Moneyhub Financial Technology
Limited or of any other group company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20210106/c90222b6/attachment.html>
More information about the Openid-specs-fapi
mailing list