1 of 56

v3.7.x

Introduction

Trust1Connector v3 Documentation

A Word of Introduction

The Trust1Connector Javascript SDK is a library that purely functions as a proxy towards the Trust1Connector API. This Library does not contain any business logic.

Sample code uses ES6 language features such as arrow functions and promises. For compatibility with IE11, code written with these features must be either transpiled using tools like Babel or refactored accordingly using callbacks which are also available on the Trust1Connector Javascript SDK.

Concept

Running the Trust1Connector in a shared environment, such as Citrix, XenApp and Remote Desktop, requires additional installation steps. In this section we explain the concept and approach used.

Architecture Overview

The following schematic seems rather complicated as it explains the inner workings of the Trust1Connector components, the concept is elaborate further on this page. If you are only interested in what the integration impact is for your Web Application in a Shared Environment, you can skip directly to the section: Integration in Web Applications

Components

Web Environment

The Web Application can use the T1C-SDK-JS or a custom REST API client for integration purpose. As the Web Application operates in a browser context, resolving an agent, by means of a consent, will result in a browser cookie being provided.

The T1C-SDK-JS implements the detection of a Shared Environment during the initialisation of the library. When initialisation succeeds without a controlled exception, the setup is a standalone; when the initialisation throws an 401 Error, the T1C-SDK-JS can be used to request the user for a Consent.

When using the REST API directly form your web application, reading the browser cookie and performing the initialisation must be done by the integrating Web Application itself.

Shared Environment Host

Compared to Trust1Connector v2, the v3 release has a separate component to be be installed on a shared host. This component is called the T1C-Proxy and only exposes the following use cases:

Verify random available ports [in a predefined range] which can be used by an Agent (Session of T1C-API running in user space)
Port reservation upon installation of a new T1C-API in an active user session
Port registration upon initialisation of a T1C-API in an active user session
Management of an in-memory list of active Agents
Management of user consents in a shared environment by means of browser cookies with an optional configurable TTL (time to live)

The T1C-Proxy operates by Default on the API port defined in the T1C-DS (Distribution Server). From a Web Application perspective, this is the only information known. When a Web Application requests the information of the device, the PROXY device type will inform the Web Application that the targeted underlying API is a PROXY, which means that the Web Application must ask for the Agent specific API port to configure an URI which can be used to execute the use cases.

When using the T1C-SDK-JS this is done implicitly during initialisation.

Shared Environment Client

A T1C-API installed for a specific users runs in [User Space]. To avoid possible attack vectors, the Trust1Connector v3 will always run in [User Space].

Upon installation of the T1C-API, during the post install phase, the T1C-API will try to verify automatically if it is running in a shared environment. If this is the case, the T1C-API will ask the T1C-Proxy for available ports and will reserve those post, prior to initialisation and startup.

The ports which are reserved by the T1C-Proxy are the following:

T1C-API Port: This is the port exposing the OpenAPI interface towards Web Applications and used by the T1C-SDK-JS

When receiving ports during post-install, an user agent device is temporary RESERVED in the Agent Registry of the T1C-Proxy. Upon T1C-API initialisation, the port configurations will be confirmed and the Agent Registry will set the device state on REGISTERED. From this moment on, a T1C-API instance, running in an active user session, will be available for the Web Application via the consent flow.

The T1C-gRPC instance is inherently a component from the T1C-API, and thus is managed by the T1C-API. As each user must have it's own hardened runtime for communication purpose, the port assigned for T1C-gRPC will be registered and configured by the T1C-API (and restarted when needed).

Central Back-Office

Starting from this release (v3) of the Trust1Connector, each device must have a link with an active and running T1C-DS (Trust1Connector Distribution Server). This is to guarantee security, updates, and avoid potential risk in production.

The T1C-DS is proceeded by an API Gateway who is managing the security offloading in the application layer. For a Web Application to communicate with a T1C-Proxy or T1C-API, a JWT (Json Web Token) is needed and obliged. The T1C-DS is responsible for the key management, the certificate management and other use cases which are described in a separate wiki.

In order to retrieve a valid JWT, the T1C-DS can be requested from your application back-end with a valid api-key. The JWT is valid for a given amount of time, and sets the context used when requesting the T1C-API on a device.

Security

Pin Handling

The PIN handling logic is implemented in the Trust1Connector API. More information on the basic and/or advanced rules can be found on the following link:

Communication Stack

Prerequisites

Trust1Connector API DNS

The Trust1Connector API v3 exposes a secure REST API on the client device. Trust1Team has created a t1c.t1t.io DNS entry (or customer-specific DNS entry) that points to 127.0.0.1 in order to facilitate SSL communication. This means that if the customer infrastructure uses a proxy for all network traffic, an exemption must be made for t1c.t1t.io to always point to the origin device's loopback address. The same holds true for the localhost domain name, this should redirect to 127.0.0.1 on the user's local system, not the localhost of the proxy server.

If no exemption is made and https://t1c.t1t.io is handled by a proxy, it will redirect to 127.0.0.1 IP of the proxy server instead of the local machine, and the Trust1Connector API will be unreachable.

The reserved domain from Trust1Team (t1c.t1t.io) has been registered with DNSSEC on the aforementioned URI. When a PARTNER uses its own DNS, we strongly recommend applying DNSSEC on the domain used in production.

DNS rebind protection

Some (corporate) networks have a policy that disables the ability to bind a domain to a local network IP. The Trust1Connector relies on this for t1c.t1t.io which resolves in to 127.0.0.1 which is a local ip for localhost

If DNS rebind protection is enabled it is unable to use t1c.t1t.io for connection towards the Trust1Connector because the network does not allow this Domain to be a local ip-address.

To resolve the issue either DNS rebind protection can be disabled or you can whitelist the domain t1c.t1t.io to allow this domain.

Applications using the Trust1Connector

Applications that want to make use of the Trust1Connector will be run from a specific domain. This means that the Trust1Connector needs to know that certain domains/applications want to make use of the Trust1Connector's functionality.

For these applications to gain access to the Trust1Connectors API we need to whitelist the domain in whats called the cors list. This list contains all the accepted domains that can make use of the Trust1Connector.

If you want to use the Trust1Connector on a specific domain, please contact our support team to add this domain to the cors list.

Distribution Service

In order to correctly function, the Trust1Connector API must be able to connect to its configured Distribution Service. You must allow REST traffic to the following URLs (if applicable):

Acceptance: https://acc-ds.t1t.io
Production: https://ds.t1t.io

A partner can opt for its own Distribution server, whereas the URIs mentioned above, will be defined by the hosting party.

The option of working without Distribution Service is also possible. You can find all the possibilities to run the Trust1Connector here

In some cases (environments) the Domain acc-ds.t1t.io or ds.t1t.io are not accessable. If this is because the domain cannot be resolved we do recommend to either ask the network/system administrator to make sure that those domains can be resolved on the network. Or changing the DNS server to the google DNS (8.8.8.8 & 8.8.4.4), this has solved the issue for some of our customers.

Disk Space

Keep in mind sizes can vary a bit depending on the Operating system and the environment (develop, acceptance, production)

Windows

Trust1Connector installer is about 20Mb in size. The installed size comes to 40-50Mb.

This includes the Trust1Connector API, Registry and Sandbox.

MacOS

Trust1Connector installer is about 20Mb in size. The installed size comes to 40-50Mb.

This includes the Trust1Connector API, Registry and Sandbox.

The increased size over windows mainly comes to the way MacOS handles dialogs. These are distributed with the Trust1Connector as seperate binaries.

API Key

All endpoints of the Trust1Connector API are secured and require a JWT to access. To obtain a token, an API key must be exchanged.

This API key must be requested from TRUST1TEAM, or created by the customer if they are hosting their own Distribution Service. The API key must never be used in a front-end application (where the API key can be compromised). The API key is needed to exchange the token, using a Distribution Server, resulting in a short-lived Json Web Token.

A PARTNER can decide to distribute a version without the use of a JWT. In those cases, the liability of the security flow resides completely in the context of the web application, thus Trust1Team can not guarantee the security context where the Trust1Connector is integrated upon.

Operating System

Trust1Connector support two operating systems for all tokens, Linux (Debian/Ubuntu) for PKCS11 tokens; On request, a Google Chromebook can be supported depending on the deployment or target installer.

MacOS 11.x or higher
- X86 architecture
- M1/M2/ARM architecture
Windows 810 or higher

Trust1Team support Windows/Mac OSX OS families where lifecycle support is guaranteed from the Vendor of the Operating System. The moment the OS version has been marked as ‘end of life’, Trust1Team can not guarantee the functionality anymore.

When PARTNERS are in need to support an older version or keeping the support running on the level of Trust1Team, no guarantees can be made. Trust1Team can setup a custom project, on demand of the PARTNER. Those requirements, changes or other adaptations needed, are not covered in the Trust1Connector license fee.

Supported OS or platform

Supported

Remarks

Windows 7

EOL but some partners are running a custom compiled target of the Trust1Connector in production until migration.

Windows 8.1

EOL but some partners are running a custom compiled target of the Trust1Connector in production until migration.

Windows 10

Yes

Windows 11

Yes

macOS 10.15 (Cataline)

EOL

macOS 11 (Big Sur)

Yes

macOS 12 (Monterey)

Yes

macOS 13 (Ventura)

Yes

macOS 14 (Sonoma)

Yes*

2023-10

macOS 14 (Sonoma) has issues at the moment with usblib and CCID. A future patch will fix the card reader issues; Updates will be come avaible when a patch is released

Windows 8.1 or higher

To run in user-space on Windows 8.1 or higher some components have to be set on the operating system

Registry keys

Below you can find a list of all registry keys that will be created for the working of the Trust1Connector, All these keys are added to HKCU

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

HKEY_CURRENT_USER\SOFTWARE\Trust1Team\Trust1Connector

Cookies

Since 3.5.x no more cookies are used.

Browsers

The Trust1Connector is browser agnostic so it does not matter what browser is being used as long as it support HTTP communication (HTTP 1.1) (which should all of them).

Version wise we do recommend to use the latest versions of your browser for security reasons but the versions below is was we accept as a minimum

Chrome >80
Firefox >75
Edge 88 or higher
IE 11 (End of Life is June 15 2022)
All other browsers. As recent as possible

Trust1Connector JS SDK

You can find the trust1connector JS SDK for the Trust1Connector v3 via NPM

You can also find the source code here https://github.com/Trust1Team/t1c-sdk-js/tags

Changelog

Legend

Icon

Description

✅

Improvement upon the Trust1Connector

🔺

Bugfix

☑️

Story / new feature for the Trust1Connector

v3.7.11

Release 30/10/2023

Release notes

Bug

T1C-2806 Shared environment - issue with 904300-Signature data does not equal the expected data: reg should not send out the signature in the responses (or verify if the client pub is correctly loaded for REMOTE environments) -> local is not an issue

Task

T1C-2777 Apple al-tool deprecation for signing/notarization

Story

T1C-2560 Direct download of SSL when digest is not equal to the published version on DS

T1C-2808 Add the integration with Local Signing Application

T1C-2809 Sidecar for Certificate check upon start and init

T1C-2810 Add swagger-ui initial set of exposed apis

T1C-2812 Provide an initial openApi spec for LSA module

Improvement

T1C-2638 As an integrator I can ask T1C to digest data before sign for each module

v3.7.10

Release 03/10/2023

Release Notes

Bug

T1C-2710 t1c-sdk-js make excessive failing "pre-flight" requests

T1C-2742 Ds Logs push using CURL has issues -> not sending over the PUT json body

T1C-2747 File exchange list content type on macos sometimes gives read access errors on a just created folder via the API

T1C-2765 SSL certifiicate synchronisation does not happen after first startup

T1C-2804 Update T1C SSL certificates when running binaries from user session, while binaries are located in admin location

Task

T1C-2671 Update notarization in packager, altool being deprecated

T1C-2755 RMCR - Upgrade sentry to latest version

T1C-2760 Document Dashboard setup

Story

T1C-2380 As a User/Support desk I would like to change the log-level (info|debug|warn)

T1C-2652 As a System I need to keep my transactions between installations

Improvement

T1C-2805 Update Cryptoki on Mac/Win for updated PKCS11 drivers

v3.7.9

Released 26/07/2023

Release notes

Bug

T1C-2735 Validate and consent Lock error on mutex should not return invalid consent but should give a propper try again later error

T1C-2780 As a system administator I want to see the transactions of devices - somehow the transactions don't reach the DS

T1C-2788 Prevent the refresh needed when polling during connector update/upgrade

Task

T1C-2733 Add version to the installer

T1C-2778 Upgrade Rust Edition 2021

T1C-2779 Update Clap

Story

T1C-2781 As a connector running on a local device I want to support key rotation from the application consumer

T1C-2782 Update clap to v4 as CLI parser

T1C-2783 Enable insecure for debugging when running in dev mode

T1C-2784 Update the token information returned to the web application to contain a valid type

T1C-2785 Finalise PKCS11 session for each running instance when ending a remote transaction

T1C-2786 Update the PNA specification as an extension on previous release (announced Google Chrome v117)

T1C-2787 Add documentation for ReadMyCards Web Application used for demonstration and showcase

T1C-2790 Upgrade utility libs

T1C-2791 Initial version for an independant debugger

Improvement

T1C-2789 Add tracing events to the connector api and registry

v3.7.7

Released 30/05/2023

Release notes

Bug

T1C-2102 JWT token validation consistently fails due to incorrect device time

Story

T1C-2266 As a DS I need to provide a JWT token based on the time information of the requester.

T1C-2705 Pass through the optional lable from the JWT SUB to the transactions file and DS

T1C-2741 As a system I should be able to send the log files to the DS so that support can easily look for issues with a device

Improvement

T1C-2695 As a client of the T1C API I want the api to validate the JWT token sent before proceeding with the use case

T1C-2696 As a T1C API I want to renew the certificate needed for validation of the JWT when rotation happens on the DS

v3.7.5

Released 18/01/2023

Release notes

Bug

After registering the device a synchronisation needs to happen

v3.7.4

Released 22/12/2022

Release notes

Task

Upgrade compiler version to latest stable

Story

As a system I when installed in a separate folder I want to validate the SSL certificate validity and domain based on the root file

v3.7.2

Released 20/10/2022

Release notes

Story

As a system I should be able to send the log files to the DS so that support can easily look for issues with a device

v3.7.1

Released 20/10/2022

Release notes

Bug

Remove header that was added in 3.7.0 from testing APN (w3c draft) implementation which caused older versions to fail

v3.7.0

Released 19/10/2022

Release notes

Bug

Registry does not retrieve the base cors list on startup
Mutex lock causes Registry and api to go into a deadlock
When the user has a custom date/time set on his System it causes the API to crash on DS communication
Shared environment/multi user setup makes the Registry and API get in a deadlock state
Vulnerabilities based on Penetration test of Connective

Improvement

Use separate endpoint for reg to validate if api is registered on the correct user
As an integrator I can ask for all readers and ask to exclude readers by name

Story

As a system I want to use the private and public device key to encrypt and decrypt the response data so that an integrator/SDK can validate that no man in the middle attack has happened

🔺Mutex

The API and Registry use a feature called Mutexes to have data that can be shared over multiple OS threads. Using this is necessary for some functionality. In previous versions when you have a Shared environment (citrix for example) you could make the API and Registry get into what's called a DeadlockThis caused the Mutex to never be unlocked for use by another OS thread. Causing the connector to be blocked completely.This has now been solved and has been tested on instances of 1000 concurrent devices.

🔺System time out of sync

We had a user which Operating system had a custom date set (not synced) which caused issues with DS communication. The DS communication also checks wether the time of request is not in the future or in the past (with some slack ofcourse). So if you use the Connector with a custom date you will not be able to contact the DS because it requires a request within a correct time-zone.If this is not the case it could be that a malicious user is trying to exploit the DS at which point the DS refuses the request. The issue was that this caused the Connector to crash.This has been solved so that the Connector does not crash.System time must be correct, otherwise DS communication can not be done (secrity issue)

✅ Private Network Access

Private Network Access is a new CORS draft. Which prevents remote servers to contact local instances without any extra checks. Chrome has already implemented this draft in a non-blocking manner, the implemenation of chrome is to send 2 pre-flight requests. One which is the normal pre-flight and another one where the PNA implementation has been done.At this point the pre-flight for the PNA implementation is non-blocking meaning that if the pre-flight fails it will not block the request.When the PNA Cors draft is final this will become blocking.In this release we've already started adding some required components to support this in an upcoming release.

☑️ Sync log files with DS

In this release we've implemented a feature where the Connector will send it's log files towards the DS. This is so that support desks can easily get the log files of the device which is requesting support.

☑️ HTTP verify response signature

We've added a feature where you can run the Connector in regualr HTTP mode. To still be secure we've added a signature field to the responses which can be verified to not be tampered with at the client's side. This verification is implemented in the JS SDK.

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

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.

Core

Setting up the SDK

Include Trust1Connector JS SDK

Include the Trust1Connector JavaScript SDK on your web application. This will provide you with access to the SDK's functions which are used to execute the Trust1Connector's functionality.

From now on we will refer to the Trust1Connector JS SDK to the following variances;

T1C-js/t1cjs
T1C SDK

Using Trust1Connector in as a library

The Trust1Connector is a Javascript Library with TypeScript typings. This can be easily used in any web-application by loading the javacript files on the web-page.

Loading the T1C SDK onto a web-page can be done as shown in the code example below of a html page

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <script defer src="./T1CSdk.js"></script>
</head>
<body>
    ...
</body>
</html>

