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

Anders Rundgren anders.rundgren.net at gmail.com
Wed Feb 3 06:02:40 UTC 2021


Hi Francis,

It is clear that the proposal leaves out signed HTTP headers. This is IMO the only issue you raised that is of the type GO/NO GO.

I'm unable following your reasoning about non-repudiation; maybe a concrete example could be helpful?

TLDR;

 From my watchtower seen, it doesn't make sense for a signer to specify legally oriented information that is related to the specific signature/key.  Validity and trust of a signature as well as long-term storage of signed data seems to rather be an issue for relying parties and the rules/laws they are operating under.

AFAIK, it is usually the issuer (CA) who specifies policies for signature keys which typically is expressed in a CPS as well as through tons of [mostly useless] X.509 policy extensions.

A signer may indeed specify policies like validity and conditions, but those would be related to the message rather than the signature/key.

Maybe some of this is rooted in the eIDAS vision?  In theory you may be obliged to trust and accept eIDAS-signed messages. IMO, this is not going to happen because relying parties need additional information before entering a purely "digital relation" like the PRETA registry.  in addition, there are considerable technical, liability, and cost issues associated with the eIDAS concept.

Regards,
Anders

On 2021-02-02 21:01, Francis Pouatcha via Openid-specs-fapi wrote:
> 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 <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
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> 



More information about the Openid-specs-fapi mailing list