<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi Francis</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">> sigT - this is equivalent to `iat` and if we have a standard JWT, then we can use the standard `iat` claim</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">> sigD - now there are three types of data that need to be signed:</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><b><br></b></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><b>1. url & method</b></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">dpop has a defined way to convey these in a standard JWT. I see no reason why the representation of these values according to the OBE spec is any better. Arguably it is worse as it relies on canonicalisation rules from draft-cavage.</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>2. request body</b></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">obe/draft cavage don't directly sign this, but rather rely on an http digest header being created and use that as the signing material. My suggestion is that rather than sign the http header, we actually include the digest as a defined claim in a JWT. This makes both signing and verification easier and arguably makes the resulting JWT easier to understand and use as it is a self-contained token, there is no need to reconstruct the signing material, the verifier simply has to compute the digest and compare it to the verified digest in the JWT.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><b><br></b></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><b>3. other http headers</b></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">My recommendation is that for any new API standard these should be avoided. I think the industry has settled on a best practice for RESTful JSON APIs of having payloads containing `data` and `meta` objects. Any metadata is better to be sent in the body rather than as a header. However I understand that many existing API specs (including current drafts of FAPI) use http headers to convey relevant metadata. Now if request size is not an issue then my suggestion is that http headers that need to be signed are repeated in the JWT (e.g. <a href="https://github.com/davidgtonge/http-signing/blob/main/src/dpop-plus3.js">https://github.com/davidgtonge/http-signing/blob/main/src/dpop-plus3.js</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"><b>Verification Complexity</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">Verification steps for dpop-plus</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">1. compute body digest hash</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">2. decode JWT to get public key details</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">3. retrieve public key</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">4. verify JWT</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">5. check equality between http method and `htm` claim</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">6. check equality between http uri and `htu` claim</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">7. check equality between digest hash and `htd` claim</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">8. check equality between `hth` claim and other http headers (ensuring that header names are lowercased)</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">All of this can be done using standard JWT libraries. </div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">The verification checks are simple equality checks.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">It is very clear to understand if anything goes wrong.</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">Verification steps for OBE<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">1. compute body digest hash</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">2. parse signature header to retrieve the JWS header<br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">3. decode JWS header</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">4. retrieve public key</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">5. verify that non-standard JWS header claims are included in the `crit` claim</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">6. use the `sigD.pars` data to construct the signing material according to the `sigD/mId` scheme</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">7. verify the JWS using the signing material</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">This can't be done by all standard JWT libraries </div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"> - many will base64url encode with jws payload</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"> - many won't verify `crit` claims automatically</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"> - many won't decode a detached JWS</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">Step 6 is quite complex and if something goes wrong the verifier has no idea that the problem is. This can be a big barrier to interoperability. As pointed out in the OBE spec they haven't understood the importance of lower-casing http headers, and that is a group of very technically minded people trying to write a spec. Implementers are very likely to make similar issues and it will be hard to understand what has gone wrong. </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">Do you think its worth having a call to talk about 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">Thanks</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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 30 Oct 2020 at 00:22, Francis Pouatcha <<a href="mailto:Francis.Pouatcha@adorsys.com">Francis.Pouatcha@adorsys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Dave,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
DPoP is simple because if focusses on the transport (moment) and can thereby limited on transport related issues. It is IMHO designed for ephemeral transport based key materials, where there is no need to have a key legitimated.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
A Http Signature must be designed to allow for use as proof in a court case or as supporting material for an audit. This is the reason why you need those additional attributes that by consequence lead to more complexity.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
As for OBE, attributes added are</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<ul>
<li>sigT: the signature time. This could in many cases be different from the transmission time of the request.</li><li>sigD: the signature data specification: this is essential to define what is to be signed. As </li><ul>
<li>different legislation might require the presence of different header parameters</li><li>the body type canonicalization might vary depending on the nature of the request body (or not). The canonicalization of the body content will be a variant to deal with. In particular, when it will come to archiving signed http requests.</li></ul>
</ul>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
We are suggesting an additional:</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<ul>
<li>sigF: to indicate the trust framework for. resolution and legitimation of the key material.  </li></ul>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:"trebuchet ms",sans-serif;font-size:14px;background-color:rgb(255,255,255);display:inline">PSD2 API initiatives in Europe<span> in Europe are contributor to OBE, therefore the highest probability they will all adopt it.
 Beside this it is prepared for eIDAS conformity, making signed material a valid proof under European law.</span></span><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:"trebuchet ms",sans-serif;font-size:14px;background-color:rgb(255,255,255);display:inline"><span><br>
