Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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
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
In the example you can see that we load the Javascript SDK on line 8
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.
We also provide an npm package that makes it easier to load and use the Trust1Connector Javascript SDK as a module.
<!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><script defer src="./T1CSdk.js"></script>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.
The following schematic seems rather complicated as it explains the inner workings of the Trust1Connector components, the concept is explained 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 and go directly to the following section: Integration in Web Applications
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.
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
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.
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
When receiving ports during post-install, an user agent device is temporary RESERVED in the Agent Registry of the T1C-Registry. 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 .
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).
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.
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:
The different architectures supported by the Trust1Connector
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
This document describes all achievable different scenario’s with pros and cons, depending on the business case.
To understand how the Trust1Connector can be setup, it is good to have an overview of all components in the Trust1Connector eco system.
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.
Trusted browser and no PIN encryption between the browser and the connector application interface.
Untrusted browser and PIN encryption enforced through the connector application interface.
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.
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.
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
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.
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.
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.
The variants decribed hereafter differs in how the packager stores the files and executables during installation.
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.
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.
provide an CLI param override mechanism, which is a pass-through for the overriden params to the executables (api/reg/sandbox)
An optional Local Registry for multi-host or shared environments.
It is required when using Trust1Connector on a shared machine with multiple users. The component is optional, and a central registry can be used as well. The integrating party must choose whether to opt for a local dynamic registry or a central Distribution Service Registry
T1C-Registry [Centralised]
An optional Centralised Registry for multi-host or shared environments. The service can only be used when a Distribution Service is provided in the solution architecture.
It is required when using Trust1Connector on a shared machine with multiple users. The component is optional, and a local dynamic registry can be used as well. The integration party must choose whether to opt for a decentralised or centralised approach. When choosing a centralised approach, a Distribution Service setup is needed.
T1C-DS
The Trust1Connector Distribution Server is a central management service for the T1C.
The DS is serving use cases for version management, demographic information, key rotation, additional security protection, dynamic CORS, application management and more
Virtual Reader
The remote loading implementation for a backend smart card service
The virtual card reader acts as a remote smart card reader, able to communicate with any card on a remote client enabling HSMs (High security modules), central card management systems, smart card personalisation use cases and more
API Gateway
An optional API gateway introduced when using the T1C-DS for security policy enforcement
As the T1C-DS acts as a REST microservice, additional security measurement must be taken into account. The API gateway implements different security policies applied on:
Device to DS communication
Application to DS communication
application application management
Component
Description
Note
T1C-SDK-JS
An easy to use Javascript SDK for quick integration into partner web applications
This is an optional component which can be used to ease and speed up the integration of the Trust1Connector into any web application. The SDK acts as an interface for the consuming web application and supports backwards compatibility
REST Client
A 3rd Party Rest client
Any REST client can be used to address the Trust1Connector use cases directly from your consuming application. Applications can be native desktop applications or web applications in any technology
T1C-Sandbox
A secured Sandbox for smart card APDU execution, exposing a gRPC interface
The Sandbox can be used directly for certain applications, but it’s main goal is to isolate the APDU interactions towards smart cards, and card readers (contact or contactless)
T1C-Rust-API
An OpenAPI REST interface, acting as an addressable microservice.
The local REST Service, installed on the local device, serving the functionality used directly from consuming applications or from the T1C-SDK-JS. The OpenAPI YAML is published and can be used to generate a REST client in any technology








T1C-Registry [Decentralised]
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)

For initialisation of the T1C you need to prepare your application first by adding the SDK JS files to your project and importing them in such a way that you can call for the Javascript functions when you need them. When you've succesfully downloaded and installed the Trust1Connector you can initialize and use the Trust1Connector
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.
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.
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.
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
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 .
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.
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.
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
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
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;
Trust1Connector v3 Documentation
The Trust1Connector Javascript SDK is a library that functions as a proxy towards the Trust1Connector API. This Library does not contain any business logic and is a refernce implementation for the Trust1Connector API (HTTP/JSON).
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.
The Trust1Connector is a middleware which interacts with hardware tokens and system certificate stores (where certificates are stored and protected within the operating system).
The ambitions of the Trust1Connector is to:
provide a generic interface to hardware tokens and smart cards
operating system agnostic (works for all operating systems)
browser agnostic (not depending on a browser plugin)
You can find the trust1connector JS SDK for the Trust1Connector v3 via NPM
You can also find the source code here
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
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
facilitate the derivation towards a mobile identity
favours a decentralized approach and privacy-first
facilitate user authentication and digital signatures
facilitates identity information validation and secured transport
favours a Zero-Knowledge approach
exchange Verifiable Claims

apikey
string
API-key received from Trust1Team
Production
51983
https://ds.t1t.io
Acceptance
51883
https://acc-ds.t1t.io
Develop
51783
None
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
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.
As mentioned, when a card-reader has pin-pad capabilities, this will be mentioned in the response (notice the pinpadproperty):
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.
Possibility to exclude certain readers based on their name. the input accepts a comma separated list if multiple exclusion terms are needed
This exclude readers will search for the term in the reader names and exclude those that match with the term
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:
this family share the same functionalities and the description of the ID-One Cosmo V7 applies to all versions including the “-n” subject to this validation.
This document describes the functionality provided by the Oberthur ID-One smartcard - which is a PKI container:
ID-One Cosmo V7-n; FIPS 140-2 Security Policy
All model information can be found in the Token typings model page
When initialisation is finished you can continue using the aventra object to execute the functions below.
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
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;
The expected response for this call should be;
The expected response for this call should be;
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;
This will return information of the Aventra card.
The expected response for this call should be;
When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not.
Contains the 'root certificate' stored on the smart card. The service can be called:
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, authentication and singing. The service can be called:
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. The service can be called:
The expected response for these calls should be in the following format;
The expected response for these calls should be in the following format;
Data can be signed using the smartcard. To do so, the SDK facilitates in:
Retrieving the certificate chain (root, intermediate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed has
To sign data, an algorithm must be specified in the algorithm property (see Supported Algorithms), 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 Bulk PIN 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.
The expected response for this call should be;
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
The PIN set for bulk signing can be reset by calling this method.
Response will look like:
The SDK 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.
The expected response for this call should be;
The expected response for this call should be;
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.
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 readers functionality
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;
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.
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;
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.
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
these are the exposed functions available on the T1CClient to initialize a module
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 initialized correctly in order to access the all resource.
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.
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 initialized the Trust1Connector you can execute the rest of the Trust1Connector's functionality, for example listing the readers and fetching information from a specific smart card.
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
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.
Possibility to exclude certain readers based on their name
This exclude readers will search for the term in the reader names and exclude those that match with the term
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):
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.
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:
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
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.
Via the pushLogs function you can trigger the Trust1Connector to send out the log files towards the Distribution service.