In the example you can see that we load the Javascript SDK on line 8

<script defer src="./T1CSdk.js"></script>

The defer attribute means that the script will be downloaded in parallel with the rest of the web-page but will be executed when the page has finished loading in.

This is mostly used to make sure that when the Javascript wants to target a specific element on the page, for example a div, that this element has already been loaded and is accessable.

Using Trust1Connector as a module

We also provide an npm package that makes it easier to load and use the Trust1Connector Javascript SDK as a module.

Initialize Trust1Connector

Introduction

For initialisation of the T1C you need to prepare your application first by and importing them in such a way that you can call for the Javascript functions when you need them. When you've succesfully and installed the Trust1Connector you can initialize and use the Trust1Connector

Mode of operations

The Trust1Connector's architecture is created so that we can support a wide range of system setups. This means we can both support single users using the Trust1Connector but also systems where multiple users make use of the same hardware, we call this shared environments.

Additionally to shared environments, we support remote desktops as an extension on shared environments.

Since Trust1Connector version 3.6.1 we can provide integrators the support to initialise the Trust1Connector in different ways.

Please contact support if you need support for this modus. As this is not the default mode and requires the Trust1Connector to be run in a specific context

Using this operation mode, the integrator can decide to use the Trust1Connector and inforce that no consent is needed. making it very straightforward for the end-user to utilise any functionality the Trust1Connector offers.

In this mode we cannot support multiple instances of the Trust1Connector. Meaning shared environments and multiple users logged in on the same system can create unexpected behaviour.

This is the default mode of operation and goes hand-in-hand with instances. A consent is required to both request the user's permission to use the Trust1Connector on his system and also to correctly determine which instance of the Trust1Connector needs to be used.

The Consent provides support to use the Trust1Connector with multiple users on the same system ().

Using Single Instance with consent as an operational mode, enforeces users to consent unregarded the environment - be it single device or multi user environment. Validity of the consent can be determined by the application.

Just like the this mode requires a consent to both ask permission to the user and determine the correct instance of the Trust1Connector Agent/API.

This mode support shared environments such as Citrix, terminal server and remote desktop.

Creating the configuration object

We will prepare the SDK's configuration Object, this object is used to pass information about which default port the Trust1Connector is running on, JWT key, API url, ... which is needed to properly contact and use the Trust1Connector.

When the Trust1Connector is configured with a Distribution Service in mind you can provide a valid JWT token in the configuration object. .

Retrieving JWT tokens should be handled in your own backend to maximize security

Now we can create a complete Configuration Options object to be passed to the Trust1Connector.

T1CConfigOptions

The T1C config options is a class that can be used to create a valid configuration object to initialize the Trust1Connector. Below you can find a class definition.

t1cProxyUrl and t1cProxyPort are deprecated since 3.5.x and only used in 3.4.x versions.

Parameters

t1cApiUrl: string Optional The URL that connects to the local Trust1Connector instances. This can be either localhost or a domain that directs towards localhost. By default this will be https://t1c.t1t.io

t1cApiPort: string Optional The port defined to be used for the Trust1Connector. By default this is 51983

t1cProxyUrl: string Optional - Deprecated The URL that connects to the local Trust1Connector Proxy instances. This can be either localhost or a domain that directs towards localhost. By default this will be https://t1c.t1t.io

t1cProxyPort: string Optional - Deprecated The port defined to be used for the Trust1Connector Proxy. By default this is 51983

jwt: string Optional The JWT token that is used to authenticate towards the Trust1Connector. This should be retrieved from the DS and is only needed when the Trust1Connector is configured to work with a DS and requires JWT validation

applicationDomain: string Optional The domain of the application that is using the Trust1Connector. This is used to make sure the consent is only available for a specific web-application. This prevents various clients to interfere with eachother. This domain also tags the Distribution service transactions being sent to the Distribution service. This makes it easy to distinguish between applications/tags for the transactions

When a remote DS is used you can set the following field with the correct DS url, this will in turn use the DS's capabilities of acting as a Trust1Connector proxy for enchanced security.

Now we can continue to use the config variable to and retrieve a T1CClient

Authenticated client

If you need to set up the Trust1Connector with a valid JWT token you can follow the documentation on the to from the DS.

When you have a valid token you can provide this in the Configuration. This will make sure the Trust1Connector is usable until the token becomes unvalid. At which point you can your token to continue to use the Trust1Connector. More information on how to retrieve,use and refresh a token can be found on the .

Initializing the Trust1Connector SDK

Initialization of the Trust1Connector in many cases requires a user consent, the exception being when no registry is configured (either local or central) and if the Trust1Connector is run in a enabled. More information can be found . The registry allowed us to create a Trust1Connector that works in any environment, without the need for Administrative rights from the users, wether it be Standalone, Multi session, RDP, Citrix, ...

To Initialize the Trust1Connector a is required(when a central or local registry is present) or when the . When no consent can be found the error codes 814500 or 814501 will be thrown. This means that either the previous consent is not valid anymore or no consent was given yet.

More information regarding the consent can be found on the which explains it in more detail.

If you have the enabled the consent error will not appear but will either give a valid Client to use or a 112999 error, depicting it could not find any active instance of the Trust1Connector.

When either no consent is present or its invalid you will receive a invalid client object (line 8 in example above) that can be used to trigger the getImplicitConsent function in the Core serivce.

The Consent requires a user action to . This data is used by the T1C registry to make sure you're targetting the correct instance of the Trust1Connector. More information about this can be found here.

The signature of the getImplicitConsent function is as follows;

This function expects:

codeword: string The string value that is saved to the user's clipboard needs to be sent to the Consent function.

durationInDays: number Optional Amount of days that the consent is valid.

callback: (error?: T1CLibException, data?: T1CClient) Optional Callback when you're not using ES

Below is a small javascript example of how you can trigger the getImplicitConsent function

After this you will have a client that can be used to execute the rest of the functionality that the Trust1Connector has to offer.

Full example

When your instance of the Trust1Connector has the optional consent mode enabled but still want to enforce the consent flow you can use the following explicit consent initialisation.

This will ignore the enabled feature of having the consent being optional and will require a valid consent to operate the Trust1Connector.

Clipboard

To provide a consent, we suggest you use the clipboard functionality available in browsers. The most supported way is via document.exeCommand and below you can find an example of this.

There is also a but this is not fully supported yet

The code below is an example of how you can integrate a copy command in the webbrowser

Retrieve JWT token

GET https://ds.t1t.io/v3_5/tokens/application

This endpoint will return a valid JWT token to use for a certain period based on the API-key you provide in the `apikey` header

Headers

Name

Type

Description

Trust1Connector environments

The Trust1Connector has a Develop, Acceptance and production version. The difference between them is mainly the Distirbution service connection and the port number they use.

These port numbers are linked to the Trust1Connector distributed by Trust1Team. If you have a custom installation these will be different. Please contact your distributor for more information.

The port numbers of the Trust1Connector are;

Environment

Port number

Distribution service

Readers

Introduction

The Trust1Connector after correct initialization has the ability to retrieve the available card readers detected on the system. With these card readers you can continue and execute functionality such as retrieving biometric information, signing data, authentication, ...

Below you can find more information on how to retrieve the available readers. All these functions are available in the

List card readers

Returns a list of available card readers. Multiple readers can be connected. Each reader is identified by a unique reader_id.

The response will contains a list of card readers:

When multiple readers are attached to a device, the response will show all connected card readers:

Important to notice:

The response adds a card-element when a card is inserted into the card reader.
The response contains card-reader pin-pad capabilities

Card Inserted

As mentioned in the List card-readers, when a smart-card is inserted/detected, the reader will contain the cart-type based on the ATR. The ATR (Anwser To Reset), is the response from any smart-card when powered, and defines the card type. The Trust1Connector recognized more than 3k smart-card types.

In the response below you notice that this specific card also includes a module and description property. Both of these are arrays and are also optional. This means that the Trust1Connector recognizes this specific token and knows which module can be used for this token. The Trust1Connector has the possibility to detect that a card can be used by more than 1 module, in that case the module array will display multiple values depicting which modules can be used. The description is purely metadata.

Pin-Pad Capabilities

As mentioned, when a card-reader has pin-pad capabilities, this will be mentioned in the response (notice the pinpadproperty):

List Card-Readers - Explained Example

The following example is the response for List card-readers on a device with 4 different card-readers attached:

When a reader has a smart-card inserted (contact interface) or detected (contactless interface), the card type will be resolved by the Trust1Connector in order to respond with a meaningful type. In the above examples you see that; one card-reader has a Belgian eID card; another card-reader has a MisterCash or VISA Card available for interaction.

Get card readers with card inserted

Returns a list of available card readers with a smart card inserted. Multiple readers can be connected with multiple smart cards inserted. Each reader is identified by a unique reader_id and contains information about a connected smart card. A smart card is of a certain type. The Trust1Connector detects the type of the smart card and returns this information in the JSON response.

Response:

Core Service

Introduction

The Trust1Connector core services address communication functionality with local devices. The Trust1Connector core exposes 2 main interfaces:

interface for web/native applications using JavaScrip/Typescript
REST API as a new approach and to incorporate the Trust1Connector as a microservice in the application architecture

In this guide, we target only the use of Trust1Connector's core interface for web/native applications. The T1C-SDK-JS exposes protected resources for administration and consumer usage.

The JavaScript library must be in order to access the all resource.

Consumer resources

Consumer resources are typically used from an application perspective:

Get pub-key certificate
Get version
Get Information (operating system, runtime, user context, variable configuration)
List card-readers (with active card)
Get card-reader
List card-readers (with active cards)
List card-readers (with or without active card)
Trigger a push of the log files towards the DS

Executing these functionality is explained further.

Core Functionalities

The Trust1Connector functionalities are about secured communication with device hardware. The document highlights communication with smart card readers - contact and contact-less. Other hardware devices can be enabled or integrated as well in the solution. Some of the already are, for example printer drivers, signature tablet drivers, ...

After you've you can execute the rest of the Trust1Connector's functionality, for example listing the readers and fetching information from a specific smart card.

List card readers

Returns a list of available card readers. Multiple readers can be connected. Each reader is identified by a unique reader_id.

The response will contains a list of card readers:

When multiple readers are attached to a device, the response will show all connected card readers:

Important to notice:

The response adds a card-element when a card is inserted into the card reader.
The response contains card-reader pin-pad capabilities

Card Inserted

Pin-Pad Capabilities

As mentioned in the List card-readers, when a card-reader has pin-pad capabilities, this will be mentioned in the response (notice the pinpadproperty):

List Card-Readers - Explained Example

The following example is the response for List card-readers on a device with 4 different card-readers attached:

In the above example you notice that 4 card-readers are connected. Each card-reader receives his temporary id which can be used for other functions where a card-reader id is needed. This method can be requested in order to list all available card-readers, and optional cards-inserted. Each card-reader has a vendor provided name, which is retrieved from the card-reader itself. An additional property pinpad, a boolean value, denotes if the card-reader has pin-pad capabilities. A pin-pad is a card-reader, most of the times with its own display and key-pad. From a security perspective, it's considered best practice to use as much as possible pin-pad capabilities of a pin-pad card-reader. When a reader has a smart-card inserted (contact interface) or detected (contactless interface), the card type will be resolved by the GCL in order to respond with a meaningful type. In the above examples you see that; one card-reader has a Belgian eID card; another card-reader has a MisterCash or VISA Card available for interaction.

The readers returned, are the card-readers with a card available. The card-readers where no card is presented, are ignored.

Get card reader with card inserted

Response:

Get the Javascript SDK version

To retrieve the version of the Javascript SDK you can use the version function available in the CoreService

You can follow the example below to retrieve the version number

The ouput in the log of the code above should look like the following

Get device public key

via the getDevicePublicKey endpoint you're able to fetch the public key information of the device. This requires an authenticated client to be able to access this endpoint.

This endpoint is used in the library to encrypt pin, puk and pace information so that it is not exposed in the network logs of the browser.

Encryption of pin, puk and pace is only possible when the Trust1Connector is registered via a DS and has a valid device key-pair. The SDK will automatically switch to send the pin, puk or pace info in clear text if its not able to encrypt. The Trust1Connector API will also detect if it has no valid device key-pair it will not try to decrypt the incoming pin, puk or pace information.

Push log files

Via the pushLogs function you can trigger the Trust1Connector to send out the log files towards the Distribution service.

Core interface

Downloading latest Trust1Connector

Downloading Trust1Connector

The T1C JS SDK no longer has a method to download the T1C installer.

