W007

The OBIE R/W API specification (in v3.0, 3.1, 3.1.1, 3.1.2 and 3.1.3) require both TPPs and ASPSPs to sign all payment messages (JSON Web Signatures JWS). Non-repudiation requirements are met through the use of a number of extensions including RFC 7797. The OBIE specification makes use of the "b64" header parameter and currently enforces the following:

• the parameter b64 to be false (must not contain a Base64URL encoded payload element)

• the parameter b64 as a critical claim by adding it to the crit claim

The b64 claim (defined in https://tools.ietf.org/html/rfc7797#section-3) controls whether the message is base64-url encoded before signing. Unfortunately, a number of the JWS libraries do not correctly implement support for the b64 claim, resulting in incorrect signature generation and validation by any ASPSP or TPP who uses these libraries.

• Majority of the JWT libraries do not support the ‘b64’ header parameter for message signing in the RW APIs making it virtually impossible for ASPSPs/TPPs who use these libraries to verify the x-jws-signature consistently.

• Majority of ASPSPs are therefore unable to pass any tests and certify conformance for payment initiation using the functional conformance tool.

• It is likely that TPP implementations will face a similar issue while generating PISP requests and will generate messages that are incorrectly signed.

• The receiving party (TPPs / ASPSPs) will be unable to verify message signatures correctly.

Immediate action

• TPPs and ASPSPs must not validate the message signature during the period of the waiver.

• ASPSPs should ignore, but must not reject signature during the period of the waiver.

• OBIE must update the conformance harness to not generate or validate the message signature during the period of the waiver.

In the longer term

• No retrospective changes will be made to previous published versions of the API Specification (i.e. v3.1, 3.1.1, 3.1.2, 3.1.3).

• Version 3.1.4 of the Payment Initiation API Specification has been updated to remove the claim b64 claim in the header.

• After expiration of this waiver: TPPs and ASPSPs must support message signatures as defined in their Payment Initiation APIs implementation after expiration of the waiver. 

  • If ASPSPs are still using v3.1.3 or earlier, they must support the parameter b64 to be false, and any TPPs using these ASPSPs must do the same.

  • If ASPSPs have updated to v3.1.4 or later, they must not include the b64 claim in the header, and any TPPs using these ASPSPs must do the same.

  • OBIE must update the conformance tool.

  • ASPSPs should re-run the conformance tool and re-apply for a certification for PIS.

• ASPSPs must include details of which version they support in their API documentation and must give TPPs at least three month's notice of any changes.

OBIE will work with ASPSPs, TPPs and vendors to ensure that this is effectively communicated.     

• ASPSPs and TPPs may need to modify or bypass the library used for signing in order to implement the specification in this regard. 

• ASPSPs and TPPs may need to again modify their codebase regardless of the W007 when b64 claim is removed from a future version of the Payment Initiation APIs.

• The cost of modifying and maintaining these libraries is expected to far outweigh the cost of suppressing the header as recommended above.

• The defective signatures are difficult to detect and could lead to a significant support burden for OBIE and the ecosystem.

• ASPSPs will not be able to pass conformance tests and certify. This will lead to confusion and could limit adoption/take-up of Payment Initiation APIs.

Not known

Not known