[Openid-specs-fapi] Reviewing SHMIP at https://bitbucket.org/openid/fapi/src/581a0350bca97240f104fa27f4e9f0d9d851aab0/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md

Francis Pouatcha fpo at adorsys.de
Tue Feb 2 20:01:19 UTC 2021


Just when through the document again.

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:

  1.  The content of the message relevant for the non-repudiation proof
  2.  The juridical intent of the non-repudiation and
  3.  The period for which the non-repudiation character of the message must be preserved.

These underlying constraints required any non-repudiation specification to consider following:

The possibility of adding custom headers to the signature

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.

Verification Key Constraints

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.

Canonicalization of Signature Content

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 https://tools.ietf.org/html/rfc4998).

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.

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:

  *   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.
  *   Signature Trust Framework : defining what type of key are acceptable, how those keys are discovered, transported, and legitimated.

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.

Best regards

/Francis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20210202/f8d505bd/attachment-0001.html>


More information about the Openid-specs-fapi mailing list