Sandbox Digital Signature Utility SMBC Group v1.0

#

Step and Use Case

Provenance

Endpoint

Parameters

1

Generate signing string and digital signature

• This utility enables you to compare the three Berlin Group digital signature headers returned from this operation against what your code produces.
• This utility further returns additional information that you can use for development and testing purposes including the derived signing string that we use to calculate the digital signature in both text and hashed formats. This enables you to validate the intermediate processing steps when generating the digital signature and needs to be correct before proceeding to the next step.
• The "smbc-headers" HTTP header is Berlin Group operation agnostic and can be used to specify any headers of your choosing. This flexibility enables you to test both happy- and unhappy-paths for all your Berlin Group operations in relation to signing string and digital signature generation.

SMBC Group

POST /sandbox/v1/signature

HTTP headers

• smbc-headers (SMBC): custom SMBC header used to specify the list of HTTP headers to be used when generating the signature for the message, e.g., consent-id, x-request-id, psu-id. Note that the order matters.
• smbc-request-target (SMBC): In production, the (request-target) is derived from the production endpoint being used, for example "POST /berlingroup/v1/payments/pain.001-sepa-credit-transfers". This custom header enables you to simulate different production endpoints when testing your digital signature implementation.

Request payload

• Any payload will do but we suggest using sample payloads that you are planning to use for, say, POST /payments.

2

Validate Berlin Group request headers for digital signatures

• When you are satisfied that your application is generating the signing string and digital signature that matches POST /sandbox/v1/signature above, this utility enables you to validate the Berlin Group headers for the corresponding request.
• As before, the "smbc-headers" HTTP header can be used to specify any headers of your choosing and therefore testing both happy- and unhappy-paths for all Berlin Group operations that require digital signatures.

POST /sandbox/v1/signature/validation

HTTP headers

• smbc-headers (SMBC): custom SMBC header used to specify the list of HTTP headers to be used when generating the signature for the message, e.g., consent-id, x-request-id, psu-id. Note that the order matters.
• Digest (Berlin Group): hash of the request payload.
• Signature (Berlin Group): digital signature header in the format defined by the Cavage/Sporny specification.
• TPP-Signature-Certificate (Berlin Group): certificate used for signing the request, in base64 encoding.

Request payload

• Any payload will do but we suggest using sample payloads that you are planning to use for, say, POST /payments.

3

Submit payment and signing basket requests with digital signatures

• When you have fully tested the digital signatures for, say, payment creation using the digital signature validation utility above, you are now ready to submit the full request to POST /payments.
• In addition to all the standard Berlin Group checks (e.g. OAuth2, mandatory headers), selected PISP operations such as POST /payments require you to include the three Berlin Group headers for digital signatures. If your tests have passed using the two utilities above, you should not expect any digital signature errors when invoking these Berlin Group operations.
• This enables you to separate the development and testing of the digital signature elements of your application from the rest of your application (e.g. OAuth2, mandatory headers).

Berlin Group

All PISP operations requiring digital signatures including POST /payments/{payment-product}

See the respective API documentation pages.