</span></span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:"trebuchet ms",sans-serif;font-size:14px;background-color:rgb(255,255,255);display:inline"><span>/Francis</span></span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="font-family:"trebuchet ms",sans-serif;font-size:14px;background-color:rgb(255,255,255);display:inline"><span><br>
</span></span></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-7564259005954378471divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Dave Tonge <<a href="mailto:dave.tonge@momentumft.co.uk" target="_blank">dave.tonge@momentumft.co.uk</a>><br>
<b>Sent:</b> Thursday, October 29, 2020 12:43 PM<br>
<b>To:</b> Francis Pouatcha <<a href="mailto:Francis.Pouatcha@adorsys.com" target="_blank">Francis.Pouatcha@adorsys.com</a>><br>
<b>Cc:</b> FAPI Working Group List <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>>; Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-fapi] A simpler signing solution</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div style="font-family:"trebuchet ms",sans-serif">I've pushed some example code for the some of the different signing mechanisms here: <a href="https://github.com/davidgtonge/http-signing" target="_blank">https://github.com/davidgtonge/http-signing</a></div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">I'll add a bit more analysis.</div>
<div style="font-family:"trebuchet ms",sans-serif">But my main issue with the OBE approach is the unnecessary complexity.</div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">For example compare this file: <a href="https://github.com/davidgtonge/http-signing/blob/main/src/obe.js" target="_blank">https://github.com/davidgtonge/http-signing/blob/main/src/obe.js</a></div>
<div style="font-family:"trebuchet ms",sans-serif">With this one: <a href="https://github.com/davidgtonge/http-signing/blob/main/src/dpop-plus.js" target="_blank">https://github.com/davidgtonge/http-signing/blob/main/src/dpop-plus.js</a></div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">This is just the signing rather than the verification. </div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">The question to my mind is will PSD2 API initiatives in Europe adopt the OBE profile. I'm not sure that OBUK will. Do you know if Berlin Group will?</div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">Dave</div>
</div>
<br>
<div>
<div dir="ltr">On Thu, 29 Oct 2020 at 15:33, Francis Pouatcha <<a href="mailto:Francis.Pouatcha@adorsys.com" target="_blank">Francis.Pouatcha@adorsys.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310appendonsend" style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Dave Tonge <<a href="mailto:dave.tonge@momentumft.co.uk" target="_blank">dave.tonge@momentumft.co.uk</a>><br>
<b>Sent:</b> Thursday, October 29, 2020 10:09 AM<br>
<b>To:</b> FAPI Working Group List <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Cc:</b> Francis Pouatcha <<a href="mailto:Francis.Pouatcha@adorsys.com" target="_blank">Francis.Pouatcha@adorsys.com</a>>; Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-fapi] A simpler signing solution</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div style="font-family:"trebuchet ms",sans-serif">Hi Francis, Brian</div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">I am proposing that we define a new mechanism for http signing in the FAPI WG.</div>
<div style="font-family:"trebuchet ms",sans-serif">Obviously it should use existing standards where at all applicable.</div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">As discussed on the call, it would be good to come up with a document that we can present to the WG.</div>
<div style="font-family:"trebuchet ms",sans-serif">It seems that we have two options at the moment:</div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif"><b>1. Build on the OBE spec</b></div>
<div style="font-family:"trebuchet ms",sans-serif"><b>2. Build on dPOP</b></div>
<div style="font-family:"trebuchet ms",sans-serif"><b><br>
</b></div>
<div style="font-family:"trebuchet ms",sans-serif">At first I was leaning towards option 1, but after further review of the OBE spec I personally am very much leaning towards option 2. I think the OBE spec is not fit for purpose, it adds lots of unnecessary
 complexity just because its trying to join draft-cavage and  an earlier version of the UK OpenBanking signing spec together. I may try and show some worked examples as I think my suggestion will result in a small http payload even if some header values are
 repeated. </div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">I do believe the payload size is less interesting here than interoperability. I prefer we look at how to simplify  the current OBE draft.</div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif"><a id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310OWAAM157636" href="mailto:bcampbell@pingidentity.com" target="_blank">@Brian Campbell</a> -> reply inline bellow:</div>
</div>
<br>
<div>
<div dir="ltr">On Thu, 29 Oct 2020 at 14:12, Brian Campbell via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div dir="ltr">
<div>
<div dir="ltr">On Thu, Oct 29, 2020 at 5:10 AM Francis Pouatcha <<a href="mailto:Francis.Pouatcha@adorsys.com" target="_blank">Francis.Pouatcha@adorsys.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I agree with Dave we shall not define a new signature mechanism.</div>
</div>
</blockquote>
<div><br>
</div>
<div>As I understood the message that started this thread and the discussion about it during the call yesterday, Dave is very much proposing that we define a new mechanism. Maybe there's some semantic difference or miscommunication here but I'm confused by
 your statement. <br>
