v3.6.x

Changelog

Legend

IconDescription

Improvement upon the Trust1Connector

Bugfix

Story / new feature for the Trust1Connector

v3.6.3

Released 19/08/2022

Release notes

Bug

t1c-sdk-js tries to validate any present consent token when consent is disabled (optional consent)

Improvement

Remove the implicit CORS request from API info endpoint to DS, and provide/expose a public function in JS for application to force a CORS sync

Story

As a dashboard user I want to see how many installation have the DNS rebind issue

v3.6.1

Javascript SDK 3.6.0 has been unpublished and contains a bug in the consent flow where the error code is not returned correctly

Released 01/04/2022

The Mac Silicon (M1) is not yet supported for this version

Release notes

Bug

  • Update consent error codes for 3.6.x so that they do not interfere with other error codes

Improvement

  • As an SDK integrator I want to be able to fetch all the certificates on a token, including their information

  • As a user I want to validate the signed hash from a PKCS11 token, using the validation function of the PKCS11 interface

Story

  • As a user I want ot use Camerfirma token

  • As a user I want to use Chambersign token

  • As a SDK integrator I want to be able to call the TokenInfo enpdoint on PKCS11 tokens

🔺 Consent error code update

The consent error code has been updated in the Trust1Connector API library, and t1c-sdk-js clients have no impact on that change

🔺 Multi-client support and race condition fix

When using different instances of the Trust1Connector (optionally from another partner) on a Windows system, a port collision could be possible due to a race condition in port assignment upon initialization. Ports are now protected with anti-collision and are salted to make a port less guessable.

🔺 Implicit creation of LaunchAgents folder on Mac/OSX

When no LaunchAgents folder was present on the system, the installation procedure creates this folder implicitly.

☑️ Exposed Camerfirma interface

Camerfima is a new PKCS11 token added to the modules of the Trust1Connector. The Camerfirma token pre-requisites the installation of the Carmerfirma middleware.

☑️ Exposed Chambersign interface

Chambersign is a new PKCS11 token added to the modules of the Trust1Connector. The Chambersign token pre-requisites the installation of the Chambersign middleware.

☑️ Token Info endpoint will now returned detailed information when using a PKCS11 token

The token info endpoint has been implemented before only for identity tokens. We have added support for Token Info of the PKCS11 modules. As the response has a different data structure, an additional type has been added for clients to parse the response correctly.

The PKCS11 token info exposes information on the algorithms which can be used for different use cases (digital signature, validation, authentication, ...). In a future release additional functionality will be provided such as: encryption, decryption, key exchange,...

✅ Fetch all the certificates on a token including all their information

For the different notification types, many tokens share multiple certificates for a single type. The original interface supported only a single certificate response. To be backwards compatible, those certification function have been adapted to be behave the same as in v3.5.x.

New functions are available to support multiple certificate reponses, they are called: [certificateType]Extended. For PKCS11 tokens the certificate response also returns, besides the base64 encoded certificate and the certificate id, the following properties:

  • issuer

  • subject

  • serial number

  • hash sub pub key

  • hash iss pub key

  • exponent (payment modules)

  • remainder (payment modules)

  • parsed certificate (ASN1 format of the base64 encoded certificate)

You can find an example for certigna here

✅ Signed hash validation function exposed for PKCS11 tokens

A new function has been added for all PKCS11 modules called the 'validate' endpoint. This endpoint, when available, can be used to validate a signed hash received after calling the 'sign' function. In an next version a variant of the validation function using OpenSSL will be added for all tokens.

✅ PKCS11 migration towards RUST

For the Trust1Connector to support more PKCS11 functionality, the intermediate PKCS11 layer has been removed in preference of a direct PKCS11 LIB integration. FFI is used in RUST to support any library which need to be loaded.

✅ Token Algortihm input validation for signing and authentication

Additional guard has been implemented to prevent empty algorithms for the digital signature and validation endpoints. PKCS11 tokens will verify as well if the provided algortihm is exposed as an allowed mechanism for the targetted use case.

✅ JCOP3 ATR added

The Trust1Connector can now detec Java Card Object Platform 3 typed cards

✅ Select default PKCS11 non-repudation or authentication certificate

When requesting for a signature or an authentication, the correct certificate must be provided. For PKCS11 tokens the certificate id (or reference) can be ommitted. The PKCS11 token will be default pick the first certificate (for the type needed) and use this with the specified mechanism to sign/authenticate.

PreviousTrust1Connector JS SDKNextSetting up the SDK

Last updated