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

v3.8.8

v3.8.7

v3.8.6

v3.8.4

v3.8.3

v3.8.2

v3.8.1

v3.7.13

v3.7.11

v3.7.10

v3.7.9

v3.7.7

v3.7.5

v3.7.4

v3.7.2

v3.7.1

v3.7.0

🔺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.

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.

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

v3.6.1

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

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.

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

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

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

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,...

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)

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.

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.

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.

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

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.

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, ...

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:

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 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.

Exclude readers

Possibility to exclude certain readers based on their name. the input accepts a comma separated list if multiple exclusion terms are needed

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:

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:

1. /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.

2. /v3_5/downloads/installers/{{OS}}/versions/{{version}}: This endpoint allows you to download a specific version of a T1C installer for a specific OS.

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);

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.

Example upgrade flow

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

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

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:

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.

Architecture Overview

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 process [t1c-registry]

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-Registry 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-Registry 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 process [t1c-api]

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-Registry for available ports and will reserve those post, prior to initialisation and startup.

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

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

The T1C-sandbox 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-sandbox 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-Registry 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:

Share Environment Flows

Communication Stack

Overview

The Trust1Connector can be configured to comply with different installation scenario’s. This can be done when packaging the Trust1Connector, and is managed through setting the correct command-line arguments upon startup. To facilitate this, the Trust1Connector ships with a partner specific launcher which can be adapted to comply with different reqeusts.

The Trust1Connector can be installed in different ways, depending on the requirements for a specific business context. By default the Trust1Connector uses the best approach for a device in an unknown context.

The different setups describes below all share *the same codebase*. For each target the executables are exactly the same.

We achieve this through command line parametrization of the executable. Updating the CLI parameters for the API or Registry modifies the behaviour of the runtime execution.

This provides us with the following benefits:

• same code base, same binaries

• change behaviour for a specific context

• change behaviour at runtime

The installation profiles, as we tend to have many command line arguments, are encapsulated in a separate executable, this is called 't1c-launch'.

The 't1c-launc' does the following:

• validate the environment

• validate prerequisites

• start the connector executables

• provide the correct CLI params, decided upon compilation time

• provide an CLI param override mechanism, which is a pass-through for the overriden params to the executables (api/reg/sandbox)

This document describes all achievable different scenario’s with pros and cons, depending on the business case.

Overall Components

To understand how the Trust1Connector can be setup, it is good to have an overview of all components in the Trust1Connector eco system.

Offline Modes

The Trust1Connector can be installed in ‘offline’ mode. This is the case when:

• no internet connection is available

• no centralised Distribution Service is available/wanted

Following this approach, the installation base (devices with T1C installed) is managed from an software application distribution platform (version management, insights, …).

The Trust1Connector is fully functional in an offline environment and contains all module logic in the installation footprint. The options explained here describes what are the possible modes for offline installations.

Offline Desktop Mode

Trusted browser and no PIN encryption between the browser and the connector application interface.

Offline Web-encryption Desktop Mode

Untrusted browser and PIN encryption enforced through the connector application interface.

Offline Shared Environment Mode

The Shared Registry executable is introduced to resolve client address ports during initialization. The shared registry runs a single instance on one of the connected clients OR the host application.

When the host is NOT running the shared registry, clients are dynamically checking if a registry is available. When a registry instance is not found, a random client launches a registry instance, untill the client becomes unavailable.

Online Modes

In this mode the Distribution Service is used for one or both of the following categories of use cases:

• connector client instance synchronization

• central port resolution

The former category denotes the device synchronization and management operational use cases.

The lattter adds to the functionality by acting as a central registry, becoming a critical component during connector client instance initialization.

In that scenario, connector instances are always bound to DS (Distribution Service); the DS is the centralized service handling the address port resolution for every client. A client will register it’s dynamically assigned port (from a configurable port range) at the DS. The DS resolves the address port for each web application trying to connect with it’s local client. The handshake is performed using an the web application consent flow.

Online Desktop Mode

The DS is a central service collection all anonimized operation data for every linked connector instance.

The DS serves the operational use cases:

• demographic information

• SSL and Device certificate rotation

• client-demand log dispatching

• CORS management

• application application management

Online Web-encryption Desktop Mode

The communication from the web application towards the connector instance is secured and requires pre-requested JWT from the Distribution Service.

The local connector instances enforces JWT validation prior to use case execution.

Additional functionality for device key-rotation and application registry bindings are available in this context.

Online Shared Environment Mode with Local Host/Client Registry

In this mode, DS communication is established but not blocking operationally once installed.

PIN Encryption and shared registry is configured on the host or on the client dynamically (local election algorithm). The shared registry stores a list of agents, keeping track of agents-port correlation.

The JWT authentication/validation on API is optional and configured during packaging.

