<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Dear WG<br clear="all"></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">The FAPI2 Advanced spec requires a mechanism for HTTP signing.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Brian and I have worked on the following spec based on DPoP that could be used to enable this:</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><a href="https://bitbucket.org/openid/fapi/src/581a0350bca97240f104fa27f4e9f0d9d851aab0/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md">https://bitbucket.org/openid/fapi/src/581a0350bca97240f104fa27f4e9f0d9d851aab0/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md</a> (SHIMP)<br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">There has been some discussion in <a href="https://bitbucket.org/openid/fapi/issues/309/decision-on-message-signing-for-fapi-2">this issue</a></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I'll provide some more info below, but my ask of the WG is:</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><b>Should the FAPI WG adopt this document as a WG draft and start working on it?</b></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">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.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">---</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Here is an overview of the spec from the intro:</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><i>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.<br><br>This specification is an extension to DPoP that supports the following<br><br> 1. Signing a digest of the HTTP body data<br> 2. Using DPoP proofs in HTTP responses<br> 3. Allowing a signed HTTP response to be cryptographically linked to a signed HTTP request<br><br>The 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><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">----</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">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.<br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Issues with other solutions:</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">1. Draft Cavage - custom (error prone) canonicalization and algorithm specification</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">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</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">3. Detached JWS (used by OB UK) - only signs the body, requires custom JWT header claims</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">In contrast SHIMP has these advantages:</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"> - uses simple JWTs, easy to implement, interoperable</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"> - no need for custom JWT header claims</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"> - no error-prone canonicalization</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I look forward to receiving your feedback.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Dave</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div></div>

<br>
<p dir="ltr" style="font-weight:bold"><font face="Arial" color="#808080" size="1">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 <a href="https://register.fca.org.uk/" target="_blank"><span>https://register.fca.org.uk/</span></a>. 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. </font></p><p dir="ltr" style="font-weight:bold"><span style="color:rgb(128,128,128);font-family:Arial;font-weight:400"><font size="1">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.</font></span></p><br>