<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Just when through the document again.</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);">
This is a great complementary document for DPoP for the purpose of increasing integrity level of messages. There are couple of fundamental differences between integrity (sa strived by DPoP, SHMIP) and non-repudiation:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<ol data-listchain="__List_Chain_38">
<li><span>The content of the message relevant for the non-repudiation proof</span></li><li><span>The juridical intent of the non-repudiation and</span></li><li>The period for which the non-repudiation character of the message must be preserved.</li></ol>
</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);">
These underlying constraints required any non-repudiation specification to consider following:</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);">
<div><span>The possibility of adding custom headers to the signature</span></div>
<div><span><br>
</span></div>
<div><span>There is no way we can required every information to be signed to be added to the request body. The design of an API is left to the discretion of the target market. The decision on how to transport an information (Header, body, certificate, ..) cannot
be constrained by a non-repudiation spec.</span></div>
<div><span><br>
</span></div>
<div><span>Verification Key Constraints</span></div>
<div><span><br>
</span></div>
<div><span>The ability to specify additional verification key constraints is inherent to the need of non-repudiation itself. For non-repudiation, the legitimacy and longevity of the verification key is as important as the signature itself. Therefore, a spec
designed for non-repudiation must provide a way of specifying/limiting the type and nature of keys to be used and the way this key is communicated to the verifier.</span></div>
<div><span><br>
</span></div>
<div>Canonicalization of Signature Content</div>
<div><br>
</div>
<div>In the same perspective, a specification for non-repudiation must open room allow canonicalization of the signature content (both header and messages). There are many reasons why we cannot limit the nature of header fields to be carried by the non-repudiating
signature. Including but not limited to the long term need of adding evidence records (See
<a href="https://tools.ietf.org/html/rfc4998" id="LPlnk">https://tools.ietf.org/html/rfc4998</a>).</div>
<div><br>
</div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
In summary, using DPoP and SHMIP, we can solidify integrity of messages exchanged in during a grant negotiation. As life cycle of that negotiation flow is always limited in time. For long term and legally effective proof of the non-repudiation of a message,
those specifications are not appropriate.</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);">
For this reason, a draft addressing nonrepudiation can only be a template that has to be materialized when concrete conditions of the target market are known. Therefore, I advise to consider opening room for the possibility of specifying:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<ul>
<li><span>Signature Data : referencing a documentation off what data (content, headers) are application for a legislation (market). This shall also include of applicable canonicalization rules to apply to data to be signed, a eventually specification on how
to provision those signed records with additional evidence records over time.</span></li><li>Signature Trust Framework : defining what type of key are acceptable, how those keys are discovered, transported, and legitimated.</li></ul>
<div><br>
</div>
<div>Without having check with OBE, i suspect they are facing the same challenges, and this might be the reason why they AFAIK haven't released a version of their Open Banking Signature spec yet.</div>
<div><br>
</div>
<div>Best regards</div>
<div><br>
</div>
<div>/Francis</div>
</div>
</body>
</html>