An extension on the profile above, is when an admin runs the 'registry' process on-startup, as a service user, in a shared environment. This means that the registry process will run always, and will not be changed throughout user sessions (especially when a user session gets invalidated, or stays acive even when de user has logged out.

For shared environments, our recommendation is to start the registry process on a shared environment for all remote terminals/clients.

Online Shared Environment Mode with Central Registry

The DS keeps track of the client address ports and resolves the port upon every new session between the browser and the local connector instance during initialisation. Additionally the public key for web application encryption is shared between the registry and the requestion client application.

Other Variants

The variants decribed hereafter differs in how the packager stores the files and executables during installation.

Shared Environments Share User Image

In this mode, a user image is by default stateless and the connector is initialized upon every new user session.

This implies that the connector instance will register upon startup, for every new user login.

The user always starts with a clean installation when logged-in. This approach resembles with how Docker starts new images instances and can be used thus in a Docker image.

Shared Environments Share Binary Folder

This variant is called ‘split installer’ and splits the location of the executables during installation and the user session related configuration files (transaction info, consent, device certificates, logs, …).

In this approach, the executables are provision in a predefined path (typically system program files or system folder).

The user session related files are stored in a user specific folder location.

Introduction

The connector is using a DNS (depending on the connector partner), with a default value of:

The given URL is registered with DNSSEC enabled, and resolves to a 'localhost' domain.

Although the connector can run in a different mode (http, localhost, custom domain name, etc.), to solve the above issue, the following causes are probable:

• DNS Rebind is enforced from your router or ISP (Internet Service Provider)

• The domain name is not whitelisted in your internal network

• A local proxy is running and prevents the internal connector communication

• An antivirus is blocking the connector communication

• Your (custom) DNS server does not contain resolution for localhost and t1c.t1t.io

The functionality for automatic DNS Rebind resolutation solves the local connectivity issue by adding the DNS used by the connector to the host file of the device.

As the connector is running in user-mode, and thus not have elevated rights, a separate process will be started on the operating system, asking the user to enter the `admin password` only with the purpose of adding the record to the host file of the system.

When a user does not have `administrator` access to his device, and IT administrator can solve the issue (an apply it to all users from that domain).

Logical Flow

The following diagram show the logic begin the one-time check. The process runs on startup on a seperate system thread, and when executed succesfully, persists a marker file (.dnsrebind) in the installation directory of the connector.

Process States

Clean

Starting from from a clean installation, it will go trough the flow above and based on the outcome of the DNS resolving, the process will update the hostfile and create the markerfile

Success - marker present

The process will go trough the flow above and when successful, a DNS check is executed which a successful response.

Success - no marker present

The process will go trough the flow above and when successful, the process will create the marker file without the need of updating the hostfile

Failure - marker present

The process will go trough the flow above and when `failure`, the process will see the marker file, resulting in a error message that it could not resolve the domain. In this scenario, the markerfile indicates that the hostfile has been updated so the problem must be elsewhere.

Failure - no marker present

The process will go trough the flow above and when `failure`, the process will create the marker file and update the hostfile. When the final DNS check fails and it will return an error message.

Here the markerfile also indicates that the hostfile has been updated so the problem must be elsewhere.

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
  ) {
  }
}

export class TokenVersionResponse extends T1CResponse {
  // use union type to be backwards compatible with versions before 3.6.0
  constructor(
    public data: TokenVersion,
    public success: boolean,
    public signature?: string
  ) {
    super(success, data, signature);
  }
}

export class TokenVersion {
  constructor(
    version: string,
  ) {}
}

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.

// Config object definition
export class T1CConfigOptions {
  constructor(
    public t1cApiUrl?: string,
    public t1cApiPort?: string,
    public t1cProxyUrl?: string,
    public t1cProxyPort?: string,
    public jwt?: string
  ) {}
}



// example
const configoptions = new T1CSdk.T1CConfigOptions(
  environment.t1cApiUrl,
  environment.t1cApiPort,
  environment.t1cProxyUrl,
  environment.t1cProxyPort,
  environment.jwt
);
config = new T1CSdk.T1CConfig(configoptions);

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.

curl --location --request GET 'https://acc-ds.t1t.io/v3_5/tokens/application' \
--header 'apikey: your-api-key'

Example response

{
    "success": true,
    "data": "eyJraWQiOiJ0MWNkcyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJ0MWNkcy1hcHAiLCJzdWIiOiJkZXZlbG9wbWVudCIsImV4cCI6MTU5OTA1MTExMywiaWF0IjoxNTk5MDQ5OTEzLCJuYmYiOjE1OTkwNDk5MDh9.LE_AdYv9PWxqSRm6-lkV_3TxInCqbf_hTwHFKCFfYwkuzex6AMkeW6FaVCOxu-EBU158S2g70i4VBpeT2TAr0IoOyjK-nalvVG5aB9MwidZMtiPlidcUfsDhsyhbhwqlhI2dzB5J5KsBmvZwpoG-Pg2koUSidruixg3SxRrCMotBRlRNKItnYgfs6_wvd_OOLXs2OlufYOD876MWcJymBK48wf9ESQ50clR3zwPAQsNnXFq2Augk0gOlCgWO1--WgaFeMnBF28b7genZXIkwZCfT82nRYtiOs0zLK2WtyireTHDgjIZif4nX8pggE7t_63Hbv8wCvv8_Mg2PfdhCMQ"
}