</div>
</div>
</div>
</div>
</blockquote>
<div>I think having compatibility with OBE is essential.</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div>
<div> </div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
As for the replacement of RFC3230 with <a href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/" id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310x_gmail-m_4747989461665442057gmail-m_3117359831006870745gmail-m_-5782288200654301967LPlnk789417" style="margin:0px;font-size:14px;background-color:rgb(255,255,255)" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/</a>,
 adding a signature header field to indicate the mechanism used to digest the http body might solve the problem.</div>
</div>
</blockquote>
<div><br>
</div>
<div>What problem? I just wanted to note that there was work underway to update/obsolete RFC3230 as it seemed relevant given Dave's initial proposal relied on RFC3230. But I don't understand what problem you're suggesting would be introduced by the new document
 or how that would solve it.</div>
</div>
</div>
</div>
</blockquote>
<div>No problem. Like elaborated in <a href="https://bitbucket.org/openid/fapi/issues/297/open-banking-europe-jws-profile-for#comment-59040544" id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPlnk" target="_blank">https://bitbucket.org/openid/fapi/issues/297/open-banking-europe-jws-profile-for#comment-59040544</a> the
 field "sigD"."pars" can be  used to indicate canonicalization and digest rules for body. Giving implementor a choice on how to process the http body.</div>
<div>
<div id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPBorder_GTaHR0cHM6Ly9iaXRidWNrZXQub3JnL29wZW5pZC9mYXBpL2lzc3Vlcy8yOTcvb3Blbi1iYW5raW5nLWV1cm9wZS1qd3MtcHJvZmlsZS1mb3IjY29tbWVudC01OTA0MDU0NA.." style="width:100%;margin-top:16px;margin-bottom:16px;max-width:800px;min-width:424px">
<table id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPContainer607209" style="padding:12px 36px 12px 12px;width:100%;border-width:1px;border-style:solid;border-color:rgb(200,200,200);border-radius:2px">
<tbody>
<tr valign="top" style="border-spacing:0px">
<td>
<div id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPImageContainer607209" style="margin-right:12px;height:160px;overflow:hidden">
<a id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPImageAnchor607209" href="https://bitbucket.org/openid/fapi/issues/297/open-banking-europe-jws-profile-for#comment-59040544" target="_blank"><img id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPThumbnailImageId607209" alt="" height="160" width="160" style="display: block;" src="https://bytebucket.org/ravatar/%7B62dbbd30-f6ca-4f4f-94f6-3231a7ffb001%7D?ts=markdown"></a></div>
</td>
<td style="width:100%">
<div id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPTitle607209" style="font-size:21px;font-weight:300;margin-right:8px;font-family:wf_segoe-ui_light,"Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;margin-bottom:12px">
<a id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPUrlAnchor607209" href="https://bitbucket.org/openid/fapi/issues/297/open-banking-europe-jws-profile-for#comment-59040544" style="text-decoration:none" target="_blank">Open Banking Europe JWS PROFILE for OpenBanking</a></div>
<div id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPDescription607209" style="font-size:14px;max-height:100px;color:rgb(102,102,102);font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;margin-bottom:12px;margin-right:8px;overflow:hidden">
This JWS profile consolidate the work done at ETSI \\(JADes\\) and the Internet Draft draft-cavage-http-signatures-10 and Signing HTTP Messages. This issue will be used to collect details associated with referencing that work in the FAPI profiles for the purpose
 of addressing non repudiation.</div>
