Release Notes for BankID CSC Signing¶

Noteworthy changes in BankID CSC Signing.

Only important bugfixes, API changes and new features are listed here.

Releases¶

Token single-use enforcement: Each access token from csc/v2/oauth2/token must now follow a strict endpoint order (credentials/list → credentials/authorize → signatures/signHash). Reusing a token at an endpoint it has already been used at will result in a token_already_used error (HTTP 400). This ensures that each signing session follows the intended flow, and prevents issues caused by token reuse or out-of-order calls.
Input validation on credentials/authorize: The numSignatures parameter now requires a value between 1 and 50, the hashes array is required with a maximum of 50 entries, and hashAlgorithmOID is required. Invalid requests are rejected with a clear error message.
Maximum hashes reduced from 100 to 50: The maximum number of hashes accepted per call to credentials/authorize and signatures/signHash has been reduced from 100 to 50.
Improved error responses: Errors from the signing backend are now mapped to specific error codes rather than generic responses, making it easier to diagnose issues. See the new Error handling documentation for a full reference.
New error code csc_user_keys_limit: Returned with HTTP 503 when the signing backend key generation limit is temporarily reached. Retry after a short delay.

Improved reliability and response times under high load by introducing HTTP connection pooling for calls to the signing backend and connection pooling for the token cache. Under heavy signing traffic this prevents connection exhaustion and reduces per-request latency, making signing operations more consistent for merchants and their end users.

Improved the error message returned to clients when no signing credentials are available. The response now returns a clear "No credentials are available" message instead of an internal diagnostic string, making it easier to handle this case in integrations.

The lang parameter in the CSC authorize flow (GET /csc/v2/oauth2/authorize) is now validated server-side. Only supported language codes (nb, nn, en) are forwarded to the identity provider; any unsupported value is safely ignored and the default language is used instead. This prevents unexpected behaviour when an unsupported language code is passed, and ensures a consistent user experience during the signing flow.

Implemented the CSC API credentials/info endpoint (POST /csc/v2/credentials/info), which returns detailed information about a specific signing credential — including the certificate chain, key parameters, and authorisation settings. Merchants can use this endpoint to retrieve and display credential metadata to the end user before initiating a signing operation, as defined by the CSC specification.