Refresh JWT token

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:

const configoptions = new T1CSdk.T1CConfigOptions(
  environment.t1cApiUrl,
  environment.t1cApiPort,
  environment.t1cProxyUrl,
  environment.t1cProxyPort,
  environment.jwt
);
config = new T1CSdk.T1CConfig(configoptions);

T1CSdk.T1CClient.initialize(config).then(res => {
        client = res;
        console.log("Client config: ", client.localConfig)
        core = client.core();
    }, err => {});

The function's interface is as follows;

updateJWT(jwt: string, callback?: (error: T1CLibException, data?: T1CClient) => void): Promise<T1CClient>

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

core.updateJWT("jwt").then(client => {}, error => {});

Distribution services

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:

{
  description: "some error description",
  code: "some error code"
}

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

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;

1. Integration of the API

2. 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;

export class GCLConfigOptions {
    constructor(public gclUrl?: string,
                public gwOrProxyUrl?: string,
                public apiKey?: string,
                public gwJwt?: string,
                public tokenExchangeContextPath?: string,
                public ocvContextPath?: string,
                public dsContextPath?: string,
                public dsFileContextPath?: string,
                public pkcs11Config?: Pkcs11ModuleConfig,
                public agentPort?: number,
                public implicitDownload?: boolean,
                public forceHardwarePinpad?: boolean,
                public sessionTimeout?: number,
                public consentDuration?: number,
                public consentTimeout?: number,
                public syncManaged?: boolean,
                public osPinDialog?: boolean,
                public containerDownloadTimeout?: number,
                public localTestMode?: boolean,
                public lang?: string,
                public providedContainers?: T1CContainerid[]) {
    }
}

With the v3 this is significantly simplified to the following;

class T1CConfigOptions {
  constructor(
    public t1cApiUrl?: string,
    public t1cApiPort?: string,
    public t1cProxyUrl?: string, // deprecated
    public t1cProxyPort?: string, // deprecated
    public jwt?: string,
    public applicationDomain?: string, // "rmc.t1t.be"
  ) {}
}

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:

config = new GCLLib.GCLConfig(configoptions);
    GCLLib.GCLClient.initialize(config).then(res => {
        client = res;
        core = client.core();
        console.log("GCLClient: ", res)
    }, err => {
        console.log("GCL error:", err)
    })

V3 example;

config = new T1CSdk.T1CConfig(configoptions);
T1CSdk.T1CClient.initialize(config).then(res => {
    client = res;
    console.log("Client config: ", client.localConfig)
    core = client.core();

}, err => {
    errorHandler(err);
});

Introduction

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

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

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

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.

const beid = client.beid(reader_id);

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

beid.allData(filters).then(...).catch(...)

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.

// pin and pin_type are needed for luxid
const generic = client.generic(reader_id, pin, pin_type)

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

generic.allData('beid', filters).then(...).catch(...)

Generic Payment

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

const generic = client.paymentGeneric(reader_id)

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

generic.readData('emv').then(...).catch(...)

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

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>;
  allAlgoRefs(module: string, callback?: (error: T1CLibException, data: TokenAlgorithmReferencesResponse) => void): Promise<TokenAlgorithmReferencesResponse>
  resetBulkPin(module: string, callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;
}

Generic Payment interface

export interface AbstractPaymentGeneric {
  readApplicationData(module: string, callback?: (error: T1CLibException, data: PaymentReadApplicationDataResponse) => void): Promise<PaymentReadApplicationDataResponse>;
  readData(module: string, callback?: (error: T1CLibException, data: PaymentReadDataResponse) => void): Promise<PaymentReadDataResponse>;

  allCerts(module: string, aid: string, filters: string[] | Options, callback?: (error: T1CLibException, data: PaymentAllCertsResponse | TokenAllCertsExtendedResponse) => void): Promise<PaymentAllCertsResponse | TokenAllCertsExtendedResponse>;
  issuerPublicCertificate(module: string, aid: string, callback?: (error: T1CLibException, data: PaymentCertificateResponse) => void): Promise<PaymentCertificateResponse>;
  iccPublicCertificate(module: string, aid: string, callback?: (error: T1CLibException, data: PaymentCertificateResponse) => void): Promise<PaymentCertificateResponse>;