Instead, the T1C installer can be downloaded by navigating the client browser to the /v3_5/downloads/installer endpoint of the Distribution Service (e.g. https://acc-ds.t1t.io/v3_5/downloads/installer). The Distribution Service will analyse the User-Agent header and automatically initiate the download of an OS-appropriate installer of the latest configured version. The user agent string parsing is considered "best-effort"; as they can vary wildly depending OS and browser software.

Alternatively, you can also initiate the download of a T1C installer with the following endpoints:

/v3_5/downloads/installers/{{OS}}: This endpoint allows you to specify the OS for which you wish to obtain an installer. The possible values are win32, win64, unix, macos macosarm.
/v3_5/downloads/installers/{{OS}}/versions/{{version}}: This endpoint allows you to download a specific version of a T1C installer for a specific OS.

If using the generic endpoint 3_5/downloads/installer

The automatic user-agent detection also does not differentiate between ARM/M1 and Intel Mac devices

Differentiate between MacOS architectures

For MacOS there are currently 2 supported architectures:

ARM64 (M1, ...)
Intel x86_64

Currently, browsers etc do not display which architecture you're running. So in order to provide download links to the users you need to provide them with the option to download any of the 2 architectures. The user needs to decide which platform he is running.

From the DS you can get both links with the following URL's (Production DS is used in the example);

# Intel x86_64
https://ds.t1t.io/v3_5/downloads/installers/macos

# ARM64
https://ds.t1t.io/v3_5/downloads/installers/macosarm

After this, you can provide the user with the choice of which one they want to download. Below you can see an example of how Google does this with their Browser, Google Chrome.

Here you can clearly see they provide two versions, with a recommendation on Intel because the majority of the users still run Intel Apple devices

Distribution services

Below you can find a list of Distribuction services available from Trust1Team. If you are integrating with a 3rd party that uses the Trust1Connector you can contact them for information regarding the Distribution services.

Environment

DS url

Acceptance

https://acc-ds.t1t.io

Production

https://ds.t1t.io

Example upgrade flow

Information below is an example. If the integrator pleases he can alter the flow to their business use-case

Via the Distribution service you can fetch the latest available version. This can be done via the call

curl --location --request GET 'https://acc-ds.t1t.io/v3_5/versions/latest' \
--header 'Authorization: Bearer eyJh...BCr8Q'

This will return all information needed from the latest version, for example our latest version at this point returns:

{
	"success": true,
	"data": {
		"id": "3.6.0",
		"createdOn": "2022-03-21T07:47:48.590425Z",
		"updatedOn": "2022-05-30T10:46:36.532283Z",
		"recommended": false,
		"mandatory": false,
		"allowed": true,
		"visible": true,
		"uris": [
			{
				"os": "MACOSARM",
				"uri": "https://storage.googleapis.com/t1c-dependen....e/trust1team/Trust1Connector-arm.dmg"
			},
			{
				"os": "UNIX",
				"uri": "https://storage.googleapis.com/t1c-depend....trust1team/trust1connector.deb"
			},
			{
				"os": "MACOS",
				"uri": "https://storage.googleapis.com/t1c-dep....Trust1Connector Acceptance-x86.dmg"
			},
			{
				"os": "WIN64",
				"uri": "https://storage.googleapis.com/t1c-depe....t1Connector-Acceptance-x64.msi"
			},
			{
				"os": "WIN32",
				"uri": "https://storage.googleapis.com/t1c-dependenci...ust1Connector-Acceptance-x86.msi"
			}
		],
		"installationApiKey": "6257cbe3-e25a-.....-9fb9-02ad17d1f193"
	}
}

You can check the boolean values mandatory recommended and allowed to determine a pop-up for example, so that the user can download and use this Trust1Connector.

You can also retrieve the same information for a specific version. This endpoint returns the same response type as the latest version call:

curl --location --request GET 'https://acc-ds.t1t.io/v3_5/versions/3.6.0' \
--header 'Authorization: Bearer eyJh...BCr8Q'

In the call above, you can substitute 3.6.0 for the desired version ID

Example screenshot below of our demo-application (rmc.t1t.io)

Below you can find an example of how an version check can be implemented in your front-end application.

Consent

Introduction

The Trust1Connector requires a user consent to function. This consent will be stored in the browsers localstorage for that user.

The consent token is stored with a domain specific key;t1c-consent-{{applicationDomain}}::{{apiUrl}}

When executing the consent flow, the user will be provided with a consent token which can be pasted into his clipboard. This token has to be passed with the Consent function which will perform a verfication (the token pasted in the clipboard - form the application context - should match with the token available on the clipboard for the T1C).

The consent can be configured to have an expiration date, when this expiration date has been exceeded, a new consent will be asked towards the user.

Upon installation of the Trust1Connector, a user will not be able to retrieve any data from the connector without first giving its consent, agreeing to give access to his/her card reader of filestorage. Without this consent, all requests will return a 401/404 Unauthorized response with error No valid consent found or at initialisation of the Trust1Connector SDK an error No valid consent found. The application should detect these errors and use it to trigger the consent dialog.

The application shows this code word on screen and provide a button for 'copy-to-clipboard'. When the user has copied the code word to the clipboard (on user click button event), an implicit consent request can be executed towards the T1C. The T1C will grab the pasted code word from the user system clipboard and if both match, an implicit user consent has been granted for the calling application. The relation between the application and the local T1C instance is 'approved'. At this point the Trust1Connector returns a verified consent object that is stored in the browser's localstorage. This object is used to validate the consent and retrieve the necessary information for the Trust1Connector to function. This object will be re-used the next time the user wants to use the Trust1Connector until the consent expires.

Generating a random clipboard value

The clipboard value is a random value that is used to determine which agent you are running. This clipboard value needs to be pseudorandom so that we dont accidently find different agent.

The Javascript has an exposed function that creates this value for you.

The function is statically available on the T1CClient class and has the following interface.

public static generateConsentToken(): string

This will return the randomly generated value as a string value immediatley.

To call this;

# regular imported javascript via script tag
T1CSdk.T1CClient.generateConsentToken()

# Import loaded via NPM
import {T1CClient} from "t1c-sdk-js";

T1CClient.generateConsentToken()

If you decide not to use this function, the value needs to be prefixed with `::t1c::miksa::

User clipboard remark

Initially the concept was based on copying programmatically the code word, from the application context, to the user system clipboard. Although, through CAB forum, this not allowed; A user interaction is mandatory. The application should provide a 'copy-to-clipboard' button or alike in order to 'trigger' a user action. Once this action has been done, the T1C can be triggered to execute the consent.

Currently, the need for a user interaction is a known limitation (aka. clipboard.js). As this is the case, the W3C has a project ' Clipboard APIs' to propose a solution for a new clipboard API in browsers. The use case for 'Remote clipboard synchronisation' as a use case included in this draft proposal. As this is a draft, and not yet supported by the browsers, we can not perform an automatic 'paste' ('copy' in terms of the browser) to the clipboard.

Sending an implicit consent request can be done as follows:

T1CSdk.T1CClient.initialize(config).then(res => {
    client = res;
    console.log("Client config: ", client.localConfig)
    core = client.core();
}, err => {   
     if(err.code == 814501 || err.code == 814500) {
        console.log(err)
        client = err.client
        $('#consentModal').modal('show', {
            keyboard: false
        });
        $('.consent-token').text(client.core().generateConsentToken());
    } else if (err.code == 112999) {
        // Unavailable
    } else {
        console.error("T1C error:", err)
    }
});

The code below is an example of a javascript event handler on a consent button.

$('#consentModal .btn-primary').on('click', (ev) => {
    const tokenNode = document.querySelector('.consent-token');
    var range = document.createRange();
    range.selectNode(tokenNode);
    window.getSelection().addRange(range);
    try {
        document.execCommand('copy');
    } catch (err) {
        console.log('Oops, unable to copy');
    }
    window.getSelection().removeRange(range);
    const clipboardData = tokenNode.textContent;
    const validityInDays = 365
    
    client.core().getImplicitConsent(clipboardData, validityInDays).then(consentRes => {
        client = consentRes // replace the client and other set variables of the T1C
        core = client.core();
        core.version().then(versionResult => console.log("T1C running on core " + versionResult));
        $('#consentModal').modal('hide');
    }, err => {
        console.error(err)
    })
});

This call has 1 required and 2 optional parameters:

Code Word (required): a code word in string format that will be shown in the consent dialog.
Consent duration in days (optional): Allows the application the specify how long this consent is to be valid if granted. If not provided, the default value is 365 days.
Callback function (optional): function to be called with the result of the consent request.

The response of the consent will be an updated T1C Client which you after this point can use to continue your use-case(s).

The response can also be a 400 Bad Request with status code 814501 "Invalid consent" or 814500 "No agents registered" which means that the request has been sent with the unique code but the Registry cannot not find the user associated with it by checking the clipboards of all connected users.

This could mean that there is no T1C API client present or it is not running correctly.

Authenticated client

Introduction

The Trust1Connector API requires a valid JWT token to be provided in the Authorization header. This JWT token can be retrieved by asking the Distribution Service to generate a token for a specific API-key. It is important that this API-key is not exposed in the front-end application as this is a security violation.

When you've received a valid JWT token from the DS you can provide this into the configuration object when initialising the Trust1Connector JS client.

When using the Trust1Connector Javascript SDK the Authorization header is automatically populated with the JWT provided while initialising.

When the Token has expired there is a function which you can call to provide a new token and which will in turn return an updated client to be used.

Retrieving a JWT token

Retrieving a valid JWT token happens via the DS. When passing a valid API-key to header of the endpoint {{ds-url}}/v3/tokens/application (GET) you wil in turn receive a valid JWT token.

Example response

Refresh JWT token

Refreshing the JWT token can only be done after a first successfull initialisation of the Trust1Connector. This means the Trust1Connector has to be initialised with a valid configuration the first time. When the token expires after first successfull initialisation you can use the refreshJWT function described below

A JWT token is only valid for a certain period. After this period the API will return an error. At this point you need to request a new JWT token to be able to communicate with the API.

In the T1C JS SDK there is a function which you can use to re-initalise the client with a new valid JWT token. This should be done when you receive a 104025 error-code which means you do not have a valid JWT

The updateJWT function can be found in the Core service. After initialising you can retrieve the core as follows:

The function's interface is as follows;

This function returns an updated client which you can continue to use for your desired use-cases.

Distribution services

Module/container setup

Introduction

This document will describe how you can set up your desired module or generic module for using the functionalities that each module have. This ofcourse requires you to succesfully initialized the Trust1Connector via or and have a

Initialize your module

When the user has selected his desired reader to use we can continue to initialize the module to use. This requires at least the readerID to properly initialize.

Some modules like the LuxID module require you to also add a additional pin and pinType for example, this will also need to be provided in the module initialization.

To initialize a module we first need the client as described in the introduction, here's a quick happy flow of how to retrieve a T1CClient

When we have the T1CClient we can use this to choose our module. We can also use the generic interface if we want.

the reader_id is the identifier which can be retrieved from the

Base module initialization

Below is an example of how to iniailize the Belgian EID module. This is a specific module that has all the functionalities for the Belgian EID card. You can see we use the client to fetch an instance of the beid module which we can further use to execute any functionality exposed on the beid module.

now we can use this to for example fetch all the available token data;

Generic

Generic Token

Ofcourse we can also use the generic interface which has all the functions exposed that you can use for all the modules.

This will require you to always provide the module when you call any of its functions. Because it still needs to know which commands it needs to send to the card/token.

When we now want to execute a getAllData for beid we would call it like this;

Generic is split up in 2 different generic modules. This is because the payment modules differ to much from the regular tokens.

Generic Payment

To initialise a generic payment module its very similar to the token version but the available functions will differ.

When we now want to execute a readData for emv we would call it like this;

Interfaces

Below you can find an overview of the generic interfaces. This shows what functions are available on both. If you want more information about a specific token/module you need to go to their respecitve pages which will explain more in detail what you can do with them.

Generic Token interface

Generic Payment interface

Available modules

Below is a list of the available modules;

generic
paymentGeneric
fileex
rawprint
beid
remoteloading
emv
crelan
aventra
oberthur
idemia
luxeid
wacom
diplad
certigna
certinomis
dnie
safenet
eherkenning
jcop
airbus
luxtrust
camerfirma
chambersign

Functions

these are the exposed functions available on the T1CClient to initialize a module

Status codes / error handeling

Introduction

In the Trust1Connector V3 we've completely reworked the error system. The goal of this system is to have error codes which are easy to read, understand and integrate. Our first implementation was a very generic approach with as few error codes as possible.

After some iterations of the Trust1Connector we've discovered that the old error system did not suffice the needs of integrators. So we've upgraded the system to be more consistent and extensive. This provides integrators the flexibility to have a very detailed error handeling system while keeping it easy to understand and read.

The new system provides information about the origin, type and detailed information of the error. We maintained the same type (integers) as our previous error codes, this makes it easier to differentiate them.

Status Codes

T1C uses response codes when handling a request.

In case of an error the response will contain a body with more detailed information about the error:

Error format

Error codes will be in the following number format XXXXXX for example 201010 is an error code that depicts an error occurred with the reader in the Transaction service.

The first digit depicts the Origin of that error, values can be the following;

The following 2 digits describe the type of error;

Finally we have 3 digits that give a more detailed error. These will give you more information about the specific error-case. Currently we have the following exceptions that can be thrown.

Codes to expect

The following list are codes that you can expect.

General / Controller

Aventry My Id 4

Oberthur 7.3

Idemia cosmo 8.2

BeID

Diplad

Luxtrust

Luxeid

EMV

Crelan

File exchange

Error codes coming from v2

Simple error handeling

The most simple way you can check the error codes is by only taking into account the latest 3 digits. The first 3 digits provide information about the Context and environment

Quick-Migration Guide (v2 -> v3)

Introduction

When you already have a V2 integrated this page will provide you with some easy steps to quickly migrate to the V3 of the Trust1Connector. Migration from the v2 to the v3 of the Trust1Connector can be done in 2 ways;

Integration of the API
Integration via the deprecated Javascript SDK

Both are viable integrations. When integrating via the API you have more control over the functionality and the dependencies used.

Update a v2 application to v3

For updating your web application first of all you need to use the new Javascript SDK. After this there are some differences in using the SDK from the v2.

Configuration

The configuration from the v2 has changed, we simplified this.

The v2 had the following configuration options;

With the v3 this is significantly simplified to the following;

Initialisation

After you've created your configuration object you can do the initialisation of the Trust1Connector SDK. This has largely remained the same except for the error codes.

V2 example:

V3 example;

For more information regarding initialization we suggest the

Token

Token typing models

Introduction

This page describes all generic token models used.

Models

export class ModuleDescriptionResponse extends DataObjectResponse {
  constructor(public data: TokenModuleDescription, public success: boolean) {
    super(data, success);
  }
}

export class TokenCertificateResponse extends T1CResponse {
  constructor(public data: TokenCertificate, public success: boolean) {
    super(success, data);
  }
}


export class TokenCertificate {
  constructor(
      public certificate?: string,
      public certificates?: Array<string>,
      public certificateType?: string,
      public id?: string,
      public parsedCertificate?: Certificate,
      public parsedCertificates?: Array<Certificate>
  ) {}
}

export class TokenAddressResponse extends DataObjectResponse {
  constructor(public data: TokenAddressData, public success: boolean) {
    super(data, success);
  }
}

export class TokenPictureResponse extends DataObjectResponse {
  constructor(public data: TokenPictureData, public success: boolean) {
    super(data, success);
  }
}

export class TokenVerifyPinResponse extends DataObjectResponse {
  constructor(public data: TokenVerifyPinResponseData, public success: boolean) {
    super(data, success);
  }
}

export class TokenVerifyPinResponseData {
  constructor(
      public verified: boolean
  ) {}
}

export class TokenSignResponse extends DataObjectResponse {
  constructor(public data: TokenSignResponseData, public success: boolean) {
    super(data, success);
  }
}

export class TokenSignResponseData {
  constructor(
      public data?: string
  ) {}
}

export class TokenAuthenticateResponse extends DataObjectResponse {
  constructor(public data: TokenAuthenticateResponseData, public success: boolean) {
    super(data, success);
  }
}

export class TokenAuthenticateResponseData {
  constructor(
      public data?: string
  ) {}
}

export class TokenModuleDescription {
  constructor(
      public desc: string
  ) {}
}

export class TokenAddressData {
  constructor(
    public municipality?: string,
    public rawData?: string,
    public signature?: string,
    public streetAndNumber?: string,
    public version?: number,
    public zipcode?: string
  ) {}
}



export class TokenAllDataResponse extends DataObjectResponse {
  constructor(public data: TokenAllData, public success: boolean) {
    super(data, success);
  }
}


export class TokenAllData {
  constructor(
    public picture?: TokenPictureData,
    public biometric?: TokenBiometricData,
    public address?: TokenAddressData,
  ) {}
}

export class TokenPictureData {
  constructor(
      public picture?: string,
      public signature?: string,
      public width?: number,
      public height?: number,
  ) {}
}

export class TokenData {
  constructor(
      public rawData?: string,
      public version?: string,
      public serialNumber?: string,
      public label?: string,
      public prnGeneration?: string,
      public eidCompliant?: string,
      public graphicalPersoVersion?: string,
      public versionRfu?: string,
      public electricalPersoVersion?: string,
      public electricalPersoInterfaceVersion?: string,
      public changeCounter?: number,
      public activated?: string,
  ) {}
}

export class TokenDataResponse extends DataObjectResponse {
  constructor(public data: TokenData, public success: boolean) {
    super(data, success);
  }
}

export class TokenBiometricData {
  constructor(
    public birthDate?: string,
    public birthLocation?: string,
    public cardDeliveryMunicipality?: string,
    public cardNumber?: string,
    public cardValidityDateBegin?: string,
    public cardValidityDateEnd?: string,
    public chipNumber?: string,
    public documentType?: string,
    public firstNames?: string,
    public name?: string,
    public nationalNumber?: string,
    public nationality?: string,
    public nobleCondition?: string,
    public pictureHash?: string,
    public rawData?: string,
    public sex?: string,
    public signature?: string,
    public specialStatus?: string,
    public thirdName?: string,
    public version?: number,
    public issuer?: string
  ) {}
}

export class TokenBiometricDataResponse extends DataObjectResponse {
  constructor(public data: TokenBiometricData, public success: boolean) {
    super(data, success);
  }
}

export class TokenAlgorithmReferencesResponse {
  constructor(public data: TokenAlgorithmReferences, public success: boolean) {
  }
}

export class TokenAlgorithmReferences {
  constructor(public ref: Array<string>) {
  }
}

export class TokenResetPinResponse {
  constructor(public data: TokenResetPin, public success: boolean) {
  }
}

export class TokenResetPin {
  constructor(public verified: boolean) {
  }
}


export class PinType {
  static PIN = 'Pin';
  static CAN = 'Can';
}


// Requests
export class TokenAuthenticateOrSignData {
    constructor(public algorithm: string, public data: string, public pin?: string, public pace?: string, public id?: string, public osDialog?: boolean, public txId?: string, public language?: string, public base64Encoded?: boolean, public timeout?: number) {
    }
}

export class TokenVerifyPinData {
    constructor(public pin?: string, public pace?: string, public osDialog?: boolean, public base64Encoded?: boolean, public timeout?: number) {
    }
}

export enum TokenResetPinReferenceType {
    issign = "issign",
    isauthenticate = "isauthenticate",
    isencrypt = "isencrypt"
}

export class TokenResetPinData {
    constructor(
        public puk: string,
        public pin?: string,
        public resetOnly?: boolean,
        public osDialog?: boolean,
        public reference?: TokenResetPinReferenceType,
        public base64Encoded?: boolean) {
    }
}

export class PaymentVerifyPinData {
    constructor(public pin?: string, public osDialog? :boolean, public base64Encoded?: boolean, public timeout?: number) {
    }
}

export class PaymentSignData {
    constructor(public txId: string, public language: string, public data: string, public timeout?: number) {
    }
}


export class TokenCertificateExtendedResponse extends T1CResponse {
  constructor(public data: TokenCertificateExtended, public success: boolean) {
    super(success, data);
  }
}


export class TokenCertificateExtended {
  constructor(
    public certificates?: Array<T1CCertificate>
  ) {
  }
}


export class T1CCertificate {
  constructor(
    public certificate?: string,
    public certificateType?: string,
    public id?: string,
    public subject?: string,
    public issuer?: string,
    public serialNumber?: string,
    public url?: string,
    public hashSubPubKey?: string,
    public hashIssPubKey?: string,
    public exponent?: string,
    public remainder?: string,
    public parsedCertificate?: Certificate
  ) {
  }
}

Generic token

Introduction

The Generic token interface is an interface used to integrate all supported tokens. This interface relies on the fact that you will need to provide a valid module. The module suggested from the reader response can be used here.

Interface

export interface AbstractEidGeneric {
  allData(module: string, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllDataResponse) => void): Promise<TokenAllDataResponse>;
  allCerts(module: string, parseCerts?: boolean,  filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsResponse) => void): Promise<TokenAllCertsResponse>;
  biometric(module: string, callback?: (error: T1CLibException, data: TokenBiometricDataResponse) => void): Promise<TokenBiometricDataResponse>;
  tokenData(module: string, callback?: (error: T1CLibException, data: TokenInfoResponse) => void): Promise<TokenInfoResponse>;
  address(module: string, callback?: (error: T1CLibException, data: TokenAddressResponse) => void): Promise<TokenAddressResponse>;
  picture(module: string, callback?: (error: T1CLibException, data: TokenPictureResponse) => void): Promise<TokenPictureResponse>;
  rootCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  intermediateCertificates(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  authenticationCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  nonRepudiationCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  encryptionCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  issuerCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;

  allCertsExtended(module: string, parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
  rootCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  intermediateCertificatesExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  authenticationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  nonRepudiationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  encryptionCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  issuerCertificateExtended(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;

  verifyPin(module: string, body: TokenVerifyPinData, callback?: (error: T1CLibException, data: TokenVerifyPinResponse) => void): Promise<TokenVerifyPinResponse>;
  authenticate(module: string, body: TokenAuthenticateOrSignData, callback?: (error: T1CLibException, data: TokenAuthenticateResponse) => void): Promise<TokenAuthenticateResponse>;
  sign(module: string, body: TokenAuthenticateOrSignData, bulk?: boolean, callback?: (error: T1CLibException, data: TokenSignResponse) => void): Promise<TokenSignResponse>;
  signRaw(module: string, body: TokenAuthenticateOrSignData, bulk?: boolean, callback?: (error: T1CLibException, data: TokenSignResponse) => void): Promise<TokenSignResponse>;
  allAlgoRefs(module: string, callback?: (error: T1CLibException, data: TokenAlgorithmReferencesResponse) => void): Promise<TokenAlgorithmReferencesResponse>
  resetBulkPin(module: string, callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;
}

Models

All model information can be found in the Token typings model page

Initialise the Trust1Connector JS

Initialise a Trust1Connector client with a valid configuration:

T1CSdk.T1CClient.initialize(config).then(res => {
    client = res;
}, err => {
    console.error(error)
});

Obtain the Reader information

In order to get all connected card-readers, with available cards:

var core = client.core();
core.readersCardAvailable(callback);

This function call returns:

{
  "data": [
    {
      "card": {
        "atr": "3B9813400AA503010101AD1311",
        "description": ["Belgian eID Card"]
      },
      "id": "57a3e2e71c48cee9",
      "name": "Bit4id miniLector",
      "pinpad": false,
      "suggestedModule": "beid"
    }
  ],
  "success": true
}

As you can see in the response we get a property suggestedModule which is returned based on the card, reader and AID information. This suggested module can be used in the generic interface.

Using the generic interface can be done as follows;

var generic = client.generic(selected_reader.id, pin, pinType);

The pin and pinType are optional and are used for unlocking the pace layer (if the card is protected with a pace layer).

At this point for each use-case you will need to provide the module. This can be manually defined or be retrieved from the suggestedModule property in the reader-response. In the examples below we provide the module as a variable module

Cardholder Information

The card holder is the person identified using the Belgian eID card. It's important to note that all data must be validated in your backend. Data validation can be done using the appropriate certificate (public key).

Biometric data

Contains all card holder related data, excluding the card holder address and photo. The service can be called:

generic.biometric(module, options, callback);

An example callback:

function callback(err,data) {
    if(err){
        console.log("Error:",JSON.stringify(err, null, '  '));
    }
    else {
        console.log(JSON.stringify(data, null, '  '));
    }
}

Response:

{
 "birthDate": "15 JUL  1993",
 "birthLocation": "Roeselare",
 "cardDeliveryMunicipality": "Avelgem",
 "cardNumber": "592..8233",
 "cardValidityDateBegin": "27.05.2015",
 "cardValidityDateEnd": "27.05.2025",
 "chipNumber": "U0xHk...EstwAjEpJQQg==",
 "documentType": "01",
 "firstNames": "Gilles Frans",
 "name": "Platteeuw",
 "nationalNumber": "930...154",
 "nationality": "Belg",
 "nobleCondition": "",
 "pictureHash": "Fqva9YCp...JKyn8=",
 "rawData": "AQw1OTIxMjQwNTgy...TARFBar2vWAqTW+axEIuyskBgFySsp/",
 "sex": "M",
 "signature": "hKys9WMjUm4ipg...14xUCg/98Y9/gP/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
 "specialStatus": "0",
 "thirdName": "J",
 "version": "0"
}

Address

Contains the card holder's address. The service can be called:

generic.address(module, callback);

Response:

{
 "municipality": "Hoeselt",
 "rawData": "ARJLZXJrc...AAAAAA==",
 "signature": "mhPyeRg25H...w==",
 "streetAndNumber": "Kerkstraat X",
 "version": "0",
 "zipcode": "3730"
}

Picture

Contains the card holder's picture stored on the smart card. The service can be called:

generic.picture(module, callback);

Response:

{
  "data": "/9j/4AAQSkZJRgABA...59aVpcklSDzyKUTEDGK//9k=",
  "success": true
}

Token info

The token info contains generic information about the card and it's capabilities. This information includes the serial number, file types for object directory files, algorithms implemented on the card, etc.

Response

{
  "data": {
    "eid_compliant":48,
    "electrical_perso_interface_version":0,
    "electrical_perso_version":3,
    "graphical_perso_version":7,
    "label":"BELPIC",
    "prn_generation":4,
    "raw_data":"MCcCAQAEEFNMSU4z...JFTFBJQwMCBDCeBAcDAAA=",
    "serial_number":"534C494E..1231C",
    "version":0,
    "version_rfu":0
    },
    "success": true
}

Certificates

Exposes all the certificates publicly available on the smart card.

Extended certificates

You can also fetch the extended versions of the certificates via the functions

allCertsExtended(module: string, parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
rootCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
intermediateCertificatesExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
authenticationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
nonRepudiationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
encryptionCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
issuerCertificateExtended(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;

this has the capabilities to return multiple certificates if the token has multiple of this type.

for a single certificate the response looks like:

{
    "success" : true
    "data" : {
        "certificates": [{
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        }]
    }
}

the allCertsExtended returns the following, with the contents of the certificates as the one you can see above;

{
    "success" : true
    "data" : {
        "rootCertificate": {
            "certificates": [...]
        },
        "authenticationCertificate": {
            "certificates": [...]
        },
        "nonRepudiationCertificate": {
            "certificates": [...]
        },
        "intermediateCertificates": {
            "certificates": [...]
        },
        "encryptionCertificate": {
            "certificates": [...]
        }
   }
}

Root Certificate

Contains the 'root certificate' stored on the smart card. The root certificate is used to sign the 'citizen CA certificate'. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not. The service can be called:

generic.rootCertificate(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

You can also fetch the root certificate via the function rootCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

Authentication Certificate

Contains the 'authentication certificate' stored on the smart card. The 'authentication certificate' contains the public key corresponding to the private RSA authentication key. The 'authentication certificate' is needed for pin validation and authentication. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:

generic.authenticationCertificate(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

You can also fetch the root certificate via the function authenticationCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

Intermediate Certificate (citizen)

Contains the citizen certificate stored on the smart card. The 'citizen certificate' is used to sign the 'authentication certificate' and the 'non-repudiation certificate'. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:

generic.intermediateCertificates(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

You can also fetch the root certificate via the function intermediateCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

Non-repudiation Certificate

Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:

generic.nonRepudiationCertificate(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

The response looks like:

You can also fetch the root certificate via the function nonRepudiationCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

Encryption Certificate (RRN)

Contains the 'encryption certificate' stored on the smart card. The 'encryption certificate' corresponds to the private key used to sign the 'biometric' and 'Address' data. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:

generic.encryptionCertificate(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

You can also fetch the root certificate via the function encryptionCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

All certificates

generic.allCerts(module, parseCertsBoolean, callback);

Response:

{
 "rootCertificate": {
 ...
 },
 "authenticationCertificate": {
 ...
 },
 "nonRepudiationCertificate": {
 ...
 },
 "intermediateCertificates": {
 ...
 },
 "encryptionCertificate": {
 ...
 }
}

You can also fetch the root certificate via the function allCertsExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "rootCertificate": {
            "certificates": [...]
        },
        "authenticationCertificate": {
            "certificates": [...]
        },
        "nonRepudiationCertificate": {
            "certificates": [...]
        },
        "intermediateCertificates": {
            "certificates": [...]
        },
        "encryptionCertificate": {
            "certificates": [...]
        }
   }
}

Data Filter

Filter Card Holder Data

All data on the smart card can be dumped at once, or using a filter. In order to read all data at once:

var filter = [];
generic.allData(module, { filters: filter}, callback);

Response:

{
 "picture": {
  "picture": "/9j/4AAQSkZJRgABAgEBLAEsAAD/.../wAALCADIAIwBAREA/8QA0gAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/2gAIAQEAAD8A9JpKKWiikooooopaKSilooooopKr3d9bWaFriVEwM4J5Ncjq3jUxkixQADozjJNcze+L9WndWF20OOCI/lzRb+KtYjhIN67Z7vyf1qT/AIS3Wc5F2OnQgY/lWrovjC7hYLqJ86IkksPvCustPEumXbbUuAjYzh+K1UkWRA6MGU9CDkGn0UUUUUUUhOBk8CuY1zxOls/kWjbnH3pAMgewrz7VtWmu7gvJIzZ65NZk1wSBjOagWbn5lB+vagy7+2KlilUE7eRj1qS3ncSEE4X3qwzNs81Dgg9K19G8VXumTLFv8yDOWjb+len6bqMGp2qz2zZU8Ed1PpVyiiiiio5pkgiaSRgqKMkmuH8ReKXlMlpAAkHRnB5b29q4+e5HzAHjPFZkoLyhevH6014XUcjBqAow5xQEYjFPClDxkCnq20AkZ/xqyl2oUK4xu6n0qwgguZQ28K2Ofc1v6Pqs2lSRGJzsLAOv94d69MtriO6gSaFgyMMg1LS0UUlcn491FbfS/sicyzEH6AGvOCzuApPOakt7CWYk7TjNXE0iUNnyyfpVqPQ53XiNwPepYfDMhb94GAq5/wAIzbhc4IPpVK/8OYjzEMmsWbRZ0XIUnHtVRrR4/vqR9RSwQGXdt4Zav2rbFww6DI5ruvBuqIIjaSuMu2Y8/TpXYUtFFIa8r8W6h9v1d9mCqHYuO4FVdM0t7iZWb8a6y10+KNQCOlXFijQfKop6g9hUmw4pjoRzmopEyvIqrJEjDGKpXGnwzoQ68+1YNxpv2Ry8RPHrVGUqse4MN38Qq7o8o8kOh+dG3AjsRXpejapHqVsDkLMo+dM8/WtOiis/WrxrHTJp1GWAwOeme9eWqqzTln6k5rqNLhWKFcDmtJRk1aSPPWp0i21J5dRSx8VWKVXkQA1WmwvGDzWVegSRsp4zXNT2WwMASSxqa1kNimMBkOB9fWt7QLx4ddgaNCyyLtIHevR6Wiuf8ZsRobAdWcD+dcLYQZlHck/lXWQKEjUVZj69OlXI+manXnvTiADioXPJ4qBhVaQ/NVWbkZ7VlXeDmqRYY27Rn1rOmkDXOwKBgH8av6XOba9guVz8hA2+1epg5GaWiuf8ZqTom4fwyKf5iuS0uFiQcV0MYwgBqxH1FWl6VLGeKcxOOaaRmoZAcVTkBqrOcL61j3B5NVgducVXkeOOXLKMt1p9tIsyjaAMGvVI+I1+gp9FZXiOAT6LcKRnaN35Vy+lhfKJ9Kv+cifeYACpIry3A5kA+tW1uYmXKuD+NSRzDseKl3gjrTS47UhYAGqFxINxqhcSA8ZrPlQmq8kZArNujljkdBUuhAy3cUOOWdRXrY4FLRUN0iSW8iSkBGUg5riLGMrbzxq3IkI3CozpuWZmnkye+6qT6TlmPnkk9M1Smsbq3OUuOOvWtDTrq4j+V5CRn1rpIZy6ZNSbiBz1qneXphFcpqmqzyNiJiBnqKyl+33DDZJL9dxq2i6pDg7mYehNX7a/lx5d5EADwGHUVBeR/MfT2q/4It2n10vtykY3H29K9MpaSsLxKJJo4oI5Ci53NjvWbbweUGAH3sE5qG8DpnqB7CsKNru7umitUKgdXbqay3m1L7cluxlMm/DAqMYrqLfTW5DKAw7joa1LRCnDVNelYo91cXq13NcMfLDbAcA+tVbXTppyzMrNtGSq9RTP7VhgZY44HBP+1k1Zi1LzZNgbOexGCKS8kwQcc1LM4ayeT0Sl8M+IhpDzfuA4kwCe+BXqFldxXtrHcQnKOMjNWKSsfV48zI3qMVVwpIA5xxTpI1bqBVNrRQ25EwfVaja3cybtgz/eK81ahjKrz1pTwR6k1U1aQ/Zm57VhQKDGhAyBWxatHACUXbuHOO9Yt3plol01wkWSTnGazLixaW5EsSbSO4q5HZu6Ey9R0qLUQYNOcdA3FY1vGS4wK9f8NQtBolurdSC2PrWtRWfqoHlI3cHFZUXJJ9TU3U4xxTguKdsyM1FINtQNjcKpauC1uwHORWLYsAAhPStqOPKAjoaHhU8Fc1G0KDouKgmUBTisDXCTBGoxgtk1W02AysoUclgK9it4hDBHGOiKFqWiqWppvtT7EGsgKoGVJB7ip161KoWlY4qrctjGOpqCJd74JqLUlVYic8YrlI22ySSKehzXUWDCa2RxzkVaaMVUnXaDWXdzBVIzziuf1Pc80MS9x1rd8Maa39qxRucqhDtj2r0elopkiCRGRuhGKxJreaFipQlB/EBTA2Dih5tg4ySeAKlUnbufr6VBOpkBA4PassR3NtIZJJ/MB/h24xWDr+rySYihU+/NZULXMkXlrHyepFdfoYaG1RG5IFa7yZTIrNv5gqHmudnn3zgdeazrjL3+7PyggV6J4QgY28ly643YRT64610tFFJTXXcjL6jFc+/BIP8ACcUKoEm888YFI13GuVkbafehZ4uu8UOYpVwGGazp9KtmYs2AfempZQx524pyusRAyKkEuXU9jxWNrUxUsnc1k26F50U9WIFd1F4N08XCzu0rdCUJ4Jro0RY0VEUKqjAA7U+iiikrCvV2Xki9ic1BExDYPOKL6xhvIdrqM9j6VjmwNuNiu6/8CzUiW0uw73bOOCADVO7hulGRIxY9iOKy5RfgnbKB+NLZWWp3EwMtwBHnPU8106xrFGiZzt5JNcpqdyLnVWVOUU81a0GL7TrdsmMgOCfoDmvUaWiiiikrM1aHlJh0HBrNBAcZqcnH0qJ1EnBGaqvGy/dPFU51mfv+tVRaNnLc/Wp0cRLgHmqup35hs2AJ8xxgYrBijKRlm+8eSa6nwLbbryW4b+EYFd5RRRRRRVXURmxlz7fzrmDJ820noavoQ0WCcmlQZpXjBGarMijpzVedBtJNZczbSTmsW6k864BY/Kvaomk3sFB4rtfBO398F6BcV19FFFFFFVr/AJs5fpXLXEJK716imWt5tOxzir6Tqe9JLcAcbhUTTrt4Iqhc3IOQGrA1C/CcZ56VkPOzHr1p0JZ32r07mu/8ELsaYZ5K5rsKKKKSloqtfnFnL9KwkAP41Qv7I53R9ax5ri5tzhg31qm+qzdDzUb6zKBjAqlNqkrZxwTWe8jSOSSSalhiaRgO1a1tAsYA711/hA7bpx6qa7CikpaSio1njZioYZHWs/UdQtmhlgjnjeUYyinJHPes2M5HNPYDbiqr28cvyuoIqjceH7eQ5AI+lZ0vhyME4Z/zqjPoiRZ5aqBslRulXbe3woOKtLGc8itvQJxbXqseh4NdRPqaxpujjMnqAcYHrToNShlAz8h96mkvLeJQ0k8aKe7MBT0uIZF3JNGy+qsCKqajfx2gUFvmJ6ZrB1HxUkSttIGOOtcpfeK5jC8dsxDP1f0+laehxeVp8cjcyTfOxPU1uRmpm6VAchqkEmKjkcYz0rJvGDZrJMe+Tgd6vRwbU6UpTBqS1O2ZT71vRkSJtakaARITyy+3UVyXiXUTvijEqugB+6en1rJi1AqmN7D6Gut8S61a6XKipbieSRSSXPSuBv8AUZbyQlwFXP3VGAKp7q9B0OTzdLtG/wBnH5VtR1Z6ionXnIprDI6VWkjB/i5qnPCMHAqCCAeZyKutGoWqsvBqOM4cH3rcgOQKvRNxisbxB4ettQgaZcRToM7gOv1rgEvzAvl+VE+D1K1//9k="
 },
 "biometric": {
  "birthDate": "15 JUL  1993",
  "birthLocation": "Roeselare",
  "cardDeliveryMunicipality": "Avelgem",
  "cardNumber": "592124058233",
  "cardValidityDateBegin": "27.05.2015",
  "cardValidityDateEnd": "27.05.2025",
  "chipNumber": "...==",
  "documentType": "01",
  "firstNames": "Gilles Frans",
  "name": "Platteeuw",
  "nationalNumber": "...",
  "nationality": "Belg",
  "nobleCondition": "",
  "pictureHash": "...=",
  "rawData": "...+axEIuyskBgFySsp/",
  "sex": "M",
  "signature": ".../OlA44h4YCM/h+J14xUCg/98Y9/.../C/RB2dtVbHwFvDuafmr4ZEshTlZTLidHKlISFvFWOtsLAEPCbl5LjfQwcOKe0pDADtHb4IStBnr+aaE8oHsTaKq66Y+zt+AbwdmWOrMA5URKKf7dZkY7jt3h8KZDw36VjcytUgjxVIdqwHsDkmIjK6mJtakIwybS5wn3RiQj33/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
  "specialStatus": "0",
  "thirdName": "J",
  "version": "0"
 },
 "address": {
  "municipality": "Hoeselt",
  "rawData": "...==",
  "signature": "...+Evety1PnTE4pqXaHgBxIpk+P8kRL5W3zDV+../../..+YoHBC9KqTmSpl5KULxdnKiyCt+2RyJdzE2wyoymjRmysIhJy1wW9PRnx99S1TFqQLuc0tyBmkBPR4aFqmOq4a7zqd0q2Q1g+BbnwJ4d3oa10ia5+0kBXf0THoXv3HYIHlnwhBMfAtWzPnFrYBuAKTwyl7yBF5IFfXFpGWuVZUTJElgNcmNvsHMnAhVwDw==",
  "streetAndNumber": "Kerkstraat X",
  "version": "0",
  "zipcode": "3730"
 }
}

The filter can be used to ask a list of custom data containers. For example, we want to read only the biometric data

var filter = ['biometric'];
generic.allData(module, { filters: filter }, callback);

Response:

{
 "biometric": {
  "birthDate": "15 JUL  1993",
  "birthLocation": "Roeselare",
  "cardDeliveryMunicipality": "Avelgem",
  "cardNumber": "592124058233",
  "cardValidityDateBegin": "27.05.2015",
  "cardValidityDateEnd": "27.05.2025",
  "chipNumber": "...==",
  "documentType": "01",
  "firstNames": "Gilles Frans",
  "name": "Platteeuw",
  "nationalNumber": "...",
  "nationality": "Belg",
  "nobleCondition": "",
  "pictureHash": "...=",
  "rawData": "...+axEIuyskBgFySsp/",
  "sex": "M",
  "signature": ".../OlA44h4YCM/h+J14xUCg/98Y9/.../C/RB2dtVbHwFvDuafmr4ZEshTlZTLidHKlISFvFWOtsLAEPCbl5LjfQwcOKe0pDADtHb4IStBnr+aaE8oHsTaKq66Y+zt+AbwdmWOrMA5URKKf7dZkY7jt3h8KZDw36VjcytUgjxVIdqwHsDkmIjK6mJtakIwybS5wn3RiQj33/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
  "specialStatus": "0",
  "thirdName": "J",
  "version": "0"
 }
}

Filter Certificates

All certificates on the smart card can be dumped at once, or using a filter. In order to read all certificates at once:

var filter = [];
generic.allCerts(module, parseCerts, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
 ...
 },
 "authenticationCertificate": {
 ...
 },
 "nonRepudiationCertificate": {
 ...
 },
 "intermediateCertificates": {
 ...
 },
 "encryptionCertificate": {
 ...
 }
}

The filter can be used to ask a list of custom data containers. For example, we want to read only the rootCertificate

var filter = ['rootCertificate'];
generic.allCerts(module, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
  ...
 }
}

Sign Data

Data can be signed using the Belgian eID smart card. To do so, the T1C-GCL facilitates in:

Retrieving the certificate chain (citizen-certificate, root-certificate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed hash

To get the certificates necessary for signature validation in your back-end:

var filter = null;
generic.allCerts(module, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
 ...
 },
 "authenticationCertificate": {
 ...
 },
 "nonRepudiationCertificate": {
 ...
 },
 "intermediateCertificates": {
 ...
 },
 "encryptionCertificate": {
 ...
 }
}

Depending on the connected smart card reader. A sign can be executed in 2 modes:

Using a connected card reader with 'pin-pad' capabilities (keypad and display available)
Using a connected card reader without 'pin-pad' capabilities (no keypad nor display available)

Security consideration: In order to sign a hash, security considerations prefer using a 'pin-pad'.

Sign Hash without pin-pad

When the web or native application is responsible for showing the password input, the following request is used to sign a given hash:

var data = {
      "pin":"...",
      "algorithm":"sha1",
      "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
      "osDialog": true
}
generic.sign(module, data, callback);

Response is a base64 encoded signed hash:

{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}

Sign Hash with pin-pad

When the pin entry is done on the pin-pad, the following request is used to sign a given hash:

var data = {
      "algorithm":"sha1",
      "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
      "osDialog": false
}
generic.sign(module, data, callback);

Response is a base64 encoded signed hash:

{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}

The core services lists connected readers, and if they have pin-pad capability. You can find more information in the Core Service documentation on how to verify card reader capabilities.

Raw data signing

With the function signRaw you can sign unhashed document data. This means that the Trust1Connector will hash the value itself depending on the provided sign algorithm.

Trust1Connector only supports SHA2 hashing at this point.

When using SHA3, the Trust1Connector will convert to SHA2 implicitly

Below you can find an example

var data = {
      "algorithm":"sha256",
      "data":"vl5He0ulthjX+VWNM46QX7vJ8VvXMq2k/Tq8Xq1bwEw=",
      "osDialog": false
}
generic.signRaw(module, data, callback);

The function looks the same as a regular sign operation but expects a base64 data object that is unhashed.

Supported hash functions (SHA2) are;

SHA256
SHA384
SHA512

Bulk Signing

It is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk parameter set to true to the request. Subsequent sign requests will not require the PIN to be re-entered until a request with bulk being set to false is sent, or the Bulk Sign Reset method is called.

When using bulk signing, great care must be taken to validate that the first signature request was successful prior to sending subsequent requests. Failing to do this will likely result in the card being blocked.

const data = {
    algorithm: "sha256",
    data: "E1uHACbPvhLew0gGmBH83lvtKIAKxU2/RezfBOsT6Vs=",
    pin: "1234"
}
const bulk = true;
generic.sign(module, data, bulk).then(res => {
}, err => {
    console.error(err)
})

Bulk PIN Reset

The PIN set for bulk signing can be reset by calling this method.

generic.resetBulkPin(module).then(res => {
}, err => {
    console.error(err)
})

Response will look like:

{
    "success": true,
    "data": true
}

Verify PIN

Verify PIN without pin-pad

When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:

var data = {
      "pin":"..."
}
generic.verifyPin(module, data, callback);

Response:

{
  "verified": true
}

Verify PIN with pin-pad

When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:

var data = {}
generic.verifyPin(module, data, callback);

Response:

{
  "verified": true
}

Authentication

The T1C is able to authenticate a card holder based on a challenge. The challenge can be:

provided by an external service
provided by the smart card An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
External Challenge
An external challenge is provided in the data property of the following example:

var data = {
  "pin": "...",
  "algorithm": "sha1",
  "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E="
}
generic.authenticate(module, data, callback);

Response:

{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}

Take notice that the PIN property can be omitted when using a smart card reader with pin-pad capabilities.

Get valid algorithms to use for Sign or Authenticate

Via the Trust1Connector modules you are able to retrieve available algorithms to use for Signing or Authenticate

generic.allAlgoRefs(module, callback);

The response you can expect is a list of algorithms, an example can be found below (the values below are purely examplatory)

{
    "success": true,
    "data": ["sha1", "sha256"]

Aventra MyEID PKI

Introduction

Aventra MyEID PKI Card is a cryptographic smart card conforming to common Public Key Infrastructure standards like ISO/IEC-7816 and PKCS#15v1.0 specification. It can be used for various tasks requiring strong cryptography, e. g. logging securely to Windows, encrypting e-mail, authentication, and electronic signatures. The card is also available as a Dual Interface version, compatible with T=CL protocol and also emulating Mifare™. The card is a JavaCard with Aventra MyEID applet that implements the functionality.

The applet implements the FINEID S1 v1.12 specification and it can be configured to include all or any subset of the features specified in FINEID S4-1 or S4-2 specifications. Starting from version 2.2.0 the applet supports both 1024 and 2048 bit RSA keys. From version 3.0.0 (MyEID3) the applet supports keys from 512 bit up to 2048 bit in increments of 64 bits. The applet is fully compatible with JavaCard 2.1.1 and GlobalPlatform 2.0.1 specifications. The new MyEID version 3 (MyEID3) is now released and it uses the new JavaCard 2.2.1 and GlobalPlatform 2.1.1 platform. The new MyEID3 now supports RSA keys from 512 up to 2048 bits in 64 bit increments. MyEID3 supports file sizes up to 32767 bytes and 14 different PIN-codes can be created and used. The number of RSA keys is only limited by the available memory and maximum numbers of files (see PUT DATA: INITIALISE APPLET).

References

The most relevant specifications and standards are:

ISO/IEC 7816-4
ISO/IEC 7816-8
ISO/IEC 7816-9
JavaCard 2.1.1, MyEID3: 2.2.1
GlobalPlatform 2.0.1 ' (Open Platform), MyEID3: GlobalPlatform 2.1.1
FINEID S1 and S4 documentation

This document describes the functionality provided by the Aventra smartcard - which is a PKI container - on the T1C-GCL (Generic Connector Library) implemented version:

MyEID - reference manual v1.7.36

Interface

Models

All model information can be found in the

Examples

Create the Aventra module

When initialisation is finished you can continue using the aventra object to execute the functions below.

Token info

You can fetch the token information via the function. this will give all the information of the token you need according to the PKCS11 specifications

All certificate filters

The expected response for this call should be;

all Key references

The expected response for this call should be;

all Certificates

Extended certificates

You can also fetch the extended versions of the certificates via the functions

this has the capabilities to return multiple certificates if the token has multiple of this type.

for a single certificate the response looks like:

the allCertsExtended returns the following, with the contents of the certificates as the one you can see above;

Exposes all the certificates publicly available on the smart card. The following certificates can be found on the card:

Root certificate
Signing certificate
Authentication certificate
Issuer certificate
Encryption certificate

When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not.

The expected response for this call should be;

Token data

This will return information of the Aventra card.

The expected response for this call should be;

Certificate

When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not.

Root certificate

Contains the 'root certificate' stored on the smart card.

Authentication certificate

Non repudiation certificate

Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key.

Issuer certificate

Encryption certificate

The expected response for these calls should be in the following format;

Verify pin

The expected response for these calls should be in the following format;

Sign

To sign data, an algorithm must be specified in the algorithm property (see ), and a Base64-encoded string representation of the digest bytes of the same algorithm in the data property.

Additionally, it is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk parameter set to true to the request. Subsequent sign requests will not require the PIN to be re-entered until a request with bulk being set to false is sent, or the method is called.

The expected response for this call should be;

Raw data signing

With the function signRaw you can sign unhashed document data. This means that the Trust1Connector will hash the value itself depending on the provided sign algorithm.

Trust1Connector only supports SHA2 hashing at this point.

When using SHA3, the Trust1Connector will convert to SHA2 implicitly

Below you can find an example

The function looks the same as a regular sign operation but expects a base64 data object that is unhashed.

Supported hash functions (SHA2) are;

SHA256
SHA384
SHA512

Bulk PIN Reset

The PIN set for bulk signing can be reset by calling this method.

Response will look like:

Authenticate

The expected response for this call should be;

Reset pin

The expected response for this call should be;

Retrieve supported algorithms

The expected response for this call should be;

Validate signature

The module allows you to call a function on the token that can validate a signature. For this we need to use the validateSignature function. You can call this one via;

The response of this function will return a valid property that is either true or false.

Payment

FIle

HSM

Other

Miscellaneous

Generic token

Introduction

Interface

export interface AbstractEidGeneric {
  allData(module: string, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllDataResponse) => void): Promise<TokenAllDataResponse>;
  allCerts(module: string, parseCerts?: boolean,  filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsResponse) => void): Promise<TokenAllCertsResponse>;
  biometric(module: string, callback?: (error: T1CLibException, data: TokenBiometricDataResponse) => void): Promise<TokenBiometricDataResponse>;
  tokenData(module: string, callback?: (error: T1CLibException, data: TokenInfoResponse) => void): Promise<TokenInfoResponse>;
  address(module: string, callback?: (error: T1CLibException, data: TokenAddressResponse) => void): Promise<TokenAddressResponse>;
  picture(module: string, callback?: (error: T1CLibException, data: TokenPictureResponse) => void): Promise<TokenPictureResponse>;
  rootCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  intermediateCertificates(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  authenticationCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  nonRepudiationCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  encryptionCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
  issuerCertificate(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;

  allCertsExtended(module: string, parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
  rootCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  intermediateCertificatesExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  authenticationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  nonRepudiationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  encryptionCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  issuerCertificateExtended(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;

  verifyPin(module: string, body: TokenVerifyPinData, callback?: (error: T1CLibException, data: TokenVerifyPinResponse) => void): Promise<TokenVerifyPinResponse>;
  authenticate(module: string, body: TokenAuthenticateOrSignData, callback?: (error: T1CLibException, data: TokenAuthenticateResponse) => void): Promise<TokenAuthenticateResponse>;
  sign(module: string, body: TokenAuthenticateOrSignData, bulk?: boolean, callback?: (error: T1CLibException, data: TokenSignResponse) => void): Promise<TokenSignResponse>;
  signRaw(module: string, body: TokenAuthenticateOrSignData, bulk?: boolean, callback?: (error: T1CLibException, data: TokenSignResponse) => void): Promise<TokenSignResponse>;
  allAlgoRefs(module: string, callback?: (error: T1CLibException, data: TokenAlgorithmReferencesResponse) => void): Promise<TokenAlgorithmReferencesResponse>
  resetBulkPin(module: string, callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;
}

Models

All model information can be found in the Token typings model page

Initialise the Trust1Connector JS

Initialise a Trust1Connector client with a valid configuration:

T1CSdk.T1CClient.initialize(config).then(res => {
    client = res;
}, err => {
    console.error(error)
});

Obtain the Reader information

In order to get all connected card-readers, with available cards:

var core = client.core();
core.readersCardAvailable(callback);

This function call returns:

{
  "data": [
    {
      "card": {
        "atr": "3B9813400AA503010101AD1311",
        "description": ["Belgian eID Card"]
      },
      "id": "57a3e2e71c48cee9",
      "name": "Bit4id miniLector",
      "pinpad": false,
      "suggestedModule": "beid"
    }
  ],
  "success": true
}

As you can see in the response we get a property suggestedModule which is returned based on the card, reader and AID information. This suggested module can be used in the generic interface.

Using the generic interface can be done as follows;

var generic = client.generic(selected_reader.id, pin, pinType);

The pin and pinType are optional and are used for unlocking the pace layer (if the card is protected with a pace layer).

Cardholder Information

Biometric data

Contains all card holder related data, excluding the card holder address and photo. The service can be called:

generic.biometric(module, options, callback);

An example callback:

function callback(err,data) {
    if(err){
        console.log("Error:",JSON.stringify(err, null, '  '));
    }
    else {
        console.log(JSON.stringify(data, null, '  '));
    }
}

Response:

{
 "birthDate": "15 JUL  1993",
 "birthLocation": "Roeselare",
 "cardDeliveryMunicipality": "Avelgem",
 "cardNumber": "592..8233",
 "cardValidityDateBegin": "27.05.2015",
 "cardValidityDateEnd": "27.05.2025",
 "chipNumber": "U0xHk...EstwAjEpJQQg==",
 "documentType": "01",
 "firstNames": "Gilles Frans",
 "name": "Platteeuw",
 "nationalNumber": "930...154",
 "nationality": "Belg",
 "nobleCondition": "",
 "pictureHash": "Fqva9YCp...JKyn8=",
 "rawData": "AQw1OTIxMjQwNTgy...TARFBar2vWAqTW+axEIuyskBgFySsp/",
 "sex": "M",
 "signature": "hKys9WMjUm4ipg...14xUCg/98Y9/gP/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
 "specialStatus": "0",
 "thirdName": "J",
 "version": "0"
}

Address

Contains the card holder's address. The service can be called:

generic.address(module, callback);

Response:

{
 "municipality": "Hoeselt",
 "rawData": "ARJLZXJrc...AAAAAA==",
 "signature": "mhPyeRg25H...w==",
 "streetAndNumber": "Kerkstraat X",
 "version": "0",
 "zipcode": "3730"
}

Picture

Contains the card holder's picture stored on the smart card. The service can be called:

generic.picture(module, callback);

Response:

{
  "data": "/9j/4AAQSkZJRgABA...59aVpcklSDzyKUTEDGK//9k=",
  "success": true
}

Token info

Response

{
  "data": {
    "eid_compliant":48,
    "electrical_perso_interface_version":0,
    "electrical_perso_version":3,
    "graphical_perso_version":7,
    "label":"BELPIC",
    "prn_generation":4,
    "raw_data":"MCcCAQAEEFNMSU4z...JFTFBJQwMCBDCeBAcDAAA=",
    "serial_number":"534C494E..1231C",
    "version":0,
    "version_rfu":0
    },
    "success": true
}

Certificates

Exposes all the certificates publicly available on the smart card.

Extended certificates

You can also fetch the extended versions of the certificates via the functions

allCertsExtended(module: string, parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
rootCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
intermediateCertificatesExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
authenticationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
nonRepudiationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
encryptionCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
issuerCertificateExtended(module: string, parseCerts?: boolean,  callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;

this has the capabilities to return multiple certificates if the token has multiple of this type.

for a single certificate the response looks like:

{
    "success" : true
    "data" : {
        "certificates": [{
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        }]
    }
}

the allCertsExtended returns the following, with the contents of the certificates as the one you can see above;

{
    "success" : true
    "data" : {
        "rootCertificate": {
            "certificates": [...]
        },
        "authenticationCertificate": {
            "certificates": [...]
        },
        "nonRepudiationCertificate": {
            "certificates": [...]
        },
        "intermediateCertificates": {
            "certificates": [...]
        },
        "encryptionCertificate": {
            "certificates": [...]
        }
   }
}

Root Certificate

generic.rootCertificate(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

You can also fetch the root certificate via the function rootCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

Authentication Certificate

generic.authenticationCertificate(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

You can also fetch the root certificate via the function authenticationCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

Intermediate Certificate (citizen)

generic.intermediateCertificates(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

You can also fetch the root certificate via the function intermediateCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

Non-repudiation Certificate

generic.nonRepudiationCertificate(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

The response looks like:

You can also fetch the root certificate via the function nonRepudiationCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

Encryption Certificate (RRN)

generic.encryptionCertificate(module, parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

You can also fetch the root certificate via the function encryptionCertificateExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "certificates": [
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        ]
    }
}

All certificates

generic.allCerts(module, parseCertsBoolean, callback);

Response:

{
 "rootCertificate": {
 ...
 },
 "authenticationCertificate": {
 ...
 },
 "nonRepudiationCertificate": {
 ...
 },
 "intermediateCertificates": {
 ...
 },
 "encryptionCertificate": {
 ...
 }
}

You can also fetch the root certificate via the function allCertsExtended this has the capabilities to return multiple certificates if the token has multiple of this type.

The response looks like:

{
    "success" : true
    "data" : {
        "rootCertificate": {
            "certificates": [...]
        },
        "authenticationCertificate": {
            "certificates": [...]
        },
        "nonRepudiationCertificate": {
            "certificates": [...]
        },
        "intermediateCertificates": {
            "certificates": [...]
        },
        "encryptionCertificate": {
            "certificates": [...]
        }
   }
}

Data Filter

Filter Card Holder Data

All data on the smart card can be dumped at once, or using a filter. In order to read all data at once:

var filter = [];
generic.allData(module, { filters: filter}, callback);

Response:

{
 "picture": {
  "picture": "/9j/4AAQSkZJRgABAgEBLAEsAAD/.../wAALCADIAIwBAREA/8QA0gAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/2gAIAQEAAD8A9JpKKWiikooooopaKSilooooopKr3d9bWaFriVEwM4J5Ncjq3jUxkixQADozjJNcze+L9WndWF20OOCI/lzRb+KtYjhIN67Z7vyf1qT/AIS3Wc5F2OnQgY/lWrovjC7hYLqJ86IkksPvCustPEumXbbUuAjYzh+K1UkWRA6MGU9CDkGn0UUUUUUUhOBk8CuY1zxOls/kWjbnH3pAMgewrz7VtWmu7gvJIzZ65NZk1wSBjOagWbn5lB+vagy7+2KlilUE7eRj1qS3ncSEE4X3qwzNs81Dgg9K19G8VXumTLFv8yDOWjb+len6bqMGp2qz2zZU8Ed1PpVyiiiiio5pkgiaSRgqKMkmuH8ReKXlMlpAAkHRnB5b29q4+e5HzAHjPFZkoLyhevH6014XUcjBqAow5xQEYjFPClDxkCnq20AkZ/xqyl2oUK4xu6n0qwgguZQ28K2Ofc1v6Pqs2lSRGJzsLAOv94d69MtriO6gSaFgyMMg1LS0UUlcn491FbfS/sicyzEH6AGvOCzuApPOakt7CWYk7TjNXE0iUNnyyfpVqPQ53XiNwPepYfDMhb94GAq5/wAIzbhc4IPpVK/8OYjzEMmsWbRZ0XIUnHtVRrR4/vqR9RSwQGXdt4Zav2rbFww6DI5ruvBuqIIjaSuMu2Y8/TpXYUtFFIa8r8W6h9v1d9mCqHYuO4FVdM0t7iZWb8a6y10+KNQCOlXFijQfKop6g9hUmw4pjoRzmopEyvIqrJEjDGKpXGnwzoQ68+1YNxpv2Ry8RPHrVGUqse4MN38Qq7o8o8kOh+dG3AjsRXpejapHqVsDkLMo+dM8/WtOiis/WrxrHTJp1GWAwOeme9eWqqzTln6k5rqNLhWKFcDmtJRk1aSPPWp0i21J5dRSx8VWKVXkQA1WmwvGDzWVegSRsp4zXNT2WwMASSxqa1kNimMBkOB9fWt7QLx4ddgaNCyyLtIHevR6Wiuf8ZsRobAdWcD+dcLYQZlHck/lXWQKEjUVZj69OlXI+manXnvTiADioXPJ4qBhVaQ/NVWbkZ7VlXeDmqRYY27Rn1rOmkDXOwKBgH8av6XOba9guVz8hA2+1epg5GaWiuf8ZqTom4fwyKf5iuS0uFiQcV0MYwgBqxH1FWl6VLGeKcxOOaaRmoZAcVTkBqrOcL61j3B5NVgducVXkeOOXLKMt1p9tIsyjaAMGvVI+I1+gp9FZXiOAT6LcKRnaN35Vy+lhfKJ9Kv+cifeYACpIry3A5kA+tW1uYmXKuD+NSRzDseKl3gjrTS47UhYAGqFxINxqhcSA8ZrPlQmq8kZArNujljkdBUuhAy3cUOOWdRXrY4FLRUN0iSW8iSkBGUg5riLGMrbzxq3IkI3CozpuWZmnkye+6qT6TlmPnkk9M1Smsbq3OUuOOvWtDTrq4j+V5CRn1rpIZy6ZNSbiBz1qneXphFcpqmqzyNiJiBnqKyl+33DDZJL9dxq2i6pDg7mYehNX7a/lx5d5EADwGHUVBeR/MfT2q/4It2n10vtykY3H29K9MpaSsLxKJJo4oI5Ci53NjvWbbweUGAH3sE5qG8DpnqB7CsKNru7umitUKgdXbqay3m1L7cluxlMm/DAqMYrqLfTW5DKAw7joa1LRCnDVNelYo91cXq13NcMfLDbAcA+tVbXTppyzMrNtGSq9RTP7VhgZY44HBP+1k1Zi1LzZNgbOexGCKS8kwQcc1LM4ayeT0Sl8M+IhpDzfuA4kwCe+BXqFldxXtrHcQnKOMjNWKSsfV48zI3qMVVwpIA5xxTpI1bqBVNrRQ25EwfVaja3cybtgz/eK81ahjKrz1pTwR6k1U1aQ/Zm57VhQKDGhAyBWxatHACUXbuHOO9Yt3plol01wkWSTnGazLixaW5EsSbSO4q5HZu6Ey9R0qLUQYNOcdA3FY1vGS4wK9f8NQtBolurdSC2PrWtRWfqoHlI3cHFZUXJJ9TU3U4xxTguKdsyM1FINtQNjcKpauC1uwHORWLYsAAhPStqOPKAjoaHhU8Fc1G0KDouKgmUBTisDXCTBGoxgtk1W02AysoUclgK9it4hDBHGOiKFqWiqWppvtT7EGsgKoGVJB7ip161KoWlY4qrctjGOpqCJd74JqLUlVYic8YrlI22ySSKehzXUWDCa2RxzkVaaMVUnXaDWXdzBVIzziuf1Pc80MS9x1rd8Maa39qxRucqhDtj2r0elopkiCRGRuhGKxJreaFipQlB/EBTA2Dih5tg4ySeAKlUnbufr6VBOpkBA4PassR3NtIZJJ/MB/h24xWDr+rySYihU+/NZULXMkXlrHyepFdfoYaG1RG5IFa7yZTIrNv5gqHmudnn3zgdeazrjL3+7PyggV6J4QgY28ly643YRT64610tFFJTXXcjL6jFc+/BIP8ACcUKoEm888YFI13GuVkbafehZ4uu8UOYpVwGGazp9KtmYs2AfempZQx524pyusRAyKkEuXU9jxWNrUxUsnc1k26F50U9WIFd1F4N08XCzu0rdCUJ4Jro0RY0VEUKqjAA7U+iiikrCvV2Xki9ic1BExDYPOKL6xhvIdrqM9j6VjmwNuNiu6/8CzUiW0uw73bOOCADVO7hulGRIxY9iOKy5RfgnbKB+NLZWWp3EwMtwBHnPU8106xrFGiZzt5JNcpqdyLnVWVOUU81a0GL7TrdsmMgOCfoDmvUaWiiiikrM1aHlJh0HBrNBAcZqcnH0qJ1EnBGaqvGy/dPFU51mfv+tVRaNnLc/Wp0cRLgHmqup35hs2AJ8xxgYrBijKRlm+8eSa6nwLbbryW4b+EYFd5RRRRRRVXURmxlz7fzrmDJ820noavoQ0WCcmlQZpXjBGarMijpzVedBtJNZczbSTmsW6k864BY/Kvaomk3sFB4rtfBO398F6BcV19FFFFFFVr/AJs5fpXLXEJK716imWt5tOxzir6Tqe9JLcAcbhUTTrt4Iqhc3IOQGrA1C/CcZ56VkPOzHr1p0JZ32r07mu/8ELsaYZ5K5rsKKKKSloqtfnFnL9KwkAP41Qv7I53R9ax5ri5tzhg31qm+qzdDzUb6zKBjAqlNqkrZxwTWe8jSOSSSalhiaRgO1a1tAsYA711/hA7bpx6qa7CikpaSio1njZioYZHWs/UdQtmhlgjnjeUYyinJHPes2M5HNPYDbiqr28cvyuoIqjceH7eQ5AI+lZ0vhyME4Z/zqjPoiRZ5aqBslRulXbe3woOKtLGc8itvQJxbXqseh4NdRPqaxpujjMnqAcYHrToNShlAz8h96mkvLeJQ0k8aKe7MBT0uIZF3JNGy+qsCKqajfx2gUFvmJ6ZrB1HxUkSttIGOOtcpfeK5jC8dsxDP1f0+laehxeVp8cjcyTfOxPU1uRmpm6VAchqkEmKjkcYz0rJvGDZrJMe+Tgd6vRwbU6UpTBqS1O2ZT71vRkSJtakaARITyy+3UVyXiXUTvijEqugB+6en1rJi1AqmN7D6Gut8S61a6XKipbieSRSSXPSuBv8AUZbyQlwFXP3VGAKp7q9B0OTzdLtG/wBnH5VtR1Z6ionXnIprDI6VWkjB/i5qnPCMHAqCCAeZyKutGoWqsvBqOM4cH3rcgOQKvRNxisbxB4ettQgaZcRToM7gOv1rgEvzAvl+VE+D1K1//9k="
 },
 "biometric": {
  "birthDate": "15 JUL  1993",
  "birthLocation": "Roeselare",
  "cardDeliveryMunicipality": "Avelgem",
  "cardNumber": "592124058233",
  "cardValidityDateBegin": "27.05.2015",
  "cardValidityDateEnd": "27.05.2025",
  "chipNumber": "...==",
  "documentType": "01",
  "firstNames": "Gilles Frans",
  "name": "Platteeuw",
  "nationalNumber": "...",
  "nationality": "Belg",
  "nobleCondition": "",
  "pictureHash": "...=",
  "rawData": "...+axEIuyskBgFySsp/",
  "sex": "M",
  "signature": ".../OlA44h4YCM/h+J14xUCg/98Y9/.../C/RB2dtVbHwFvDuafmr4ZEshTlZTLidHKlISFvFWOtsLAEPCbl5LjfQwcOKe0pDADtHb4IStBnr+aaE8oHsTaKq66Y+zt+AbwdmWOrMA5URKKf7dZkY7jt3h8KZDw36VjcytUgjxVIdqwHsDkmIjK6mJtakIwybS5wn3RiQj33/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
  "specialStatus": "0",
  "thirdName": "J",
  "version": "0"
 },
 "address": {
  "municipality": "Hoeselt",
  "rawData": "...==",
  "signature": "...+Evety1PnTE4pqXaHgBxIpk+P8kRL5W3zDV+../../..+YoHBC9KqTmSpl5KULxdnKiyCt+2RyJdzE2wyoymjRmysIhJy1wW9PRnx99S1TFqQLuc0tyBmkBPR4aFqmOq4a7zqd0q2Q1g+BbnwJ4d3oa10ia5+0kBXf0THoXv3HYIHlnwhBMfAtWzPnFrYBuAKTwyl7yBF5IFfXFpGWuVZUTJElgNcmNvsHMnAhVwDw==",
  "streetAndNumber": "Kerkstraat X",
  "version": "0",
  "zipcode": "3730"
 }
}

The filter can be used to ask a list of custom data containers. For example, we want to read only the biometric data

var filter = ['biometric'];
generic.allData(module, { filters: filter }, callback);

Response:

{
 "biometric": {
  "birthDate": "15 JUL  1993",
  "birthLocation": "Roeselare",
  "cardDeliveryMunicipality": "Avelgem",
  "cardNumber": "592124058233",
  "cardValidityDateBegin": "27.05.2015",
  "cardValidityDateEnd": "27.05.2025",
  "chipNumber": "...==",
  "documentType": "01",
  "firstNames": "Gilles Frans",
  "name": "Platteeuw",
  "nationalNumber": "...",
  "nationality": "Belg",
  "nobleCondition": "",
  "pictureHash": "...=",
  "rawData": "...+axEIuyskBgFySsp/",
  "sex": "M",
  "signature": ".../OlA44h4YCM/h+J14xUCg/98Y9/.../C/RB2dtVbHwFvDuafmr4ZEshTlZTLidHKlISFvFWOtsLAEPCbl5LjfQwcOKe0pDADtHb4IStBnr+aaE8oHsTaKq66Y+zt+AbwdmWOrMA5URKKf7dZkY7jt3h8KZDw36VjcytUgjxVIdqwHsDkmIjK6mJtakIwybS5wn3RiQj33/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
  "specialStatus": "0",
  "thirdName": "J",
  "version": "0"
 }
}

Filter Certificates

All certificates on the smart card can be dumped at once, or using a filter. In order to read all certificates at once:

var filter = [];
generic.allCerts(module, parseCerts, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
 ...
 },
 "authenticationCertificate": {
 ...
 },
 "nonRepudiationCertificate": {
 ...
 },
 "intermediateCertificates": {
 ...
 },
 "encryptionCertificate": {
 ...
 }
}

The filter can be used to ask a list of custom data containers. For example, we want to read only the rootCertificate

var filter = ['rootCertificate'];
generic.allCerts(module, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
  ...
 }
}

Sign Data

Data can be signed using the Belgian eID smart card. To do so, the T1C-GCL facilitates in:

Retrieving the certificate chain (citizen-certificate, root-certificate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed hash

To get the certificates necessary for signature validation in your back-end:

var filter = null;
generic.allCerts(module, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
 ...
 },
 "authenticationCertificate": {
 ...
 },
 "nonRepudiationCertificate": {
 ...
 },
 "intermediateCertificates": {
 ...
 },
 "encryptionCertificate": {
 ...
 }
}

Depending on the connected smart card reader. A sign can be executed in 2 modes:

Using a connected card reader with 'pin-pad' capabilities (keypad and display available)
Using a connected card reader without 'pin-pad' capabilities (no keypad nor display available)

Security consideration: In order to sign a hash, security considerations prefer using a 'pin-pad'.

Sign Hash without pin-pad

When the web or native application is responsible for showing the password input, the following request is used to sign a given hash:

var data = {
      "pin":"...",
      "algorithm":"sha1",
      "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
      "osDialog": true
}
generic.sign(module, data, callback);

Response is a base64 encoded signed hash:

{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}

Sign Hash with pin-pad

When the pin entry is done on the pin-pad, the following request is used to sign a given hash:

var data = {
      "algorithm":"sha1",
      "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
      "osDialog": false
}
generic.sign(module, data, callback);

Response is a base64 encoded signed hash:

{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}

The core services lists connected readers, and if they have pin-pad capability. You can find more information in the Core Service documentation on how to verify card reader capabilities.

Raw data signing

With the function signRaw you can sign unhashed document data. This means that the Trust1Connector will hash the value itself depending on the provided sign algorithm.

Trust1Connector only supports SHA2 hashing at this point.

When using SHA3, the Trust1Connector will convert to SHA2 implicitly

Below you can find an example

var data = {
      "algorithm":"sha256",
      "data":"vl5He0ulthjX+VWNM46QX7vJ8VvXMq2k/Tq8Xq1bwEw=",
      "osDialog": false
}
generic.signRaw(module, data, callback);

The function looks the same as a regular sign operation but expects a base64 data object that is unhashed.

Supported hash functions (SHA2) are;

SHA256
SHA384
SHA512

Bulk Signing

const data = {
    algorithm: "sha256",
    data: "E1uHACbPvhLew0gGmBH83lvtKIAKxU2/RezfBOsT6Vs=",
    pin: "1234"
}
const bulk = true;
generic.sign(module, data, bulk).then(res => {
}, err => {
    console.error(err)
})

Bulk PIN Reset

The PIN set for bulk signing can be reset by calling this method.

generic.resetBulkPin(module).then(res => {
}, err => {
    console.error(err)
})

Response will look like:

{
    "success": true,
    "data": true
}

Verify PIN

Verify PIN without pin-pad

When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:

var data = {
      "pin":"..."
}
generic.verifyPin(module, data, callback);

Response:

{
  "verified": true
}

Verify PIN with pin-pad

When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:

var data = {}
generic.verifyPin(module, data, callback);

Response:

{
  "verified": true
}

Authentication

The T1C is able to authenticate a card holder based on a challenge. The challenge can be:

provided by an external service
provided by the smart card An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
External Challenge
An external challenge is provided in the data property of the following example:

var data = {
  "pin": "...",
  "algorithm": "sha1",
  "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E="
}
generic.authenticate(module, data, callback);

Response:

{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}

Take notice that the PIN property can be omitted when using a smart card reader with pin-pad capabilities.

Get valid algorithms to use for Sign or Authenticate

Via the Trust1Connector modules you are able to retrieve available algorithms to use for Signing or Authenticate

generic.allAlgoRefs(module, callback);

The response you can expect is a list of algorithms, an example can be found below (the values below are purely examplatory)

{
    "success": true,
    "data": ["sha1", "sha256"]

Safenet*

Introduction

The following page describes how you can integrate the Safenet module exposed on the Trust1Connector onto your web application.

Middleware of Safenet has to be installed to be able to fully use the Safenet token.

Supported version of the middleware is; Windows: 10.2 - 64bit & 32bit MacOS: 10.2

Interface

export interface AbstractSafenet {
    allCerts(parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsResponse) => void): Promise<TokenAllCertsResponse>;
    authenticationCertificate(parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
    nonRepudiationCertificate(parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;

    allCertsExtended(parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
    authenticationCertificateExtended(parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
    nonRepudiationCertificateExtended(parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;

    validateSignature(body: TokenValidateSignatureRequest, callback?: (error: T1CLibException, data: TokenValidateSignatureResponse) => void): Promise<TokenValidateSignatureResponse>;

    verifyPin(body: TokenVerifyPinData, callback?: (error: T1CLibException, data: TokenVerifyPinResponse) => void): Promise<TokenVerifyPinResponse>;
    authenticate(body: TokenAuthenticateOrSignData, callback?: (error: T1CLibException, data: TokenAuthenticateResponse) => void): Promise<TokenAuthenticateResponse>;
    sign(body: TokenAuthenticateOrSignData, bulk?: boolean, callback?: (error: T1CLibException, data: TokenSignResponse) => void): Promise<TokenSignResponse>;
    signRaw(body: TokenAuthenticateOrSignData, bulk?: boolean, callback?: (error: T1CLibException, data: TokenSignResponse) => void): Promise<TokenSignResponse>;
    allAlgoRefs(callback?: (error: T1CLibException, data: TokenAlgorithmReferencesResponse) => void): Promise<TokenAlgorithmReferencesResponse>
    resetBulkPin(callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;
    tokenData(callback?: (error: T1CLibException, data: TokenInfoResponse) => void): Promise<TokenInfoResponse>;
}

Models

All model information can be found in the Token typings model page

Get Safenet container object

Initialise a Trust1Connector client:

T1CSdk.T1CClient.initialize(config).then(res => {
    client = res;
}, err => {
    console.error(error)
});

Get the container service:

var client = client.safenet(reader_id);

Call a function for the Belgian eID container:

function callback(err,data) {
    if(err){console.log("Error:",JSON.stringify(err, null, '  '));}
    else {console.log(JSON.stringify(data, null, '  '));}
}
beid.biometric(callback);

Obtain the Reader-ID

The constructor for the Belgian eID expect as the parameter to be a valid reader-ID. A reader-ID can be obtained from the exposed core functionality, for more information see Core services responds with available card-readers, available card in a card-reader, etc. For example: In order to get all connected card-readers, with available cards:

var core = client.core();
core.readersCardAvailable(callback);

This function call returns:

{
  "data": [
    {
      "card": {
        "atr": "3B9813400AA503010101AD1311",
        "description": [""]
      },
      "id": "57a3e2e71c48cee9",
      "name": "JC Token",
      "pinpad": false
    }
  ],
  "success": true
}

All methods for safenet will use the selected reader - identified by the reader_id.

Token info

You can fetch the token information via the function. this will give all the information of the token you need according to the PKCS11 specifications

client.tokenData().then(res => {
    // see response below
})

{
    "success": true,
    "data": {
        "info": {
            "slot": "string",
            "label": "string",
            "manufacturerId": "string",
            "model": "string",
            "serialNumber": "string",
            "flags": {
                "isRandomNumberGenerator": "boolean",
                "isWriteProtected": "boolean",
                "isLoginRequired": "boolean",
                "isUserPinInitialized": "boolean",
                "isRestoreKeyNotNeeded": "boolean",
                "isClockOnToken": "boolean",
                "isProtectedAuthenticationPath": "boolean",
                "isDualCryptoOperations": "boolean",
                "isTokenInitialized": "boolean",
                "isSecondaryAuthentication": "boolean",
                "isUserPinCountLow": "boolean",
                "isUserPinFinalTry": "boolean",
                "isUserPinLocked": "boolean",
                "isUserPinToBeChanged": "boolean",
                "isSoPinCountLow": "boolean",
                "isSoPinFinalTry": "boolean",
                "isSoPinLocked": "boolean",
                "isSoPinToBeChanged": "boolean"
            },
            "mechanisms": [
                {
                    "mechanism": "string",
                    "flags": {
                        "isHardware": "boolean",
                        "isEncrypt": "boolean",
                        "isDecrypt": "boolean",
                        "isDigest": "boolean",
                        "isSign": "boolean",
                        "isSignRecover": "boolean",
                        "isVerify": "boolean",
                        "isVerifyRecover": "boolean",
                        "isGenerate": "boolean",
                        "isGenerateKeyPair": "boolean",
                        "isWrap": "boolean",
                        "isUnwrap": "boolean",
                        "isExtension": "boolean",
                        "isEcFP": "boolean",
                        "isEcNamedcurve": "boolean",
                        "isEcUncompress": "boolean",
                        "isEcCompress": "boolean"
                    },
                    "ulMinKeySize": "number",
                    "ulMaxKeySize": "number"
                }
            ],
            "ulMaxSessionCount": "number",
            "ulSessionCount": "number",
            "ulMaxRwSessionCount": "number",
            "ulMaxPinLen": "number",
            "ulMinPinLen": "number",
            "ulTotalPubLicMemory": "number",
            "ulFreePubMemory": "number",
            "ulTotalPrivateMemory": "number",
            "ulFreePrivateMemory": "number",
            "hardwareVersion": "string",
            "firmwareVersion": "string"
        },
        "infoType": "TokenInfoType"
    }
}



//ENUM
TokenInfoType {
    Token,
    PKCS11,
    File,
    Payment,
    HSM,
    Vault,
    Wallet,
}

Certificates

Exposes all the certificates publicly available on the smart card.

Extended certificates

You can also fetch the extended versions of the certificates via the functions

allCertsExtended(parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
authenticationCertificateExtended(parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
nonRepudiationCertificateExtended(parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;

this has the capabilities to return multiple certificates if the token has multiple of this type.

for a single certificate the response looks like:

{
    "success" : true
    "data" : {
        "certificates": [{
            "certificate"?: string,
            "certificateType"?: string,
            "id"?: string,
            "subject"?: string,
            "issuer"?: string,
            "serialNumber"?: string,
            "url"?: string,
            "hashSubPubKey"?: string,
            "hashIssPubKey"?: string,
            "exponent"?: string,
            "remainder"?: string,
            "parsedCertificate"?: Certificate
        }]
    }
}

the allCertsExtended returns the following, with the contents of the certificates as the one you can see above;

{
    "success" : true
    "data" : {
        "authenticationCertificate": {
            "certificates": [...]
        },
        "nonRepudiationCertificate": {
            "certificates": [...]
        },
   }
}

Root Certificate

client.beid(reader_id).rootCertificate(parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

Authentication Certificate

client.beid(reader_id).authenticationCertificate(parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

Intermediate Certificate (citizen)

client.beid(reader_id).intermediateCertificates(parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

Non-repudiation Certificate

client.beid(reader_id).nonRepudiationCertificate(parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

Encryption Certificate

client.beid(reader_id).encryptionCertificate(parseCertsBoolean, callback);

Response:

{
    success: true,
    data: {
        certificate?: string,
        certificates?: Array<string>,
        certificateType?: string,
        id?: string,
        parsedCertificate?: Certificate,
        parsedCertificates?: Array<Certificate>
    }    
}

Data Filter

Filter Certificates

All certificates on the smart card can be dumped at once, or using a filter. In order to read all certificates at once:

var filter = [];
client.beid(reader_id).allCerts(parseCerts, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
  ...
 },
 "authenticationCertificate": {
  ...
 },
 "nonRepudiationCertificate": {
  ...
 },
 "intermediateCertificates": {
  ...
 },
 "encryptionCertificate": {
  ...
 }
}

The filter can be used to ask a list of custom data containers. For example, we want to read only the rootCertificate

var filter = ['rootCertificate'];
client.safenet(reader_id).allCerts(parseCerts, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
  ...
 }
}

Sign Data

Signing

Data can be signed using the Belgian eID smart card. To do so, the T1C-GCL facilitates in:

Retrieving the certificate chain (citizen-certificate, root-certificate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed hash

To get the certificates necessary for signature validation in your back-end:

var filter = null;
client.safenet(reader_id).allCerts(parseCerts, { filters: filter}, callback);

Response:

{
 "rootCertificate": {
  ...
 },
 "authenticationCertificate": {
  ...
 },
 "nonRepudiationCertificate": {
  ...
 },
 "intermediateCertificates": {
  ...
 },
 "encryptionCertificate": {
  ...
 }
}

Depending on the connected smart card reader. A sign can be executed in 2 modes:

Using a connected card reader with 'pin-pad' capabilities (keypad and display available)
Using a connected card reader without 'pin-pad' capabilities (no keypad nor display available)

Sign Hash without pin-pad

When the web or native application is responsible for showing the password input, the following request is used to sign a given hash:

var data = {
      "pin":"...",
      "algorithm":"sha1",
      "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
      "osDialog": true
}
client.safenet(reader_id).sign(data, callback);

Response is a base64 encoded signed hash:

{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}

Sign Hash with pin-pad

When the pin entry is done on the pin-pad, the following request is used to sign a given hash:

var data = {
      "algorithm":"sha1",
      "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
      "osDialog": false
}
client.safenet(reader_id).sign(data, callback);

Response is a base64 encoded signed hash:

{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}

The core services lists connected readers, and if they have pin-pad capability. You can find more information in the Core Service documentation on how to verify card reader capabilities.

Raw data signing

With the function signRaw you can sign unhashed document data. This means that the Trust1Connector will hash the value itself depending on the provided sign algorithm.

Trust1Connector only supports SHA2 hashing at this point.

When using SHA3, the Trust1Connector will convert to SHA2 implicitly.

Below you can find an example

var data = {
      "algorithm":"sha256",
      "data":"vl5He0ulthjX+VWNM46QX7vJ8VvXMq2k/Tq8Xq1bwEw=",
      "osDialog": false
}
client.signRaw(data, callback);

The function looks the same as a regular sign operation but expects a base64 data object that is unhashed.

Supported hash functions (SHA2) are;

SHA256
SHA384
SHA512

Verify PIN

Verify PIN without pin-pad

When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:

var data = {
      "pin":"..."
}
client.safenet(reader_id).verifyPin(data, callback);

Response:

{
  "verified": true
}

Verify PIN with pin-pad

When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:

var data = {}
client.safenet(reader_id).verifyPin(data, callback);

Response:

{
  "verified": true
}

Authentication

The T1C is able to authenticate a card holder based on a challenge. The challenge can be:

provided by an external service
provided by the smart card An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
External Challenge
An external challenge is provided in the data property of the following example:
```
var data = {
  "pin": "...",
  "algorithm": "sha1",
  "data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E="
}
client.safenet(reader_id).authenticate(data, callback);
```
Response:
```
{
  "success": true,
  "data": {
    "data" : "W7wqvWA8m9S...="
  }
}
```
Take notice that the PIN property can be omitted when using a smart card reader with pin-pad capabilities. The 'algorithm_reference' property can contain the following values: sha1, sha256, sha512, md5.
Generated Challenge
A server generated challenge can be provided to the JavaScript library. In order to do so, an additional contract must be provided with the 'OCV API' (Open Certificate Validation API).

The calculated digest of the hash is prefixed with:
DigestInfo ::= SEQUENCE {
      digestAlgorithm AlgorithmIdentifier,
      digest OCTET STRING
  }
Make sure this has been taken into consideration in order to validate the signature in a backend process.

Get valid algorithms to use for Sign or Authenticate

Via the Trust1Connector modules you are able to retrieve available algorithms to use for Signing or Authenticate

client.allAlgoRefs(module, callback);

The response you can expect is a list of algorithms, an example can be found below (the values below are purely examplatory)

{
    "success": true,
    "data": ["sha1", "sha256"]
}

Validate signature

The module allows you to call a function on the token that can validate a signature. For this we need to use the validateSignature function. You can call this one via;

const body = {
    "algorithm": 'sha256',
    "hash": '...',
    "signedHash": '...',
    "osDialog": false,
    "id": 'cert_id',
    "pin": 'pin_code',
    "timeout": 120 //timeout in seconds
}
client.validateSignature(body).then(response => {
    response.valid
).catch(error => {
    errorHandler(error)}
)

The response of this function will return a valid property that is either true or false.

{
    "success": true,
    "data": {
        "valid": true
    }
}

File exchange

File management, file up and download using an operating system abstraction layer. Allows the consuming application to work with OS independent directory and file aliases.

Introduction

The File Exchange container allows Trust1Connector to manage files and directories, to upload or download files to/from the filesystem from/to the requesting party (especially for web application). The user of the device must give a consent prior of file operations.

The File Exchange container provides the following functionalities:

selecting a folder based on application type
listing files in selected application type
downloading one or more files into selected application type
uploading one or more files from the selected application type
creating sub directories in 'mapped' folders (application types)

The Trust1Connector does NOT allow the deletion of folders or files residing on the user's device.

An application type resolves locally to an absolute file system path.

An application can create additional folders for a given application type, those folders are relative to the absolute path which has been locally mapped on the application type. This means that the web application can ask the user to create subdirectories in an application type which has been already mapped.

The File Exchange container provides additionally:

optional user notification for file transfer completion
copy and move files between application types
user consent to allow the consuming application to perform file operations
application/domain scoped, application types are bound to the application domain
OS native files and directory chooser dialogs

The File-exchange payload limit is set to 50 MB. If your needs exceed this please contact support

Configuration file

The configuration file can be found in

%localappdata%\Trust1Connector\file-exchange.json

Notifications

The File Exchange container allows the application to choose whether to notify the users in the application context, or to delegate notification to the T1C. The T1C uses the underlying operating system to notify users. The type of notification supported by the T1C is system modal information (message, error, warning dialogs).

Context and scope

The context of a type mapping is defined by the following concepts:

application_id (property of Type class): a string value denoting the application identifier. This is the root context for entity mapping. The application id is derived from the Origin domain and acts as an application scope for all defined mappings
entity: a string value denoting the root entity/owner for types mapping. This can be called the root for al 'aliases' or 'type mappings' which will be created.
type: a string value denoting a file typing, related to the absolute path mapped by an user; this value abstracts absolute paths from an application perspective as it acts as an alias, referencing a file or directory based on the configured absolute path.

The following image depicts the file exchange object model:

Type Mapping

A 'Type' in the context of the File Exchange container, is an alias or label, used by an application, to abstract the absolute path reference of the local file system. A 'Type' allows the application to perform file transfers, without the notion of the local file system organisation. The File Exchange container maps the absolute path, chosen by a user, on the application scoped label. We call this action a 'type mapping', this is, an absolute path, in the context of an application, is references by an alias or label (=Type).

A conceptual example, a mapping of

[Windows]
"C:\Users\userA\t1t\coda"
[OSX]
"/Users/userA/t1t/coda"

can be mapped on:

application_id: mywebapp.com //domain
entity: Trust1Team //root context
type: Coda

When the example mapping has been done, the consuming application does not need to worry about the underlying operating system, and can just target the folder or file using the tuple (entity, type) bounded implicitly by the operating domain (mywebapp.com).

Type subfolders

Subfolders can be managed by the application. All subfolder are relative paths and when requested can be created, optionally recursively, by the File Exchange API. It's important to understand:

Type mapping : correlates to absolute paths on a local file system
Type subfolders: correlates to relative paths on a local file system and MUST reside in a type mapping/definition.

The File Exchange container maintains the mapping for absolute paths. Relative paths will be created when used in the specified use case. Neither absolute paths or relative paths will result in deletion on the local file system! When deleting a 'type' (aka absolute path), the type will be removed from the File Exchange container, but the references directory will still exist on the user's file system.

In the File Exchange API, the parameter relpath refers to an array of strings denoting a directory path, within a type mapping.

Responses

The File Exchange API can be integrated using Promises or callbacks. Both are returning the same result.

Bulk File Transfer

The File Exchange container allows for bulk file transfer. The individual methods are stateless requests to the T1C-GCL service, and allows to up- or download one or more files from a user perspective. The progress information can be retrieved by the application for each file separately or for all the actions running on the T1C-GCL service.

Language

The language, used for OS modals, is determined the web application. The title and message properties can be provided, which will be used in the underlying OS modal/dialog. For OSX, there is no title of message for the file or directory chooser. In OSX you can only pass through the title and message using system modals (error, warn, info messages and PIN dialog).

Interface

interface AbstractFileExchange {
    download(entity: string, type: string, file: Blob, fileName: string, relPath?: [string], implicitCreationType?: boolean, notifyOnCompletion?: boolean, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<DataResponse>;
    upload(entity: string, type: string, fileName: string, rel_path?: [string], notifyOnCompletion?: boolean, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<Blob>;
    listTypes(entity?: string, page?: Page, callback?: (error: T1CLibException, data: TypeListResponse) => void): Promise<TypeListResponse>;
    listType(entity: string, type: string, callback?: (error: T1CLibException, data: TypeResponse) => void): Promise<TypeResponse>;
    listTypeContent(entity: string, type: string, relPath?: [string], page?: Page, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<FileListResponse>;
    listContent(entity: string, page?: Page, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<FileListResponse>;
    existsType(entity: string, type: string, callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;
    existsFile(entity: string, type: string, relPath: [string], callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;
    getAccessMode(entity: string, type: string, relPath?: [string], callback?: (error: T1CLibException, data: DataResponse) => void): Promise<DataResponse>;
    createDir(entity: string, type: string, relPath: [string], recursive?: boolean, callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;
    copyFile(entity: string, fromType: string, toType: string, fileName: string, newfileName: string, fromrelPath?: [string], toRelPath?: [string], callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;
    moveFile(entity: string, fromType: string, toType: string, fileName: string, fromrelPath?: [string], toRelPath?: [string], callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;
    renameFile(entity: string, type: string, fileName: string, newfileName: string, relPath?: [string], callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;
    getFileInfo(entity: string, type: string, fileName: string, relPath?: [string], callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;
    createType(entity: string, type: string, initPath?: [string], modal?: boolean, timeout?: number, callback?: (error: T1CLibException, data: TypeResponse) => void): Promise<TypeResponse>;
    createTypeDirs(entity: string, type: string, rel_path: [string], modal?: boolean, timeout?: number, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<FileListResponse>;
    updateType(entity: string, type: string, timeout?: number, callback?: (error: T1CLibException, data: TypeResponse) => void): Promise<TypeResponse>;
    deleteType(entity: string, type: string, callback?: (error: T1CLibException, data: boolean) => void): Promise<boolean>;
}

Objects

Enums

The following enumerators have been exported by the File Exchange container:

enum FileSort {ASC, DESC}
enum TypeStatus {MAPPED,UNMAPPED}

Enum

Values

Description

FileSort

ASC, DESC

Used for sorting files. ASC = ascending, DESC = descending

TypeStatus

MAPPED, UNMAPPED

Use to inform the application if a Type has been mapped to an absolute path by the user.

Classes

class T1CResponse {
    constructor(public success: boolean, public data?: any) {}
}

class ListFilesRequest {
    constructor(public path: string, public extensions: string[]) {}
}

export class File {
    constructor(public extension: string,
                public name: string,
                public path: string,
                public relPath: string[],
                public type: string,
                public entity: string,
                public size: number,
                public lastModificationTime: string,
                public isDir: boolean,
                public access: string) {}
}

class FileListResponse extends T1CResponse {
    constructor(public data: FileList, public success: boolean) {
    super(success, data);
    }
}

class FileList {
    constructor(public files: File[], public total: number) {}
}

class FileResponse extends T1CResponse {
    constructor(public data: File, public success: boolean) {
        super(success, data);
    }
}

class TypeListResponse extends T1CResponse {
    constructor(public data: TypeList, public success: boolean) {
        super(success, data);
    }
}

class TypeResponse extends T1CResponse {
    constructor(public data: Type, public success: boolean){
        super(success, data);
    }
}

class Type {
    constructor(public entity: string, public type: string, public path: string, access: string, status: TypeStatus, public files: number, public appid?: string) {}
}

class TypeList{
    constructor(public types: Type[], public total: number) {}
}

class Page {
    constructor (public start: number, public size: number, public sort: FileSort) {}
}

class DataArrayResponse extends T1CResponse {
    constructor(public data: string[], public success: boolean) {
        super(success, data);
    }
}

class DataResponse extends T1CResponse {
    constructor(public data: string, public success: boolean) {
        super(success, data);
    }
}

class RestException {
    constructor(public status: number, public code: string, public description: string, public client?: GCLClient) {
        ObjectUtil.removeNullAndUndefinedFields(this);
    }
}

Function Descriptions

The following functions are available in the T1C-JS library:

JavaScript API

Function

Input

Output

Description

download

entity, type, file, filename, relpath, implicitCreationType, notifyOnCompletion

success value

Creates a file named filename at the type location, optionally in relative folder denoted by relpath, with file contents file. Optionally notifies user upon completion.

upload

entity, type, filename, relpath, notifyOnCompletion

array buffer

Uploads a file named filename, from the type location, optionally in relative folder denoted with relpath. Optionally notifies user upon completion.

listTypes

entity, page

list of type objects

Returns a list of existing types. The type object contains information about the mapping of absolute paths. Paging can be used optionally by using the page parameter.

listType

entity, type

type object

Returns the targeted type object.

listTypeContent

entity, type, relpath, page

list of file objects

Returns a list of file objects for the targeted type. A file can be a directory or a binary file. The relpath refers to the directory path where files should be searched for.

listContent

entity, page

list of file objects

Returns a list of file objects for all known types. The list will contain all files that are present in defined types.

existsType

entity, type

boolean

Verifies if type exists. Be aware that a type can exist, but no mapping has been persisted by the user.

existsFile

entity, type, relpath

boolean

Verifies if a file exists on the local file system.

getAccessMode

entity, type, relpath, filename

access mode

Returns the access mode for a file or directory. The param relpath can be used to target a nested file or directory.

createDir

entity, type, relpath, recursive

file object

Returns the created file object (which in this use case is always a directory). When recursive is set to true, the all subfolders will be created.

copyFile

entity, fromType, toType, filename, newfilename, fromrelpath, torelpath

file object

Copy a file or directory on the local file system.

moveFile

entity, fromType, toType, filename, fromrelpath, torelpath

file object

Move a file or directory on the local file system.

renameFile

entity, type, filename, newfilename, relpath

file object

Rename a file or directory

getFileInfo

entity, type, filename, relpath

file object

Returns the targeted file information

createType

entity, type, timeoutInSeconds, initabspath

type object

Creates a new type mapping, with optional initial path (migration support). When the path is not found on the local system, the user will be prompted with a file chooser.

createTypeDirs

entity, type, relpath, showModal, timeoutInSeconds

type object

Creates new subfolders for a type mapping. If the type mapping is not existing, the user will be prompted with a file chooser.

updateType

entity, type, timeoutInSeconds

type object

Prompt the user to force renewal of type mapping. The user will be presented with file chooser, even when the mapping exists already.

deleteType

entity, type

boolean

Removes the type mapping, but does not delete

directories or files from the local system.

Detailed Function Overview

Paging (Page interface)

The File Exchange container uses paging for the endpoints:

listTypes
listContent

The page-parameter can be optionally provided and contains the following properties:

start: start index
size: number of items on a page
sort: ordering of file and directory names ascending or descending

When used, the resulting response returns an 'total' property with the total item count for the requested resource.

download

Creates a file named filename at the type location in the context of entity, optionally in relative folder denoted by relpath, with file content file. Optionally notifies user upon completion.. When notifications are disabled, the application is assumed to handle user notifications.

The optional relpath provided, will be created when not existing, this in a recursive manner.

Interface

download(entity: string, type: string, file: Blob, fileName: string, relPath?: [string], implicitCreationType?: boolean, notifyOnCompletion?: boolean, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<DataResponse>;

Parameters

entity: the entity context where the type mapping is persisted
type: location for the newly created file
file: Blob containing binary data to be put in the file
filename: name to be given to the file
relpath: optional relative path (array of strings), when provided will implicitly create the missing directories.
implicitCreationType: In case the type mapping doesn’t exist, a prompt will be shown to the user for creating the Type before performing the download.
notifyOnCompletion: show modal info form operating system to user upon completion

Output

{
    data: string
    success: boolean
}

Use Cases

The use cases are the followings with the concerned parameters :

Use Case 1

download with existing Type (whatever the value true or false of the flag ‘implicitCreationType’)
- The user launches the download process with a relpath.
- The application uses the T1C function download with as parameter a relpath.
- The file is downloaded to the directory of the path + relpath (recursive creation).

Use Case 2 – download with non existing Type and parameter ‘implicitCreationType’ = false

The user launches the download process.
The application uses the T1C function download with as parameter a relpath.
The exception 356 is raised due the fact the Type doesn’t exist.
End

Use Case 3 – download with non existing Type and parameter ‘implicitCreationType’ = true

The user launches the download process.
The application uses the T1C function download with as parameter a relpath.
The user will see the prompt for the Type creation with a default path.
The user selects the directory and cancels or validates the creation:
- Cancellation of the creation.
- Validation of the creation.
  - The Type is created.
  - The file is downloaded to the directory of the path + relpath (recursive creation).

upload

Uploads a file named filename, from the type location, optionally in relative folder denoted with relpath. Optionally notifies the user upon completion.. When the notifications are disabled, the application is assumed to handle user notifications.

The optional relpath provided, will be created when not existing, this in a recursive manner.

Interface

upload(entity: string, type: string, fileName: string, relPath?: [string], notifyOnCompletion?: boolean, callback?: (error: T1CLibException, data: Blob) => void): Promise<Blob>;

Parameters

entity: the entity context where the type mapping is persisted
type: location for the file to upload
filename: name of the file to be uploaded
relpath: optional relative path (array of strings)
notifyOnCompletion: show modal info form operating system to user upon completion

Output

Returns a Blob object

listTypes

Retrieve a list of current persisted mappings given an optional entity.

Interface

listTypes(entity?: string, page?: Page, callback?: (error: T1CLibException, data: TypeListResponse) => void): Promise<TypeListResponse>;

Parameters

entity: the entity context where the type mapping is persisted. Optional.
page: apply a paging to the result. Optional.

Output

{
    data: TypeList
    success: boolean
}

listType

Retrieve a list of current mappings given an entity type context.

Interface

listType(entity: string, type: string, callback?: (error: T1CLibException, data: TypeResponse) => void): Promise<TypeResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context

Output

{
    data: Type
    success: boolean
}

listTypeContent

List all the content for a mapping.

Interface

listTypeContent(entity: string, type: string, relPath?: [string], page?: Page, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<FileListResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context
relpath: specify a relative path to retrieve the files
page: apply a paging to the result. Optional.

Output

{
    data: FileList
    success: boolean
}

listContent

List all the content for a mapping given an entity context..

Interface

listContent(entity: string, page?: Page, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<FileListResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
page: apply a paging to the result. Optional.

Output

{
    data: FileList
    success: boolean
}

existsType

Verify if a context mapping exists.

Interface

existsType(entity: string, type: string, callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context

Output

{
    data: boolean
    success: boolean
}

existsFile

Verify if a file exists in a context mapping.

Interface

existsFile(entity: string, type: string, relPath: [string], callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context
relpath: a relative path based on the context root folder

Output

{
    data: boolean
    success: boolean
}

getAccessMode

Get the access mode of a folder or file in a context mapping.

Interface

getAccessMode(entity: string, type: string, fileName: string, relPath?: [string], callback?: (error: T1CLibException, data: DataResponse) => void): Promise<DataResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context
filename: an optional filename, if not specified the folder access mode will be returned
relpath: an optional relative path based on the context root folder

Output

{
    data: string ("rwx")
    success: boolean
}

createDir

Create a directory in a context mapping.

Interface

createDir(entity: string, type: string, relPath: [string], recursive?: boolean, callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context
relpath: a relative path based on the context root folder
recursive: indicate whether the directory should be created recursively. If not and the parent directories do not exist, an error will be thrown.

Output

{
    data: File
    success: boolean
}

copyFile

Copy a file from one context mapping to another.

Interface

copyFile(entity: string, fromType: string, toType: string, fileName: string, newfileName: string, fromrelPath?: [string], toRelPath?: [string], callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
fromType: the originating entity type mapping context
toType: the destination entity type mapping context
filename: the name the of the to copy
newfilename: the new destination file name
fromrelpath: an optional originating relative path based on the context root folder
torelpath: an optional destination relative path based on the context root folder

Output

{
    data: File
    success: boolean
}

moveFile

Move a file from one context mapping to another.

Interface

moveFile(entity: string, fromType: string, toType: string, fileName: string, fromrelPath?: [string], toRelPath?: [string], callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
fromType: the originating entity type mapping context
toType: the destination entity type mapping context
filename: the name the of the to copy
fromrelpath: an optional originating relative path based on the context root folder
torelpath: an optional destination relative path based on the context root folder

Output

{
    data: File
    success: boolean
}

renameFile

Rename a file in a context mapping.

Interface

renameFile(entity: string, type: string, fileName: string, newfileName: string, relPath?: [string], callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
fromType: the originating entity type mapping context
toType: the destination entity type mapping context
filename: the name the of the to copy
relpath: an optional relative path based on the context root folder

Output

{
    data: File
    success: boolean
}

getFileInfo

Get file information of a file in a context mapping.

Interface

getFileInfo(entity: string, type: string, fileName: string, relPath?: [string], callback?: (error: T1CLibException, data: FileResponse) => void): Promise<FileResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the originating entity type mapping context
filename: the name the of the to copy
relpath: an optional relative path based on the context root folder

Output

{
    data: File
    success: boolean
}

createType

The initPath parameter denotes an initial path proposal from the application. Example values:

Windows

inittabspath = [ "C:\", "Users", "user1", "Desktop", "folder1" ];
inittabspath = [ "C:\Users", "user1", "Desktop", "folder1" ];
inittabspath = [ "C:\Users\user1\Desktop\folder1" ];

macOS

initPath = [ "Users", "user1", "Desktop", "folder1" ];
initPath = [ "/Users/user1/Desktop/folder1" ];

Linux

initPath = [ "home", "user1", "Desktop", "folder1" ];
initPath = [ "/home/user1/Desktop/folder1" ];

The optional parameter modal is by default set to true.

When createType is called upon an existing type mapping, the file-chooser shown to the user is defaults to the existing absolute path provided for the type.

The showModal flag is used to propose (or not) the prompt to the end user even if the initPath exists or not. This parameter forces the prompt of the file chooser:

when the initPath is provided and showModal is set to true: the initPath is pre-selected in the file-chooser shown to the user if existing, or the file-chooser is shown with a default path.
when the initPath is provided and modal is set to false: the initabspath is used when mapping exists, otherwise the file-chooser is shown to the user in order to select a valid absolute path.
when the initPath is not provided and modal is set to true: the file-chooser is shown when the mapping doesn't exist.
when the initPath is not provided and modal is set to false: a type exception is thrown when the type mapping doesn't exist

Interface

createType(entity: string, type: string, initPath: [string], modal?: boolean, timeout?: number, callback?: (error: T1CLibException, data: TypeResponse) => void): Promise<TypeResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context
modal: indicate if the folder dialog must be shown
timeout: optional timeout in seconds before the folder dialog is discarded)
initPath: the optional initial root context path for the new type

Output

{
    data: Type
    success: boolean
}

Use Cases

The use cases are the followings with the concerned parameters:

Use Case 1

createType with an existing initPath and parameter showModal = true
- The user will create a type mapping.
- The application uses the T1C function createType with as parameter an existing initabspath and the modal set to true.
- A prompt must appear with the value set to initPath.
- The user selects (or not) a directory and cancels or validates the creation:
- Cancellation of the creation.
  - The exception is raised due the fact it has been aborted.
- Validation of the creation.
  - The Type is created.
- End
Use Case 2
- createType with an existing initabspath and parameter modal = false
  - The user will create a Type
- The application uses the T1C function createType using as parameter an existing initPath and the modal set to false.
- No prompt will be proposed to the end user but the Type is created.
- End
Use Case 3
- createType with a non existing initPath (whatever the value true or false of the flag modal)
  - The user will create a Type.
- The application uses the T1C function createType with as parameter a non existing initPath.
- A prompt must appear with default value.
- The user selects (or not) a directory and cancels or validates the creation:
  - Cancellation of the creation.
    The exception is raised due the fact it has been aborted.
  - Validation of the creation.
    The Type is created.
- End

createTypeDirs

Create directories for a context mapping.

Interface

createTypeDirs(entity: string, type: string, relPath: [string], modal?: boolean, timeout?: number, callback?: (error: T1CLibException, data: FileListResponse) => void): Promise<FileListResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context
relpath: a relative path based on the context root folder
modal: indicate if the folder dialog must be shown
timeout: optional timeout in seconds before the folder dialog is discarded)

Output

{
    data: FileList
    success: boolean
}

updateType

Update a context mapping. A folder dialog will be opened and a new root context path can be choosen.

Interface

updateType(entity: string, type: string, timeout?: number, callback?: (error: T1CLibException, data: TypeResponse) => void): Promise<TypeResponse>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context
timeout: timeout in seconds before the folder dialog is discarded)

Output

{
    data: Type
    success: boolean
}

deleteType

Delete a context mapping.

Interface

deleteType(entity: string, type: string, callback?: (error: T1CLibException, data: boolean) => void): Promise<boolean>;

Parameters

entity: the entity context where the type mapping is persisted.
type: the entity type mapping context

Output

{
    data: boolean
    success: boolean
}

Error Responses

The error codes mentioned are added to the File Exchange container. The exception handling follows the framework exception handling and are extensions of status codes mentioned on:

v3.7.x

Introduction

A Word of Introduction

Concept

Architecture Overview

Components

Web Environment

Shared Environment Host

Shared Environment Client

Central Back-Office

Security

Pin Handling

Share Environment Flows

Communication Stack

Prerequisites

Trust1Connector API DNS

DNS rebind protection

Applications using the Trust1Connector

Distribution Service

Disk Space

Windows

MacOS

API Key

Operating System

Windows 8.1 or higher

Registry keys

Cookies

Browsers

Trust1Connector JS SDK

Changelog

Legend

v3.7.11

Release notes

Bug

Task

Story

Improvement

v3.7.10

Release Notes

Bug

Task

Story

Improvement

v3.7.9

Bug

Task

Story

Improvement

v3.7.7

Bug

Story

Improvement

v3.7.5

Bug

v3.7.4

Task

Story

v3.7.2

v3.7.1

v3.7.0

🔺Mutex

🔺System time out of sync

✅ Private Network Access

​☑️ Sync log files with DS

​☑️ HTTP verify response signature

v3.6.3

Bug

Improvement

Story

v3.6.1

Bug

Improvement

Story

🔺 Consent error code update

🔺 Multi-client support and race condition fix

🔺 Implicit creation of LaunchAgents folder on Mac/OSX

☑️ Exposed Camerfirma interface

☑️ Exposed Chambersign interface

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

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

☑️ Sync log files with DS

☑️ HTTP verify response signature