<div id="gmail-m_-7564259005954378471x_gmail-m_1302359872621938310LPMetadata607209" style="font-size:14px;font-weight:400;color:rgb(166,166,166);font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif">
<a href="http://bitbucket.org" target="_blank">bitbucket.org</a></div>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div>
<div><br>
</div>
<div>I am a bit concerned (or rather just don't really understand the implications of) about RFC3230 and it's successor digesting the "instance" or "representation" of the resource as opposed to the payload of the message itself. But as far as I can tell RFC3230
 and <a href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/" target="_blank">
https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/</a> are the same in this regard but just use different language to describe it.<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes.</div>
<div><br>
</div>
<div>/Francis</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div style="font-size:1em;font-weight:bold;line-height:1.4">
<div style="color:rgb(97,97,97);font-family:"Open Sans";font-size:14px;font-weight:normal;line-height:21px">
<div style="font-family:Arial,Helvetica,sans-serif;font-size:0.925em;line-height:1.4;color:rgb(220,41,30);font-weight:bold">
<div style="font-size:14px;font-weight:normal;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal">
<div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">
<div style="font-weight:400;color:rgb(51,51,51);line-height:normal">
<div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">
Dave Tonge</div>
<div style="font-size:0.8125em;line-height:1.4">CTO</div>
<div style="font-size:0.8125em;line-height:1.4;margin:0px"><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" style="color:rgb(131,94,165)" target="_blank"><img alt="Moneyhub Enterprise" height="50" title="Moneyhub Enterprise" width="200" style="border: none; padding: 0px; border-radius: 2px; margin: 7px;" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png"></a></div>
<div style="padding:8px 0px">
<div style="padding:8px 0px">
<div style="letter-spacing:normal;line-height:normal">
<div style="padding:8px 0px"><span style="color:rgb(0,164,183);font-size:11px">Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL</span></div>
<span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold">t: </span><span style="font-size:11px;line-height:15.925px">+44 (0)117 280 5120</span><br style="color:rgb(0,164,183);font-size:11px;line-height:15.925px">
</div>
<div style="letter-spacing:normal;line-height:normal"><span style="font-size:11px;line-height:15.925px"><br>
</span></div>
<div style="color:rgb(97,97,97);font-family:"Open Sans";letter-spacing:normal">
<div style="line-height:1.4"><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em">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 </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em;background-color:transparent">(FRN </span><span style="color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;font-size:10.5px;font-weight:700">809360</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em">)
 at <a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. M</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:10.5px">oneyhub</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em"> Financial
 Technology is registered in England & Wales, company registration number </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em"> </span><span style="font-weight:bold;color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em">06909772</span><span style="background-color:transparent"><font color="#333333" face="lato, open sans, arial, sans-serif"><span style="font-size:0.75em"> .</span></font></span></div>
<div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4">
<span style="background-color:transparent;font-size:10.5px">Moneyhub</span><span style="background-color:transparent;font-size:0.75em"> Financial Technology Limited 2018 </span><span style="background-color:transparent;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:x-small">©</span></div>
<div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4">
<span style="background-color:transparent;font-size:0.75em"><br>
</span></div>
<div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4">
<span style="background-color:transparent;font-size:0.75em;color:rgb(136,136,136)">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.</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</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>
</div>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:1em;font-weight:bold;line-height:1.4"><div style="color:rgb(97,97,97);font-family:"Open Sans";font-size:14px;font-weight:normal;line-height:21px"><div style="font-family:Arial,Helvetica,sans-serif;font-size:0.925em;line-height:1.4;color:rgb(220,41,30);font-weight:bold"><div style="font-size:14px;font-weight:normal;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4"><div style="font-weight:400;color:rgb(51,51,51);line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">Dave Tonge</div><div style="font-size:0.8125em;line-height:1.4">CTO</div><div style="font-size:0.8125em;line-height:1.4;margin:0px"><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" style="color:rgb(131,94,165)" target="_blank"><img alt="Moneyhub Enterprise" height="50" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" title="Moneyhub Enterprise" width="200" style="border: none; padding: 0px; border-radius: 2px; margin: 7px;"></a></div><div style="padding:8px 0px"><div style="padding:8px 0px"><div style="letter-spacing:normal;line-height:normal"><div style="padding:8px 0px"><span style="color:rgb(0,164,183);font-size:11px">Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL</span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold">t: </span><span style="font-size:11px;line-height:15.925px">+44 (0)117 280 5120</span><br style="color:rgb(0,164,183);font-size:11px;line-height:15.925px"></div><div style="letter-spacing:normal;line-height:normal"><span style="font-size:11px;line-height:15.925px"><br></span></div><div style="color:rgb(97,97,97);font-family:"Open Sans";letter-spacing:normal"><div style="line-height:1.4"><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em">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 </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em;background-color:transparent">(FRN </span><span style="color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;font-size:10.5px;font-weight:700">809360</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em">) at <a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. M</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:10.5px">oneyhub</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em"> Financial Technology is registered in England & Wales, company registration number </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em"> </span><span style="font-weight:bold;color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em">06909772</span><span style="background-color:transparent"><font color="#333333" face="lato, open sans, arial, sans-serif"><span style="font-size:0.75em"> .</span></font></span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><span style="background-color:transparent;font-size:10.5px">Moneyhub</span><span style="background-color:transparent;font-size:0.75em"> Financial Technology Limited 2018 </span><span style="background-color:transparent;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:x-small">©</span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><span style="background-color:transparent;font-size:0.75em"><br></span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4"><span style="background-color:transparent;font-size:0.75em;color:rgb(136,136,136)">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.</span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></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>