  allCertsExtended(module: string, aid: string, filters: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
  issuerPublicCertificateExtended(module: string, aid: string, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
  iccPublicCertificateExtended(module: string, aid: string, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;

  verifyPin(module: string, body: PaymentVerifyPinData, callback?: (error: T1CLibException, data: PaymentVerifyPinResponse) => void): Promise<PaymentVerifyPinResponse>;
  resetBulkPin(module: string, callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;
  sign(module: string, body: PaymentSignData, bulk?: boolean, callback?: (error: T1CLibException, data: PaymentSignResponse) => void): Promise<PaymentSignResponse>;
}

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

public generic = (reader_id: string, pin?: string, pinType?: PinType): AbstractEidGeneric => {
    return this.moduleFactory.createEidGeneric(reader_id, pin, pinType)
};

public paymentGeneric = (reader_id: string): AbstractPaymentGeneric => {
    return this.moduleFactory.createPaymentGeneric(reader_id)
};

public fileex = (): AbstractFileExchange => {
    return this.moduleFactory.createFileExchange()
};

public rawprint = (): AbstractRawPrint => {
    return this.moduleFactory.createRawPrint()
};

public beid = (reader_id: string): AbstractEidBE => {
    return this.moduleFactory.createEidBE(reader_id)
};

public remoteloading = (reader_id: string): AbstractRemoteLoading => {
    return this.moduleFactory.createRemoteLoading(reader_id)
};

public emv = (reader_id: string): AbstractEmv => {
    return this.moduleFactory.createEmv(reader_id)
};

public crelan = (reader_id: string): AbstractCrelan => {
    return this.moduleFactory.createCrelan(reader_id)
};

// get instance for Aventra
public aventra = (reader_id: string): AbstractAventra => {
    return this.moduleFactory.createAventra(reader_id);
}

// get instance for Oberthur
public oberthur = (reader_id: string): AbstractOberthur73 => {
    return this.moduleFactory.createOberthur(reader_id);
}

// get instance for Oberthur
public idemia = (reader_id: string): AbstractIdemia => {
    return this.moduleFactory.createIdemia(reader_id);
}

public luxeid = (reader_id: string, pin: string, pin_type: PinType): AbstractEidLux => {
    return this.moduleFactory.createEidLUX(reader_id, pin, pin_type);
}

public wacom = (): AbstractWacom => {
    return this.moduleFactory.createWacom();
}

public diplad = (reader_id: string): AbstractEidDiplad => {
    return this.moduleFactory.createEidDiplad(reader_id);
}

public certigna = (reader_id: string): AbstractCertigna => {
    return this.moduleFactory.createCertigna(reader_id);
}

public certinomis = (reader_id: string): AbstractCertinomis => {
    return this.moduleFactory.createCertinomis(reader_id);
}

public dnie = (reader_id: string): AbstractDNIe => {
    return this.moduleFactory.createDNIe(reader_id);
}

public safenet = (reader_id: string): AbstractSafenet => {
    return this.moduleFactory.createSafenet(reader_id);
}

public eherkenning = (reader_id: string): AbstractEherkenning => {
    return this.moduleFactory.createEherkenning(reader_id);
}

public jcop = (reader_id: string): AbstractJcop => {
    return this.moduleFactory.createJcop(reader_id);
}

public airbus = (reader_id: string): AbstractAirbus => {
    return this.moduleFactory.createAirbus(reader_id);
}

public luxtrust = (reader_id: string): AbstractLuxTrust => {
    return this.moduleFactory.createLuxTrust(reader_id);
}

public camerfirma = (reader_id: string): AbstractCamerfirma => {
    return this.moduleFactory.createCamerfirma(reader_id);
}

public chambersign = (reader_id: string): AbstractChambersign => {
    return this.moduleFactory.createChambersign(reader_id);
}

Introduction

The Belgian eID container facilitates communication with card readers with inserted Belgian eID smart card. The T1C-JS client library provides function to communicate with the smart card and facilitates integration into a web or native application. This document describes the functionality provided by the Belgian eID container on the T1C

Interface

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

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

  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>;
}

Models

Get Belgian eID container object

Initialise a Trust1Connector client:

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

Get the Belgian eID container service:

var beid = client.beid(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": ["Belgian eID Card"]
      },
      "id": "57a3e2e71c48cee9",
      "name": "Bit4id miniLector",
      "pinpad": false
    }
  ],
  "success": true
}

We notice that a card object is available in the response in the context of a detected reader. The reader in the example above is Bit4id miniLector, has no pin-pad capabilities, and there is a card detected with given ATR and description "Belgian eID Card". An ATR (Answer To Reset) identifies the type of a smart-card. The reader, has a unique ID, reader_id; this reader_id must be used in order to request functionalities for the Belgian eID card. This must be done upon instantiation of the Belgian eID container:

var beid = client.beid(reader_id);

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

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