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...
The Trust1Connector requires a user consent to function. This consent will be stored in the browsers localstorage for that user.
The consent token is stored with a domain specific key;t1c-consent-{{applicationDomain}}::{{apiUrl}}
When executing the consent flow, the user will be provided with a consent token which can be pasted into his clipboard. This token has to be passed with the Consent function which will perform a verfication (the token pasted in the clipboard - form the application context - should match with the token available on the clipboard for the T1C).
The consent can be configured to have an expiration date, when this expiration date has been exceeded, a new consent will be asked towards the user.
Upon installation of the Trust1Connector, a user will not be able to retrieve any data from the connector without first giving its consent, agreeing to give access to his/her card reader of filestorage. Without this consent, all requests will return a 401/404 Unauthorized response with error No valid consent found or at initialisation of the Trust1Connector SDK an error No valid consent found. The application should detect these errors and use it to trigger the consent dialog.
The application shows this code word on screen and provide a button for 'copy-to-clipboard'. When the user has copied the code word to the clipboard (on user click button event), an implicit consent request can be executed towards the T1C. The T1C will grab the pasted code word from the user system clipboard and if both match, an implicit user consent has been granted for the calling application. The relation between the application and the local T1C instance is 'approved'. At this point the Trust1Connector returns a verified consent object that is stored in the browser's localstorage. This object is used to validate the consent and retrieve the necessary information for the Trust1Connector to function. This object will be re-used the next time the user wants to use the Trust1Connector until the consent expires.
The clipboard value is a random value that is used to determine which agent you are running. This clipboard value needs to be pseudorandom so that we dont accidently find different agent.
The Javascript has an exposed function that creates this value for you.
The function is statically available on the T1CClient
class and has the following interface.
public static generateConsentToken(): string
This will return the randomly generated value as a string value immediatley.
To call this;
# regular imported javascript via script tag
T1CSdk.T1CClient.generateConsentToken()
# Import loaded via NPM
import {T1CClient} from "t1c-sdk-js";
T1CClient.generateConsentToken()
If you decide not to use this function, the value needs to be prefixed with `::t1c::miksa::
Initially the concept was based on copying programmatically the code word, from the application context, to the user system clipboard. Although, through CAB forum, this not allowed; A user interaction is mandatory. The application should provide a 'copy-to-clipboard' button or alike in order to 'trigger' a user action. Once this action has been done, the T1C can be triggered to execute the consent.
Currently, the need for a user interaction is a known limitation (aka. clipboard.js). As this is the case, the W3C has a project ' Clipboard APIs' to propose a solution for a new clipboard API in browsers. The use case for 'Remote clipboard synchronisation' as a use case included in this draft proposal. As this is a draft, and not yet supported by the browsers, we can not perform an automatic 'paste' ('copy' in terms of the browser) to the clipboard.
Sending an implicit consent request can be done as follows:
T1CSdk.T1CClient.initialize(config).then(res => {
client = res;
console.log("Client config: ", client.localConfig)
core = client.core();
}, err => {
if(err.code == 814501 || err.code == 814500) {
console.log(err)
client = err.client
$('#consentModal').modal('show', {
keyboard: false
});
$('.consent-token').text(client.core().generateConsentToken());
} else if (err.code == 112999) {
// Unavailable
} else {
console.error("T1C error:", err)
}
});
The code below is an example of a javascript event handler on a consent button.
$('#consentModal .btn-primary').on('click', (ev) => {
const tokenNode = document.querySelector('.consent-token');
var range = document.createRange();
range.selectNode(tokenNode);
window.getSelection().addRange(range);
try {
document.execCommand('copy');
} catch (err) {
console.log('Oops, unable to copy');
}
window.getSelection().removeRange(range);
const clipboardData = tokenNode.textContent;
const validityInDays = 365
client.core().getImplicitConsent(clipboardData, validityInDays).then(consentRes => {
client = consentRes // replace the client and other set variables of the T1C
core = client.core();
core.version().then(versionResult => console.log("T1C running on core " + versionResult));
$('#consentModal').modal('hide');
}, err => {
console.error(err)
})
});
This call has 1 required and 2 optional parameters:
Code Word (required): a code word in string format that will be shown in the consent dialog.
Consent duration in days (optional): Allows the application the specify how long this consent is to be valid if granted. If not provided, the default value is 365 days.
Callback function (optional): function to be called with the result of the consent request.
The response of the consent will be an updated T1C Client which you after this point can use to continue your use-case(s).
The response can also be a 400 Bad Request with status code 814501 "Invalid consent" or 814500 "No agents registered" which means that the request has been sent with the unique code but the Registry cannot not find the user associated with it by checking the clipboards of all connected users.
This could mean that there is no T1C API client present or it is not running correctly.
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 elaborate further on this page. If you are only interested in what the integration impact is for your Web Application in a Shared Environment, you can skip directly to the section: Integration in Web Applications
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-Proxy
and only exposes the following use cases:
Verify random available ports [in a predefined range] which can be used by an Agent (Session of T1C-API running in user space)
Port reservation upon installation of a new T1C-API in an active user session
Port registration upon initialisation of a T1C-API in an active user session
Management of an in-memory list of active Agents
Management of user consents in a shared environment by means of browser cookies with an optional configurable TTL (time to live)
The T1C-Proxy
operates by Default on the API port defined in the T1C-DS
(Distribution Server). From a Web Application perspective, this is the only information known. When a Web Application requests the information of the device, the PROXY device type will inform the Web Application that the targeted underlying API is a PROXY, which means that the Web Application must ask for the Agent specific API port to configure an URI which can be used to execute the use cases.
When using the T1C-SDK-JS
this is done implicitly during initialisation.
A T1C-API
installed for a specific users runs in [User Space]. To avoid possible attack vectors, the Trust1Connector v3 will always run in [User Space].
Upon installation of the T1C-API
, during the post install phase, the T1C-API
will try to verify automatically if it is running in a shared environment. If this is the case, the T1C-API
will ask the T1C-Proxy for available ports and will reserve those post, prior to initialisation and startup.
The ports which are reserved by the T1C-Proxy
are the following:
T1C-API
Port: This is the port exposing the OpenAPI interface towards Web Applications and used by the T1C-SDK-JS
When receiving ports during post-install, an user agent device is temporary RESERVED
in the Agent Registry of the T1C-Proxy
. Upon T1C-API initialisation, the port configurations will be confirmed and the Agent Registry will set the device state on REGISTERED
. From this moment on, a T1C-API instance, running in an active user session, will be available for the Web Application via the consent flow.
The T1C-gRPC
instance is inherently a component from the T1C-API
, and thus is managed by the T1C-API
. As each user must have it's own hardened runtime for communication purpose, the port assigned for T1C-gRPC
will be registered and configured by the T1C-API
(and restarted when needed).
Starting from this release (v3) of the Trust1Connector, each device must have a link with an active and running T1C-DS (Trust1Connector Distribution Server). This is to guarantee security, updates, and avoid potential risk in production.
The T1C-DS is proceeded by an API Gateway who is managing the security offloading in the application layer. For a Web Application to communicate with a T1C-Proxy or T1C-API, a JWT (Json Web Token) is needed and obliged. The T1C-DS is responsible for the key management, the certificate management and other use cases which are described in a separate wiki.
In order to retrieve a valid JWT, the T1C-DS can be requested from your application back-end with a valid api-key. The JWT is valid for a given amount of time, and sets the context used when requesting the T1C-API on a device.
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:
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.
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 multi user 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 (even at the same time).
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 single instance with consent mode 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. You can retrieve such token via the Distribution Service based on the API key you received.
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.
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"
) {}
}
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
// ...
let environment = {
t1cApiUrl: 'https://t1c.t1t.io',
t1cApiPort: '51983',
t1cProxyUrl: 'https://t1c.t1t.io',
t1cProxyPort: '51983',
jwt: 'eyJraWQiOiJ0MWNkcyIsImFsZyI6IlJTMjU2In0..._Mg2PfdhCMQ',
applicationDomain: 'test-app'
};
const configoptions = new T1CSdk.T1CConfigOptions(
environment.t1cApiUrl,
environment.t1cApiPort,
environment.t1cProxyUrl,
environment.t1cProxyPort,
environment.jwt,
environment.applicationDomain
);
config = new T1CSdk.T1CConfig(configoptions);
// ...
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.
// When remote DS is used set the following parameter
config.dsUrl = "https://acc-ds.t1t.io";
Now we can continue to use the config
variable to initialize and retrieve a T1CClient
If you need to set up the Trust1Connector with a valid JWT token you can follow the documentation on the Authenticated Client page to retrieve a valid token 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 refresh your token to continue to use the Trust1Connector. More information on how to retrieve,use and refresh a token can be found on the Authenticated Client page.
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 specific single modus enabled. More information can be found here. 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 Consent is required(when a central or local registry is present) or when the modus is set to optional consent. 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 Consent page which explains it in more detail.
If you have the optional consent mode 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.
// ...
T1CSdk.T1CClient.initialize(config).then(res => {
client = res;
console.log("Client config: ", client.localConfig);
core = client.core();
core.version().then(versionResult => console.log("T1C running on core "+ versionResult));
}, err => {
if (err.code == 814500 || err.code == 814501) {
client = err.client;
// (new) Consent is required
}
else if(err.code == 112999) {
// Could not connect with the Trust1Connector
} else {
// an uncatched error occured
console.error("T1C error:", err)
}
});
// ...
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 copy some data to its clipboard. 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;
public getImplicitConsent(codeWord: string, durationInDays?: number,
callback?: (error?: T1CLibException, data?: T1CClient) => void
): Promise<T1CClient>
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
client.core().getImplicitConsent(document.querySelector(".clipboard-data").innerHTML).then(res => {
console.log("Consent Executed")
client = res;
// Use the client for your use-cases
}, err => {
// Failed, use the error client to retry the consent
this.client = err.client;
console.error(err.description ? err.description : err)
})
After this you will have a client
that can be used to execute the rest of the functionality that the Trust1Connector has to offer.
// Global client to be used over the entire application
const client = null
// Prepare the configuration
let environment = {
t1cApiUrl: 'https://t1c.t1t.io',
t1cApiPort: '51983',
t1cProxyUrl: 'https://t1c.t1t.io',
t1cProxyPort: '51983',
jwt: 'eyJraWQiOiJ0MWNkcyIsImFsZyI6IlJTMjU2In0..._Mg2PfdhCMQ',
applicationDomain: 'test-app'
};
const configoptions = new T1CSdk.T1CConfigOptions(
environment.t1cApiUrl,
environment.t1cApiPort,
environment.t1cProxyUrl,
environment.t1cProxyPort,
environment.jwt,
environment.applicationDomain
);
config = new T1CSdk.T1CConfig(configoptions);
// Initialize the Trust1Connector with the previously created configuration object
T1CSdk.T1CClient.initialize(config).then(res => {
client = res;
console.log("Client config: ", client.localConfig);
core = client.core();
core.version().then(versionResult => console.log("T1C running on core "+ versionResult));
}, err => {
if (err.code == 814500 || err.code == 814501) {
// (new) Consent is required
}
else if(err.code == 112999) {
// Could not connect with the Trust1Connector
} else {
// an uncatched error occured
console.error("T1C error:", err)
}
});
// when the user has clicked on the clipboard/consent button we execute the getImplicitConsent function
document.querySelector(".clipboard").addEventListener("click", (ev) => {
if (client != null) {
client.core().getImplicitConsent(document.querySelector(".clipboard-data").innerHTML).then(res => {
console.log("Consent Executed")
client = res;
// Use the client for your use-cases
}, err => {
this.client = err.client;
console.error(err.description ? err.description : err)
})
}
})
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.
// ...
T1CSdk.T1CClient.initializeExplicitConsent(config).then(res => {
client = res;
console.log("Client config: ", client.localConfig);
core = client.core();
core.version().then(versionResult => console.log("T1C running on core "+ versionResult));
}, err => {
if (err.code == 814500 || err.code == 814501) {
client = err.client;
// (new) Consent is required
}
else if(err.code == 112999) {
// Could not connect with the Trust1Connector
} else {
// an uncatched error occured
console.error("T1C error:", err)
}
});
// ...
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 clipboard API but this is not fully supported yet
const tokenNode = document.querySelector('.consent-token');
var range = document.createRange();
range.selectNode(tokenNode);
window.getSelection().addRange(range);
try {
// Now that we've selected the anchor text, execute the copy command
document.execCommand('copy');
} catch(err) {
console.log('Oops, unable to copy');
}
// Remove the selections - NOTE: Should use
// removeRange(range) when it is supported
window.getSelection().removeRange(range);
const clipboardData = tokenNode.textContent;
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
apikey
string
API-key received from Trust1Team
{
"success": true,
"data": "eyJraWQiOiJ0MWNkcyIsImFsZyI6IlJTMjU2In0...v8_Mg2PfdhCMQ"
}
{
"message": "No API key found in request"
}
{
"success": false,
"description": "Invalid API key",
"code": 1005,
}
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.
The port numbers of the Trust1Connector are;
Production
51983
https://ds.t1t.io
Acceptance
51883
https://acc-ds.t1t.io
Develop
51783
None
This document will describe how you can set up your desired module or generic module for using the functionalities that each module have. This ofcourse requires you to succesfully initialized the Trust1Connector via initialize or authenticated client and have a valid reader to contact
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.
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(...)
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 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.
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(...)
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.
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>;
}
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>;
}
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
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);
}
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
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<script defer src="./T1CSdk.js"></script>
</head>
<body>
...
</body>
</html>
In the example you can see that we load the Javascript SDK on line 8
<script defer src="./T1CSdk.js"></script>
The defer attribute means that the script will be downloaded in parallel with the rest of the web-page but will be executed when the page has finished loading in.
This is mostly used to make sure that when the Javascript wants to target a specific element on the page, for example a div, that this element has already been loaded and is accessable.
We also provide an npm package that makes it easier to load and use the Trust1Connector Javascript SDK as a module.
Trust1Connector v3 Documentation
The Trust1Connector Javascript SDK is a library that purely functions as a proxy towards the Trust1Connector API. This Library does not contain any business logic.
Sample code uses ES6 language features such as arrow functions and promises. For compatibility with IE11, code written with these features must be either transpiled using tools like Babel
or refactored accordingly using callbacks which are also available on the Trust1Connector Javascript SDK.
✅
Improvement upon the Trust1Connector
🔺
Bugfix
☑️
Story / new feature for the Trust1Connector
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.
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 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.
Javascript SDK 3.6.0 has been unpublished and contains a bug in the consent flow where the error code is not returned correctly
The Mac Silicon (M1) is not yet supported for this version
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)
You can find an example for certigna here
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.
The Trust1Connector API v3 exposes a secure REST API on the client device. Trust1Team has created a t1c.t1t.io
DNS entry (or customer-specific DNS entry) that points to 127.0.0.1
in order to facilitate SSL communication. This means that if the customer infrastructure uses a proxy for all network traffic, an exemption must be made for t1c.t1t.io
to always point to the origin device's loopback address. The same holds true for the localhost domain name, this should redirect to 127.0.0.1
on the user's local system, not the localhost of the proxy server.
If no exemption is made and https://t1c.t1t.io
is handled by a proxy, it will redirect to 127.0.0.1
IP of the proxy server instead of the local machine, and the Trust1Connector API will be unreachable.
The reserved domain from Trust1Team (t1c.t1t.io) has been registered with DNSSEC on the aforementioned URI. When a PARTNER uses its own DNS, we strongly recommend applying DNSSEC on the domain used in production.
Some (corporate) networks have a policy that disables the ability to bind a domain to a local network IP. The Trust1Connector relies on this for t1c.t1t.io
which resolves in to 127.0.0.1
which is a local ip for localhost
If DNS rebind protection is enabled it is unable to use t1c.t1t.io for connection towards the Trust1Connector because the network does not allow this Domain to be a local ip-address.
To resolve the issue either DNS rebind protection can be disabled or you can whitelist the domain t1c.t1t.io
to allow this domain.
Applications that want to make use of the Trust1Connector will be run from a specific domain. This means that the Trust1Connector needs to know that certain domains/applications want to make use of the Trust1Connector's functionality.
For these applications to gain access to the Trust1Connectors API we need to whitelist the domain in whats called the cors
list. This list contains all the accepted domains that can make use of the Trust1Connector.
In order to correctly function, the Trust1Connector API must be able to connect to its configured Distribution Service. You must allow REST traffic to the following URLs (if applicable):
Acceptance: https://acc-ds.t1t.io
Production: https://ds.t1t.io
A partner can opt for its own Distribution server, whereas the URIs mentioned above, will be defined by the hosting party.
The option of working without Distribution Service is also possible. You can find all the possibilities to run the Trust1Connector here
In some cases (environments) the Domain acc-ds.t1t.io
or ds.t1t.io
are not accessable. If this is because the domain cannot be resolved we do recommend to either ask the network/system administrator to make sure that those domains can be resolved on the network. Or changing the DNS server to the google DNS (8.8.8.8 & 8.8.4.4), this has solved the issue for some of our customers.
Trust1Connector installer is about 20Mb in size. The installed size comes to 40-50Mb.
This includes the Trust1Connector API, Registry and Sandbox.
Trust1Connector installer is about 20Mb in size. The installed size comes to 40-50Mb.
This includes the Trust1Connector API, Registry and Sandbox.
The increased size over windows mainly comes to the way MacOS handles dialogs. These are distributed with the Trust1Connector as seperate binaries.
All endpoints of the Trust1Connector API are secured and require a JWT to access. To obtain a token, an API key must be exchanged.
This API key must be requested from TRUST1TEAM, or created by the customer if they are hosting their own Distribution Service. The API key must never be used in a front-end application (where the API key can be compromised). The API key is needed to exchange the token, using a Distribution Server, resulting in a short-lived Json Web Token.
A PARTNER can decide to distribute a version without the use of a JWT. In those cases, the liability of the security flow resides completely in the context of the web application, thus Trust1Team can not guarantee the security context where the Trust1Connector is integrated upon.
Trust1Connector support two operating systems for all tokens, Linux (Debian/Ubuntu) for PKCS11 tokens; On request, a Google Chromebook can be supported depending on the deployment or target installer.
MacOS 11.x or higher
X86 architecture
M1/M2/ARM architecture
Windows 810 or higher
Trust1Team support Windows/Mac OSX OS families where lifecycle support is guaranteed from the Vendor of the Operating System. The moment the OS version has been marked as ‘end of life’, Trust1Team can not guarantee the functionality anymore.
When PARTNERS are in need to support an older version or keeping the support running on the level of Trust1Team, no guarantees can be made. Trust1Team can setup a custom project, on demand of the PARTNER. Those requirements, changes or other adaptations needed, are not covered in the Trust1Connector license fee.
Windows 7
No
EOL but some partners are running a custom compiled target of the Trust1Connector in production until migration.
Windows 8.1
No
EOL but some partners are running a custom compiled target of the Trust1Connector in production until migration.
Windows 10
Yes
Windows 11
Yes
macOS 10.15 (Cataline)
No
EOL
macOS 11 (Big Sur)
Yes
macOS 12 (Monterey)
Yes
macOS 13 (Ventura)
Yes
macOS 14 (Sonoma)
Yes*
2023-10
macOS 14 (Sonoma) has issues at the moment with usblib and CCID. A future patch will fix the card reader issues; Updates will be come avaible when a patch is released
To run in user-space on Windows 8.1 or higher some components have to be set on the operating system
Below you can find a list of all registry keys that will be created for the working of the Trust1Connector, All these keys are added to HKCU
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\SOFTWARE\Trust1Team\Trust1Connector
Since 3.5.x no more cookies are used.
The Trust1Connector is browser agnostic so it does not matter what browser is being used as long as it support HTTP communication (HTTP 1.1) (which should all of them).
Version wise we do recommend to use the latest versions of your browser for security reasons but the versions below is was we accept as a minimum
Chrome >80
Firefox >75
Edge 88 or higher
IE 11 (End of Life is June 15 2022)
All other browsers. As recent as possible
When you already have a V2 integrated this page will provide you with some easy steps to quickly migrate to the V3 of the Trust1Connector. Migration from the v2 to the v3 of the Trust1Connector can be done in 2 ways;
Integration of the API
Integration via the deprecated Javascript SDK
Both are viable integrations. When integrating via the API you have more control over the functionality and the dependencies used.
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.
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"
) {}
}
V2 config option
V3 config option
Description
gclUrl / gwOrProxyUrl
t1cApiUrl
in the V2 this was https://localhost:10443 while in the V3 this will be https://t1c.t1t.io (for T1T)
t1cApiPort
is the port where the webserver is listening on, in the v2 this is 10443 but in the v3 by default(T1T) this is 51983
t1cProxyPort
This value represents the port where the Proxy webserver is listening on. By default this is 51983 (obsolete)
t1cProxyUrl
Similar to the api url this is the URL where the proxy used in shared environment is running on. This is by default the same as the API url (obsolete)
applicationDomain
Host of the web application the Trust1Connector is being used on. This property is used to make sure no collisions can happen
apiKey
/
gwJwt
jwt
JWT token used for authentication of the web application towards the Trust1Connector. This must be retrieved from the web applications backend
tokenExchangeContextPath
/
ocvContextPath
/
dsContextPath
/
in v2 this was the context path for the DS based on the gwOrProxyUrl
dsFileContextPath
/
pkcs11Config
/
agentPort
/
implicitDownload
/
forceHardwarePinpad
/
sessionTimeout
/
consentDuration
/
syncManaged
/
osPinDialog
/
boolean which depicts the default os pin dialog value
containerDownloadTimeout
/
localTestMode
/
lang
/
providedContainers
/
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);
});
For more information regarding initialization we suggest the Initialize page
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.
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 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"
}
Refreshing the JWT token can only be done after a first successfull initialisation of the Trust1Connector. This means the Trust1Connector has to be initialised with a valid configuration the first time. When the token expires after first successfull initialisation you can use the refreshJWT function described below
A JWT token is only valid for a certain period. After this period the API will return an error. At this point you need to request a new JWT token to be able to communicate with the API.
In the T1C JS SDK there is a function which you can use to re-initalise the client with a new valid JWT token. This should be done when you receive a 104025
error-code which means you do not have a valid JWT
The updateJWT
function can be found in the Core
service. After initialising you can retrieve the core as follows:
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 => {});
Environment
DS url
Acceptance
https://acc-ds.t1t.io
Production
https://ds.t1t.io
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.
This page describes all generic token models used.
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
) {
}
}
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 Core Service
Returns a list of available card readers. Multiple readers can be connected. Each reader is identified by a unique reader_id
.
T1CSdk.T1CClient.initialize(config).then(res => {
var coreService = res.core();
core.readers(callback);
})
The response will contains a list of card readers:
{
"success": true,
"data": [
{
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false,
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card (eID)"
],
"module": ["beid"]
}
}
]
}
When multiple readers are attached to a device, the response will show all connected card readers:
{
"data": [
{
"id": "ec3109c84ee9eeb5",
"name": "Identiv uTrust 4701 F Dual Interface Reader(2)",
"pinpad": false
},
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card"
],
"module": ["beid"]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
},
{
"id": "c8d31f8fed44d952",
"name": "Identiv uTrust 4701 F Dual Interface Reader(1)",
"pinpad": false
}
],
"success": true
}
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.
{
"data": [
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card"
],
"module": ["beid"]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
}
],
"success": true
}
As mentioned, when a card-reader has pin-pad capabilities, this will be mentioned in the response (notice the pinpad
property):
{
"data": [
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card"
]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
}
],
"success": true
}
The following example is the response for List card-readers
on a device with 4 different card-readers attached:
{
"data": [
{
"id": "ec3109c84ee9eeb5",
"name": "Identiv uTrust 4701 F Dual Interface Reader(2)",
"pinpad": false
},
{
"card": {
"atr": "3B67000000000000009000",
"description": [
"MisterCash & Proton card",
"VISA Card (emitted by Bank Card Company - Belgium)"
],
"module": ["emv"]
},
"id": "e5863fcc71478871",
"name": "Gemalto Ezio Shield Secure Channel",
"pinpad": true
},
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card"
]
"module": ["beid"]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
},
{
"id": "c8d31f8fed44d952",
"name": "Identiv uTrust 4701 F Dual Interface Reader(1)",
"pinpad": false
}
],
"success": true
}
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.
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.
T1CSdk.T1CClient.initialize(config).then(client => {
var coreService = client.core();
core.readersCardAvailable(callback);
}, err => {
console.error(err);
});
Response:
{
"data": [
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": []
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
}
],
"success": true
}
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.
The Generic token interface is an interface used to integrate all supported tokens. This interface relies on the fact that you will need to provide a valid module. The module suggested from the reader response can be used here.
export interface AbstractEidGeneric {
allData(module: string, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllDataResponse) => void): Promise<TokenAllDataResponse>;
allCerts(module: string, parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsResponse) => void): Promise<TokenAllCertsResponse>;
biometric(module: string, callback?: (error: T1CLibException, data: TokenBiometricDataResponse) => void): Promise<TokenBiometricDataResponse>;
tokenData(module: string, callback?: (error: T1CLibException, data: TokenInfoResponse) => void): Promise<TokenInfoResponse>;
address(module: string, callback?: (error: T1CLibException, data: TokenAddressResponse) => void): Promise<TokenAddressResponse>;
picture(module: string, callback?: (error: T1CLibException, data: TokenPictureResponse) => void): Promise<TokenPictureResponse>;
rootCertificate(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
intermediateCertificates(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
authenticationCertificate(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
nonRepudiationCertificate(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
encryptionCertificate(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
issuerCertificate(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateResponse) => void): Promise<TokenCertificateResponse>;
allCertsExtended(module: string, parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
rootCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
intermediateCertificatesExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
authenticationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
nonRepudiationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
encryptionCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
issuerCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
verifyPin(module: string, body: TokenVerifyPinData, callback?: (error: T1CLibException, data: TokenVerifyPinResponse) => void): Promise<TokenVerifyPinResponse>;
authenticate(module: string, body: TokenAuthenticateOrSignData, callback?: (error: T1CLibException, data: TokenAuthenticateResponse) => void): Promise<TokenAuthenticateResponse>;
sign(module: string, body: TokenAuthenticateOrSignData, bulk?: boolean, callback?: (error: T1CLibException, data: TokenSignResponse) => void): Promise<TokenSignResponse>;
signRaw(module: string, body: TokenAuthenticateOrSignData, bulk?: boolean, callback?: (error: T1CLibException, data: TokenSignResponse) => void): Promise<TokenSignResponse>;
allAlgoRefs(module: string, callback?: (error: T1CLibException, data: TokenAlgorithmReferencesResponse) => void): Promise<TokenAlgorithmReferencesResponse>
resetBulkPin(module: string, callback?: (error: T1CLibException, data: BoolDataResponse) => void): Promise<BoolDataResponse>;
}
All model information can be found in the Token typings model page
Initialise a Trust1Connector client with a valid configuration:
T1CSdk.T1CClient.initialize(config).then(res => {
client = res;
}, err => {
console.error(error)
});
In order to get all connected card-readers, with available cards:
var core = client.core();
core.readersCardAvailable(callback);
This function call returns:
{
"data": [
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": ["Belgian eID Card"]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false,
"suggestedModule": "beid"
}
],
"success": true
}
As you can see in the response we get a property suggestedModule
which is returned based on the card, reader and AID information. This suggested module can be used in the generic interface.
Using the generic interface can be done as follows;
var generic = client.generic(selected_reader.id, pin, pinType);
The pin and pinType are optional and are used for unlocking the pace layer (if the card is protected with a pace layer).
At this point for each use-case you will need to provide the module. This can be manually defined or be retrieved from the suggestedModule
property in the reader-response. In the examples below we provide the module as a variable module
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).
Contains all card holder related data, excluding the card holder address and photo. The service can be called:
generic.biometric(module, options, callback);
An example callback:
function callback(err,data) {
if(err){
console.log("Error:",JSON.stringify(err, null, ' '));
}
else {
console.log(JSON.stringify(data, null, ' '));
}
}
Response:
{
"birthDate": "15 JUL 1993",
"birthLocation": "Roeselare",
"cardDeliveryMunicipality": "Avelgem",
"cardNumber": "592..8233",
"cardValidityDateBegin": "27.05.2015",
"cardValidityDateEnd": "27.05.2025",
"chipNumber": "U0xHk...EstwAjEpJQQg==",
"documentType": "01",
"firstNames": "Gilles Frans",
"name": "Platteeuw",
"nationalNumber": "930...154",
"nationality": "Belg",
"nobleCondition": "",
"pictureHash": "Fqva9YCp...JKyn8=",
"rawData": "AQw1OTIxMjQwNTgy...TARFBar2vWAqTW+axEIuyskBgFySsp/",
"sex": "M",
"signature": "hKys9WMjUm4ipg...14xUCg/98Y9/gP/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
"specialStatus": "0",
"thirdName": "J",
"version": "0"
}
Contains the card holder's address. The service can be called:
generic.address(module, callback);
Response:
{
"municipality": "Hoeselt",
"rawData": "ARJLZXJrc...AAAAAA==",
"signature": "mhPyeRg25H...w==",
"streetAndNumber": "Kerkstraat X",
"version": "0",
"zipcode": "3730"
}
Contains the card holder's picture stored on the smart card. The service can be called:
generic.picture(module, callback);
Response:
{
"data": "/9j/4AAQSkZJRgABA...59aVpcklSDzyKUTEDGK//9k=",
"success": true
}
The token info contains generic information about the card and it's capabilities. This information includes the serial number, file types for object directory files, algorithms implemented on the card, etc.
Response
{
"data": {
"eid_compliant":48,
"electrical_perso_interface_version":0,
"electrical_perso_version":3,
"graphical_perso_version":7,
"label":"BELPIC",
"prn_generation":4,
"raw_data":"MCcCAQAEEFNMSU4z...JFTFBJQwMCBDCeBAcDAAA=",
"serial_number":"534C494E..1231C",
"version":0,
"version_rfu":0
},
"success": true
}
Exposes all the certificates publicly available on the smart card.
You can also fetch the extended versions of the certificates via the functions
allCertsExtended(module: string, parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
rootCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
intermediateCertificatesExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
authenticationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
nonRepudiationCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
encryptionCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
issuerCertificateExtended(module: string, parseCerts?: boolean, callback?: (error: T1CLibException, data: TokenCertificateExtendedResponse) => void): Promise<TokenCertificateExtendedResponse>;
this has the capabilities to return multiple certificates if the token has multiple of this type.
for a single certificate the response looks like:
{
"success" : true
"data" : {
"certificates": [{
"certificate"?: string,
"certificateType"?: string,
"id"?: string,
"subject"?: string,
"issuer"?: string,
"serialNumber"?: string,
"url"?: string,
"hashSubPubKey"?: string,
"hashIssPubKey"?: string,
"exponent"?: string,
"remainder"?: string,
"parsedCertificate"?: Certificate
}]
}
}
the allCertsExtended
returns the following, with the contents of the certificates as the one you can see above;
{
"success" : true
"data" : {
"rootCertificate": {
"certificates": [...]
},
"authenticationCertificate": {
"certificates": [...]
},
"nonRepudiationCertificate": {
"certificates": [...]
},
"intermediateCertificates": {
"certificates": [...]
},
"encryptionCertificate": {
"certificates": [...]
}
}
}
Contains the 'root certificate' stored on the smart card. The root certificate is used to sign the 'citizen CA certificate'. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not. The service can be called:
generic.rootCertificate(module, parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
You can also fetch the root certificate via the function rootCertificateExtended
this has the capabilities to return multiple certificates if the token has multiple of this type.
The response looks like:
{
"success" : true
"data" : {
"certificates": [
"certificate"?: string,
"certificateType"?: string,
"id"?: string,
"subject"?: string,
"issuer"?: string,
"serialNumber"?: string,
"url"?: string,
"hashSubPubKey"?: string,
"hashIssPubKey"?: string,
"exponent"?: string,
"remainder"?: string,
"parsedCertificate"?: Certificate
]
}
}
Contains the 'authentication certificate' stored on the smart card. The 'authentication certificate' contains the public key corresponding to the private RSA authentication key. The 'authentication certificate' is needed for pin validation and authentication. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
generic.authenticationCertificate(module, parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
You can also fetch the root certificate via the function authenticationCertificateExtended
this has the capabilities to return multiple certificates if the token has multiple of this type.
The response looks like:
{
"success" : true
"data" : {
"certificates": [
"certificate"?: string,
"certificateType"?: string,
"id"?: string,
"subject"?: string,
"issuer"?: string,
"serialNumber"?: string,
"url"?: string,
"hashSubPubKey"?: string,
"hashIssPubKey"?: string,
"exponent"?: string,
"remainder"?: string,
"parsedCertificate"?: Certificate
]
}
}
Contains the citizen certificate stored on the smart card. The 'citizen certificate' is used to sign the 'authentication certificate' and the 'non-repudiation certificate'. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
generic.intermediateCertificates(module, parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
You can also fetch the root certificate via the function intermediateCertificateExtended
this has the capabilities to return multiple certificates if the token has multiple of this type.
The response looks like:
{
"success" : true
"data" : {
"certificates": [
"certificate"?: string,
"certificateType"?: string,
"id"?: string,
"subject"?: string,
"issuer"?: string,
"serialNumber"?: string,
"url"?: string,
"hashSubPubKey"?: string,
"hashIssPubKey"?: string,
"exponent"?: string,
"remainder"?: string,
"parsedCertificate"?: Certificate
]
}
}
Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
generic.nonRepudiationCertificate(module, parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
{
"success" : true
"data" : {
"certificates": [
"certificate"?: string,
"certificateType"?: string,
"id"?: string,
"subject"?: string,
"issuer"?: string,
"serialNumber"?: string,
"url"?: string,
"hashSubPubKey"?: string,
"hashIssPubKey"?: string,
"exponent"?: string,
"remainder"?: string,
"parsedCertificate"?: Certificate
]
}
}
The response looks like:
You can also fetch the root certificate via the function nonRepudiationCertificateExtended
this has the capabilities to return multiple certificates if the token has multiple of this type.
Contains the 'encryption certificate' stored on the smart card. The 'encryption certificate' corresponds to the private key used to sign the 'biometric' and 'Address' data. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
generic.encryptionCertificate(module, parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
You can also fetch the root certificate via the function encryptionCertificateExtended
this has the capabilities to return multiple certificates if the token has multiple of this type.
The response looks like:
{
"success" : true
"data" : {
"certificates": [
"certificate"?: string,
"certificateType"?: string,
"id"?: string,
"subject"?: string,
"issuer"?: string,
"serialNumber"?: string,
"url"?: string,
"hashSubPubKey"?: string,
"hashIssPubKey"?: string,
"exponent"?: string,
"remainder"?: string,
"parsedCertificate"?: Certificate
]
}
}
Contains the 'encryption certificate' stored on the smart card. The 'encryption certificate' corresponds to the private key used to sign the 'biometric' and 'Address' data. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
generic.allCerts(module, parseCertsBoolean, callback);
Response:
{
"rootCertificate": {
...
},
"authenticationCertificate": {
...
},
"nonRepudiationCertificate": {
...
},
"intermediateCertificates": {
...
},
"encryptionCertificate": {
...
}
}
You can also fetch the root certificate via the function allCertsExtended
this has the capabilities to return multiple certificates if the token has multiple of this type.
The response looks like:
{
"success" : true
"data" : {
"rootCertificate": {
"certificates": [...]
},
"authenticationCertificate": {
"certificates": [...]
},
"nonRepudiationCertificate": {
"certificates": [...]
},
"intermediateCertificates": {
"certificates": [...]
},
"encryptionCertificate": {
"certificates": [...]
}
}
}
All data on the smart card can be dumped at once, or using a filter. In order to read all data at once:
var filter = [];
generic.allData(module, { filters: filter}, callback);
Response:
{
"picture": {
"picture": "/9j/4AAQSkZJRgABAgEBLAEsAAD/.../wAALCADIAIwBAREA/8QA0gAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/2gAIAQEAAD8A9JpKKWiikooooopaKSilooooopKr3d9bWaFriVEwM4J5Ncjq3jUxkixQADozjJNcze+L9WndWF20OOCI/lzRb+KtYjhIN67Z7vyf1qT/AIS3Wc5F2OnQgY/lWrovjC7hYLqJ86IkksPvCustPEumXbbUuAjYzh+K1UkWRA6MGU9CDkGn0UUUUUUUhOBk8CuY1zxOls/kWjbnH3pAMgewrz7VtWmu7gvJIzZ65NZk1wSBjOagWbn5lB+vagy7+2KlilUE7eRj1qS3ncSEE4X3qwzNs81Dgg9K19G8VXumTLFv8yDOWjb+len6bqMGp2qz2zZU8Ed1PpVyiiiiio5pkgiaSRgqKMkmuH8ReKXlMlpAAkHRnB5b29q4+e5HzAHjPFZkoLyhevH6014XUcjBqAow5xQEYjFPClDxkCnq20AkZ/xqyl2oUK4xu6n0qwgguZQ28K2Ofc1v6Pqs2lSRGJzsLAOv94d69MtriO6gSaFgyMMg1LS0UUlcn491FbfS/sicyzEH6AGvOCzuApPOakt7CWYk7TjNXE0iUNnyyfpVqPQ53XiNwPepYfDMhb94GAq5/wAIzbhc4IPpVK/8OYjzEMmsWbRZ0XIUnHtVRrR4/vqR9RSwQGXdt4Zav2rbFww6DI5ruvBuqIIjaSuMu2Y8/TpXYUtFFIa8r8W6h9v1d9mCqHYuO4FVdM0t7iZWb8a6y10+KNQCOlXFijQfKop6g9hUmw4pjoRzmopEyvIqrJEjDGKpXGnwzoQ68+1YNxpv2Ry8RPHrVGUqse4MN38Qq7o8o8kOh+dG3AjsRXpejapHqVsDkLMo+dM8/WtOiis/WrxrHTJp1GWAwOeme9eWqqzTln6k5rqNLhWKFcDmtJRk1aSPPWp0i21J5dRSx8VWKVXkQA1WmwvGDzWVegSRsp4zXNT2WwMASSxqa1kNimMBkOB9fWt7QLx4ddgaNCyyLtIHevR6Wiuf8ZsRobAdWcD+dcLYQZlHck/lXWQKEjUVZj69OlXI+manXnvTiADioXPJ4qBhVaQ/NVWbkZ7VlXeDmqRYY27Rn1rOmkDXOwKBgH8av6XOba9guVz8hA2+1epg5GaWiuf8ZqTom4fwyKf5iuS0uFiQcV0MYwgBqxH1FWl6VLGeKcxOOaaRmoZAcVTkBqrOcL61j3B5NVgducVXkeOOXLKMt1p9tIsyjaAMGvVI+I1+gp9FZXiOAT6LcKRnaN35Vy+lhfKJ9Kv+cifeYACpIry3A5kA+tW1uYmXKuD+NSRzDseKl3gjrTS47UhYAGqFxINxqhcSA8ZrPlQmq8kZArNujljkdBUuhAy3cUOOWdRXrY4FLRUN0iSW8iSkBGUg5riLGMrbzxq3IkI3CozpuWZmnkye+6qT6TlmPnkk9M1Smsbq3OUuOOvWtDTrq4j+V5CRn1rpIZy6ZNSbiBz1qneXphFcpqmqzyNiJiBnqKyl+33DDZJL9dxq2i6pDg7mYehNX7a/lx5d5EADwGHUVBeR/MfT2q/4It2n10vtykY3H29K9MpaSsLxKJJo4oI5Ci53NjvWbbweUGAH3sE5qG8DpnqB7CsKNru7umitUKgdXbqay3m1L7cluxlMm/DAqMYrqLfTW5DKAw7joa1LRCnDVNelYo91cXq13NcMfLDbAcA+tVbXTppyzMrNtGSq9RTP7VhgZY44HBP+1k1Zi1LzZNgbOexGCKS8kwQcc1LM4ayeT0Sl8M+IhpDzfuA4kwCe+BXqFldxXtrHcQnKOMjNWKSsfV48zI3qMVVwpIA5xxTpI1bqBVNrRQ25EwfVaja3cybtgz/eK81ahjKrz1pTwR6k1U1aQ/Zm57VhQKDGhAyBWxatHACUXbuHOO9Yt3plol01wkWSTnGazLixaW5EsSbSO4q5HZu6Ey9R0qLUQYNOcdA3FY1vGS4wK9f8NQtBolurdSC2PrWtRWfqoHlI3cHFZUXJJ9TU3U4xxTguKdsyM1FINtQNjcKpauC1uwHORWLYsAAhPStqOPKAjoaHhU8Fc1G0KDouKgmUBTisDXCTBGoxgtk1W02AysoUclgK9it4hDBHGOiKFqWiqWppvtT7EGsgKoGVJB7ip161KoWlY4qrctjGOpqCJd74JqLUlVYic8YrlI22ySSKehzXUWDCa2RxzkVaaMVUnXaDWXdzBVIzziuf1Pc80MS9x1rd8Maa39qxRucqhDtj2r0elopkiCRGRuhGKxJreaFipQlB/EBTA2Dih5tg4ySeAKlUnbufr6VBOpkBA4PassR3NtIZJJ/MB/h24xWDr+rySYihU+/NZULXMkXlrHyepFdfoYaG1RG5IFa7yZTIrNv5gqHmudnn3zgdeazrjL3+7PyggV6J4QgY28ly643YRT64610tFFJTXXcjL6jFc+/BIP8ACcUKoEm888YFI13GuVkbafehZ4uu8UOYpVwGGazp9KtmYs2AfempZQx524pyusRAyKkEuXU9jxWNrUxUsnc1k26F50U9WIFd1F4N08XCzu0rdCUJ4Jro0RY0VEUKqjAA7U+iiikrCvV2Xki9ic1BExDYPOKL6xhvIdrqM9j6VjmwNuNiu6/8CzUiW0uw73bOOCADVO7hulGRIxY9iOKy5RfgnbKB+NLZWWp3EwMtwBHnPU8106xrFGiZzt5JNcpqdyLnVWVOUU81a0GL7TrdsmMgOCfoDmvUaWiiiikrM1aHlJh0HBrNBAcZqcnH0qJ1EnBGaqvGy/dPFU51mfv+tVRaNnLc/Wp0cRLgHmqup35hs2AJ8xxgYrBijKRlm+8eSa6nwLbbryW4b+EYFd5RRRRRRVXURmxlz7fzrmDJ820noavoQ0WCcmlQZpXjBGarMijpzVedBtJNZczbSTmsW6k864BY/Kvaomk3sFB4rtfBO398F6BcV19FFFFFFVr/AJs5fpXLXEJK716imWt5tOxzir6Tqe9JLcAcbhUTTrt4Iqhc3IOQGrA1C/CcZ56VkPOzHr1p0JZ32r07mu/8ELsaYZ5K5rsKKKKSloqtfnFnL9KwkAP41Qv7I53R9ax5ri5tzhg31qm+qzdDzUb6zKBjAqlNqkrZxwTWe8jSOSSSalhiaRgO1a1tAsYA711/hA7bpx6qa7CikpaSio1njZioYZHWs/UdQtmhlgjnjeUYyinJHPes2M5HNPYDbiqr28cvyuoIqjceH7eQ5AI+lZ0vhyME4Z/zqjPoiRZ5aqBslRulXbe3woOKtLGc8itvQJxbXqseh4NdRPqaxpujjMnqAcYHrToNShlAz8h96mkvLeJQ0k8aKe7MBT0uIZF3JNGy+qsCKqajfx2gUFvmJ6ZrB1HxUkSttIGOOtcpfeK5jC8dsxDP1f0+laehxeVp8cjcyTfOxPU1uRmpm6VAchqkEmKjkcYz0rJvGDZrJMe+Tgd6vRwbU6UpTBqS1O2ZT71vRkSJtakaARITyy+3UVyXiXUTvijEqugB+6en1rJi1AqmN7D6Gut8S61a6XKipbieSRSSXPSuBv8AUZbyQlwFXP3VGAKp7q9B0OTzdLtG/wBnH5VtR1Z6ionXnIprDI6VWkjB/i5qnPCMHAqCCAeZyKutGoWqsvBqOM4cH3rcgOQKvRNxisbxB4ettQgaZcRToM7gOv1rgEvzAvl+VE+D1K1//9k="
},
"biometric": {
"birthDate": "15 JUL 1993",
"birthLocation": "Roeselare",
"cardDeliveryMunicipality": "Avelgem",
"cardNumber": "592124058233",
"cardValidityDateBegin": "27.05.2015",
"cardValidityDateEnd": "27.05.2025",
"chipNumber": "...==",
"documentType": "01",
"firstNames": "Gilles Frans",
"name": "Platteeuw",
"nationalNumber": "...",
"nationality": "Belg",
"nobleCondition": "",
"pictureHash": "...=",
"rawData": "...+axEIuyskBgFySsp/",
"sex": "M",
"signature": ".../OlA44h4YCM/h+J14xUCg/98Y9/.../C/RB2dtVbHwFvDuafmr4ZEshTlZTLidHKlISFvFWOtsLAEPCbl5LjfQwcOKe0pDADtHb4IStBnr+aaE8oHsTaKq66Y+zt+AbwdmWOrMA5URKKf7dZkY7jt3h8KZDw36VjcytUgjxVIdqwHsDkmIjK6mJtakIwybS5wn3RiQj33/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
"specialStatus": "0",
"thirdName": "J",
"version": "0"
},
"address": {
"municipality": "Hoeselt",
"rawData": "...==",
"signature": "...+Evety1PnTE4pqXaHgBxIpk+P8kRL5W3zDV+../../..+YoHBC9KqTmSpl5KULxdnKiyCt+2RyJdzE2wyoymjRmysIhJy1wW9PRnx99S1TFqQLuc0tyBmkBPR4aFqmOq4a7zqd0q2Q1g+BbnwJ4d3oa10ia5+0kBXf0THoXv3HYIHlnwhBMfAtWzPnFrYBuAKTwyl7yBF5IFfXFpGWuVZUTJElgNcmNvsHMnAhVwDw==",
"streetAndNumber": "Kerkstraat X",
"version": "0",
"zipcode": "3730"
}
}
The filter can be used to ask a list of custom data containers. For example, we want to read only the biometric data
var filter = ['biometric'];
generic.allData(module, { filters: filter }, callback);
Response:
{
"biometric": {
"birthDate": "15 JUL 1993",
"birthLocation": "Roeselare",
"cardDeliveryMunicipality": "Avelgem",
"cardNumber": "592124058233",
"cardValidityDateBegin": "27.05.2015",
"cardValidityDateEnd": "27.05.2025",
"chipNumber": "...==",
"documentType": "01",
"firstNames": "Gilles Frans",
"name": "Platteeuw",
"nationalNumber": "...",
"nationality": "Belg",
"nobleCondition": "",
"pictureHash": "...=",
"rawData": "...+axEIuyskBgFySsp/",
"sex": "M",
"signature": ".../OlA44h4YCM/h+J14xUCg/98Y9/.../C/RB2dtVbHwFvDuafmr4ZEshTlZTLidHKlISFvFWOtsLAEPCbl5LjfQwcOKe0pDADtHb4IStBnr+aaE8oHsTaKq66Y+zt+AbwdmWOrMA5URKKf7dZkY7jt3h8KZDw36VjcytUgjxVIdqwHsDkmIjK6mJtakIwybS5wn3RiQj33/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
"specialStatus": "0",
"thirdName": "J",
"version": "0"
}
}
All certificates on the smart card can be dumped at once, or using a filter. In order to read all certificates at once:
var filter = [];
generic.allCerts(module, parseCerts, { filters: filter}, callback);
Response:
{
"rootCertificate": {
...
},
"authenticationCertificate": {
...
},
"nonRepudiationCertificate": {
...
},
"intermediateCertificates": {
...
},
"encryptionCertificate": {
...
}
}
The filter can be used to ask a list of custom data containers. For example, we want to read only the rootCertificate
var filter = ['rootCertificate'];
generic.allCerts(module, { filters: filter}, callback);
Response:
{
"rootCertificate": {
...
}
}
Data can be signed using the Belgian eID smart card. To do so, the T1C-GCL facilitates in:
Retrieving the certificate chain (citizen-certificate, root-certificate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed hash
To get the certificates necessary for signature validation in your back-end:
var filter = null;
generic.allCerts(module, { filters: filter}, callback);
Response:
{
"rootCertificate": {
...
},
"authenticationCertificate": {
...
},
"nonRepudiationCertificate": {
...
},
"intermediateCertificates": {
...
},
"encryptionCertificate": {
...
}
}
Depending on the connected smart card reader. A sign can be executed in 2 modes:
Using a connected card reader with 'pin-pad' capabilities (keypad and display available)
Using a connected card reader without 'pin-pad' capabilities (no keypad nor display available)
Security consideration: In order to sign a hash, security considerations prefer using a 'pin-pad'.
When the web or native application is responsible for showing the password input, the following request is used to sign a given hash:
var data = {
"pin":"...",
"algorithm":"sha1",
"data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
"osDialog": true
}
generic.sign(module, data, callback);
Response is a base64 encoded signed hash:
{
"success": true,
"data": {
"data" : "W7wqvWA8m9S...="
}
}
When the pin entry is done on the pin-pad, the following request is used to sign a given hash:
var data = {
"algorithm":"sha1",
"data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
"osDialog": false
}
generic.sign(module, data, callback);
Response is a base64 encoded signed hash:
{
"success": true,
"data": {
"data" : "W7wqvWA8m9S...="
}
}
The core services lists connected readers, and if they have pin-pad capability. You can find more information in the Core Service documentation on how to verify card reader capabilities.
With the function signRaw
you can sign unhashed document data. This means that the Trust1Connector will hash the value itself depending on the provided sign algorithm.
Trust1Connector only supports SHA2 hashing at this point.
When using SHA3, the Trust1Connector will convert to SHA2 implicitly
Below you can find an example
var data = {
"algorithm":"sha256",
"data":"vl5He0ulthjX+VWNM46QX7vJ8VvXMq2k/Tq8Xq1bwEw=",
"osDialog": false
}
generic.signRaw(module, data, callback);
The function looks the same as a regular sign operation but expects a base64
data object that is unhashed.
Supported hash functions (SHA2) are;
SHA256
SHA384
SHA512
It is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk
parameter set to true
to the request. Subsequent sign requests will not require the PIN to be re-entered until a request with bulk
being set to false
is sent, or the Bulk Sign Reset method is called.
When using bulk signing, great care must be taken to validate that the first signature request was successful prior to sending subsequent requests. Failing to do this will likely result in the card being blocked.
const data = {
algorithm: "sha256",
data: "E1uHACbPvhLew0gGmBH83lvtKIAKxU2/RezfBOsT6Vs=",
pin: "1234"
}
const bulk = true;
generic.sign(module, data, bulk).then(res => {
}, err => {
console.error(err)
})
The PIN set for bulk signing can be reset by calling this method.
generic.resetBulkPin(module).then(res => {
}, err => {
console.error(err)
})
Response will look like:
{
"success": true,
"data": true
}
When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:
var data = {
"pin":"..."
}
generic.verifyPin(module, data, callback);
Response:
{
"verified": true
}
When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:
var data = {}
generic.verifyPin(module, data, callback);
Response:
{
"verified": true
}
The T1C is able to authenticate a card holder based on a challenge. The challenge can be:
provided by an external service
provided by the smart card An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
External Challenge
An external challenge is provided in the data property of the following example:
var data = {
"pin": "...",
"algorithm": "sha1",
"data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E="
}
generic.authenticate(module, data, callback);
Response:
{
"success": true,
"data": {
"data" : "W7wqvWA8m9S...="
}
}
Take notice that the PIN property can be omitted when using a smart card reader with pin-pad capabilities.
Via the Trust1Connector modules you are able to retrieve available algorithms to use for Signing or Authenticate
generic.allAlgoRefs(module, callback);
The response you can expect is a list of algorithms, an example can be found below (the values below are purely examplatory)
{
"success": true,
"data": ["sha1", "sha256"]
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.
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
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>;
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>;
}
All model information can be found in the Token typings model page
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);
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
.
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).
Contains all card holder related data, excluding the card holder address and photo. The service can be called:
client.beid(reader_id).biometric(callback);
An example callback:
function callback(err,data) {
if(err){
console.log("Error:",JSON.stringify(err, null, ' '));
}
else {
console.log(JSON.stringify(data, null, ' '));
}
}
Response:
{
"birthDate": "15 JUL 1993",
"birthLocation": "Roeselare",
"cardDeliveryMunicipality": "Avelgem",
"cardNumber": "592..8233",
"cardValidityDateBegin": "27.05.2015",
"cardValidityDateEnd": "27.05.2025",
"chipNumber": "U0xHk...EstwAjEpJQQg==",
"documentType": "01",
"firstNames": "Gilles Frans",
"name": "Platteeuw",
"nationalNumber": "930...154",
"nationality": "Belg",
"nobleCondition": "",
"pictureHash": "Fqva9YCp...JKyn8=",
"rawData": "AQw1OTIxMjQwNTgy...TARFBar2vWAqTW+axEIuyskBgFySsp/",
"sex": "M",
"signature": "hKys9WMjUm4ipg...14xUCg/98Y9/gP/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
"specialStatus": "0",
"thirdName": "J",
"version": "0"
}
Contains the card holder's address. The service can be called:
client.beid(reader_id).address(callback);
Response:
{
"municipality": "Hoeselt",
"rawData": "ARJLZXJrc...AAAAAA==",
"signature": "mhPyeRg25H...w==",
"streetAndNumber": "Kerkstraat X",
"version": "0",
"zipcode": "3730"
}
Contains the card holder's picture stored on the smart card. The service can be called:
client.beid(reader_id).picture(callback);
Response:
{
"data": "/9j/4AAQSkZJRgABA...59aVpcklSDzyKUTEDGK//9k=",
"success": true
}
The token info contains generic information about the card and it's capabilities. This information includes the serial number, file types for object directory files, algorithms implemented on the card, etc.
Response can either be a BaseTokenInfo or a PKCS11TokenInfo object. Depending if its a pkcs11 token or not
{
"info": {
"rawData": "string",
"version": "string",
"serialNumber": "string",
"label": "string",
"prnGeneration": "string",
"eidCompliant": "string",
"graphicalPersoVersion": "string",
"versionRfu": "string",
"electricalPersoVersion": "string",
"electricalPersoInterfaceVersion": "string",
"changeCounter": "number",
"activated": "string",
},
"infoType": "Token"
}
Exposes all the certificates publicly available on the smart card.
You can also fetch the extended versions of the certificates via the functions
allCertsExtended(parseCerts?: boolean, filters?: string[] | Options, callback?: (error: T1CLibException, data: TokenAllCertsExtendedResponse) => void): Promise<TokenAllCertsExtendedResponse>;
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>;
this has the capabilities to return multiple certificates if the token has multiple of this type.
for a single certificate the response looks like:
{
"success" : true
"data" : {
"certificates": [{
"certificate"?: string,
"certificateType"?: string,
"id"?: string,
"subject"?: string,
"issuer"?: string,
"serialNumber"?: string,
"url"?: string,
"hashSubPubKey"?: string,
"hashIssPubKey"?: string,
"exponent"?: string,
"remainder"?: string,
"parsedCertificate"?: Certificate
}]
}
}
the allCertsExtended
returns the following, with the contents of the certificates as the one you can see above;
{
"success" : true
"data" : {
"rootCertificate": {
"certificates": [...]
},
"authenticationCertificate": {
"certificates": [...]
},
"nonRepudiationCertificate": {
"certificates": [...]
},
"intermediateCertificates": {
"certificates": [...]
},
"encryptionCertificate": {
"certificates": [...]
}
}
}
Contains the 'root certificate' stored on the smart card. The root certificate is used to sign the 'citizen CA certificate'. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not. The service can be called:
client.beid(reader_id).rootCertificate(parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
Contains the 'authentication certificate' stored on the smart card. The 'authentication certificate' contains the public key corresponding to the private RSA authentication key. The 'authentication certificate' is needed for pin validation and authentication. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
client.beid(reader_id).authenticationCertificate(parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
Contains the citizen certificate stored on the smart card. The 'citizen certificate' is used to sign the 'authentication certificate' and the 'non-repudiation certificate'. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
client.beid(reader_id).intermediateCertificates(parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
Contains the 'non-repudiation certificate' stored on the smart card. The 'non-repudiation certificate' contains the public key corresponding the private RSA non-repudiation key. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
client.beid(reader_id).nonRepudiationCertificate(parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
Contains the 'encryption certificate' stored on the smart card. The 'encryption certificate' corresponds to the private key used to sign the 'biometric' and 'Address' data. When additional parsing of the certificate is needed you can add a boolean to indicate if you want to parse the certificate or not The service can be called:
client.beid(reader_id).encryptionCertificate(parseCertsBoolean, callback);
Response:
{
success: true,
data: {
certificate?: string,
certificates?: Array<string>,
certificateType?: string,
id?: string,
parsedCertificate?: Certificate,
parsedCertificates?: Array<Certificate>
}
}
All data on the smart card can be dumped at once, or using a filter. In order to read all data at once:
var filter = [];
client.beid(reader_id).allData({ filters: filter}, callback);
Response:
{
"picture": {
"picture": "/9j/4AAQSkZJRgABAgEBLAEsAAD/.../wAALCADIAIwBAREA/8QA0gAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/2gAIAQEAAD8A9JpKKWiikooooopaKSilooooopKr3d9bWaFriVEwM4J5Ncjq3jUxkixQADozjJNcze+L9WndWF20OOCI/lzRb+KtYjhIN67Z7vyf1qT/AIS3Wc5F2OnQgY/lWrovjC7hYLqJ86IkksPvCustPEumXbbUuAjYzh+K1UkWRA6MGU9CDkGn0UUUUUUUhOBk8CuY1zxOls/kWjbnH3pAMgewrz7VtWmu7gvJIzZ65NZk1wSBjOagWbn5lB+vagy7+2KlilUE7eRj1qS3ncSEE4X3qwzNs81Dgg9K19G8VXumTLFv8yDOWjb+len6bqMGp2qz2zZU8Ed1PpVyiiiiio5pkgiaSRgqKMkmuH8ReKXlMlpAAkHRnB5b29q4+e5HzAHjPFZkoLyhevH6014XUcjBqAow5xQEYjFPClDxkCnq20AkZ/xqyl2oUK4xu6n0qwgguZQ28K2Ofc1v6Pqs2lSRGJzsLAOv94d69MtriO6gSaFgyMMg1LS0UUlcn491FbfS/sicyzEH6AGvOCzuApPOakt7CWYk7TjNXE0iUNnyyfpVqPQ53XiNwPepYfDMhb94GAq5/wAIzbhc4IPpVK/8OYjzEMmsWbRZ0XIUnHtVRrR4/vqR9RSwQGXdt4Zav2rbFww6DI5ruvBuqIIjaSuMu2Y8/TpXYUtFFIa8r8W6h9v1d9mCqHYuO4FVdM0t7iZWb8a6y10+KNQCOlXFijQfKop6g9hUmw4pjoRzmopEyvIqrJEjDGKpXGnwzoQ68+1YNxpv2Ry8RPHrVGUqse4MN38Qq7o8o8kOh+dG3AjsRXpejapHqVsDkLMo+dM8/WtOiis/WrxrHTJp1GWAwOeme9eWqqzTln6k5rqNLhWKFcDmtJRk1aSPPWp0i21J5dRSx8VWKVXkQA1WmwvGDzWVegSRsp4zXNT2WwMASSxqa1kNimMBkOB9fWt7QLx4ddgaNCyyLtIHevR6Wiuf8ZsRobAdWcD+dcLYQZlHck/lXWQKEjUVZj69OlXI+manXnvTiADioXPJ4qBhVaQ/NVWbkZ7VlXeDmqRYY27Rn1rOmkDXOwKBgH8av6XOba9guVz8hA2+1epg5GaWiuf8ZqTom4fwyKf5iuS0uFiQcV0MYwgBqxH1FWl6VLGeKcxOOaaRmoZAcVTkBqrOcL61j3B5NVgducVXkeOOXLKMt1p9tIsyjaAMGvVI+I1+gp9FZXiOAT6LcKRnaN35Vy+lhfKJ9Kv+cifeYACpIry3A5kA+tW1uYmXKuD+NSRzDseKl3gjrTS47UhYAGqFxINxqhcSA8ZrPlQmq8kZArNujljkdBUuhAy3cUOOWdRXrY4FLRUN0iSW8iSkBGUg5riLGMrbzxq3IkI3CozpuWZmnkye+6qT6TlmPnkk9M1Smsbq3OUuOOvWtDTrq4j+V5CRn1rpIZy6ZNSbiBz1qneXphFcpqmqzyNiJiBnqKyl+33DDZJL9dxq2i6pDg7mYehNX7a/lx5d5EADwGHUVBeR/MfT2q/4It2n10vtykY3H29K9MpaSsLxKJJo4oI5Ci53NjvWbbweUGAH3sE5qG8DpnqB7CsKNru7umitUKgdXbqay3m1L7cluxlMm/DAqMYrqLfTW5DKAw7joa1LRCnDVNelYo91cXq13NcMfLDbAcA+tVbXTppyzMrNtGSq9RTP7VhgZY44HBP+1k1Zi1LzZNgbOexGCKS8kwQcc1LM4ayeT0Sl8M+IhpDzfuA4kwCe+BXqFldxXtrHcQnKOMjNWKSsfV48zI3qMVVwpIA5xxTpI1bqBVNrRQ25EwfVaja3cybtgz/eK81ahjKrz1pTwR6k1U1aQ/Zm57VhQKDGhAyBWxatHACUXbuHOO9Yt3plol01wkWSTnGazLixaW5EsSbSO4q5HZu6Ey9R0qLUQYNOcdA3FY1vGS4wK9f8NQtBolurdSC2PrWtRWfqoHlI3cHFZUXJJ9TU3U4xxTguKdsyM1FINtQNjcKpauC1uwHORWLYsAAhPStqOPKAjoaHhU8Fc1G0KDouKgmUBTisDXCTBGoxgtk1W02AysoUclgK9it4hDBHGOiKFqWiqWppvtT7EGsgKoGVJB7ip161KoWlY4qrctjGOpqCJd74JqLUlVYic8YrlI22ySSKehzXUWDCa2RxzkVaaMVUnXaDWXdzBVIzziuf1Pc80MS9x1rd8Maa39qxRucqhDtj2r0elopkiCRGRuhGKxJreaFipQlB/EBTA2Dih5tg4ySeAKlUnbufr6VBOpkBA4PassR3NtIZJJ/MB/h24xWDr+rySYihU+/NZULXMkXlrHyepFdfoYaG1RG5IFa7yZTIrNv5gqHmudnn3zgdeazrjL3+7PyggV6J4QgY28ly643YRT64610tFFJTXXcjL6jFc+/BIP8ACcUKoEm888YFI13GuVkbafehZ4uu8UOYpVwGGazp9KtmYs2AfempZQx524pyusRAyKkEuXU9jxWNrUxUsnc1k26F50U9WIFd1F4N08XCzu0rdCUJ4Jro0RY0VEUKqjAA7U+iiikrCvV2Xki9ic1BExDYPOKL6xhvIdrqM9j6VjmwNuNiu6/8CzUiW0uw73bOOCADVO7hulGRIxY9iOKy5RfgnbKB+NLZWWp3EwMtwBHnPU8106xrFGiZzt5JNcpqdyLnVWVOUU81a0GL7TrdsmMgOCfoDmvUaWiiiikrM1aHlJh0HBrNBAcZqcnH0qJ1EnBGaqvGy/dPFU51mfv+tVRaNnLc/Wp0cRLgHmqup35hs2AJ8xxgYrBijKRlm+8eSa6nwLbbryW4b+EYFd5RRRRRRVXURmxlz7fzrmDJ820noavoQ0WCcmlQZpXjBGarMijpzVedBtJNZczbSTmsW6k864BY/Kvaomk3sFB4rtfBO398F6BcV19FFFFFFVr/AJs5fpXLXEJK716imWt5tOxzir6Tqe9JLcAcbhUTTrt4Iqhc3IOQGrA1C/CcZ56VkPOzHr1p0JZ32r07mu/8ELsaYZ5K5rsKKKKSloqtfnFnL9KwkAP41Qv7I53R9ax5ri5tzhg31qm+qzdDzUb6zKBjAqlNqkrZxwTWe8jSOSSSalhiaRgO1a1tAsYA711/hA7bpx6qa7CikpaSio1njZioYZHWs/UdQtmhlgjnjeUYyinJHPes2M5HNPYDbiqr28cvyuoIqjceH7eQ5AI+lZ0vhyME4Z/zqjPoiRZ5aqBslRulXbe3woOKtLGc8itvQJxbXqseh4NdRPqaxpujjMnqAcYHrToNShlAz8h96mkvLeJQ0k8aKe7MBT0uIZF3JNGy+qsCKqajfx2gUFvmJ6ZrB1HxUkSttIGOOtcpfeK5jC8dsxDP1f0+laehxeVp8cjcyTfOxPU1uRmpm6VAchqkEmKjkcYz0rJvGDZrJMe+Tgd6vRwbU6UpTBqS1O2ZT71vRkSJtakaARITyy+3UVyXiXUTvijEqugB+6en1rJi1AqmN7D6Gut8S61a6XKipbieSRSSXPSuBv8AUZbyQlwFXP3VGAKp7q9B0OTzdLtG/wBnH5VtR1Z6ionXnIprDI6VWkjB/i5qnPCMHAqCCAeZyKutGoWqsvBqOM4cH3rcgOQKvRNxisbxB4ettQgaZcRToM7gOv1rgEvzAvl+VE+D1K1//9k="
},
"biometric": {
"birthDate": "15 JUL 1993",
"birthLocation": "Roeselare",
"cardDeliveryMunicipality": "Avelgem",
"cardNumber": "592124058233",
"cardValidityDateBegin": "27.05.2015",
"cardValidityDateEnd": "27.05.2025",
"chipNumber": "...==",
"documentType": "01",
"firstNames": "Gilles Frans",
"name": "Platteeuw",
"nationalNumber": "...",
"nationality": "Belg",
"nobleCondition": "",
"pictureHash": "...=",
"rawData": "...+axEIuyskBgFySsp/",
"sex": "M",
"signature": ".../OlA44h4YCM/h+J14xUCg/98Y9/.../C/RB2dtVbHwFvDuafmr4ZEshTlZTLidHKlISFvFWOtsLAEPCbl5LjfQwcOKe0pDADtHb4IStBnr+aaE8oHsTaKq66Y+zt+AbwdmWOrMA5URKKf7dZkY7jt3h8KZDw36VjcytUgjxVIdqwHsDkmIjK6mJtakIwybS5wn3RiQj33/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
"specialStatus": "0",
"thirdName": "J",
"version": "0"
},
"address": {
"municipality": "Hoeselt",
"rawData": "...==",
"signature": "...+Evety1PnTE4pqXaHgBxIpk+P8kRL5W3zDV+../../..+YoHBC9KqTmSpl5KULxdnKiyCt+2RyJdzE2wyoymjRmysIhJy1wW9PRnx99S1TFqQLuc0tyBmkBPR4aFqmOq4a7zqd0q2Q1g+BbnwJ4d3oa10ia5+0kBXf0THoXv3HYIHlnwhBMfAtWzPnFrYBuAKTwyl7yBF5IFfXFpGWuVZUTJElgNcmNvsHMnAhVwDw==",
"streetAndNumber": "Kerkstraat X",
"version": "0",
"zipcode": "3730"
}
}
The filter can be used to ask a list of custom data containers. For example, we want to read only the biometric data
var filter = ['biometric'];
client.beid().allData({ filters: filter }, callback);
Response:
{
"biometric": {
"birthDate": "15 JUL 1993",
"birthLocation": "Roeselare",
"cardDeliveryMunicipality": "Avelgem",
"cardNumber": "592124058233",
"cardValidityDateBegin": "27.05.2015",
"cardValidityDateEnd": "27.05.2025",
"chipNumber": "...==",
"documentType": "01",
"firstNames": "Gilles Frans",
"name": "Platteeuw",
"nationalNumber": "...",
"nationality": "Belg",
"nobleCondition": "",
"pictureHash": "...=",
"rawData": "...+axEIuyskBgFySsp/",
"sex": "M",
"signature": ".../OlA44h4YCM/h+J14xUCg/98Y9/.../C/RB2dtVbHwFvDuafmr4ZEshTlZTLidHKlISFvFWOtsLAEPCbl5LjfQwcOKe0pDADtHb4IStBnr+aaE8oHsTaKq66Y+zt+AbwdmWOrMA5URKKf7dZkY7jt3h8KZDw36VjcytUgjxVIdqwHsDkmIjK6mJtakIwybS5wn3RiQj33/vgG7JTRZJoKgDXLLTvLZO4qlfA==",
"specialStatus": "0",
"thirdName": "J",
"version": "0"
}
}
All certificates on the smart card can be dumped at once, or using a filter. In order to read all certificates at once:
var filter = [];
client.beid(reader_id).allCerts(parseCerts, { filters: filter}, callback);
Response:
{
"rootCertificate": {
...
},
"authenticationCertificate": {
...
},
"nonRepudiationCertificate": {
...
},
"intermediateCertificates": {
...
},
"encryptionCertificate": {
...
}
}
The filter can be used to ask a list of custom data containers. For example, we want to read only the rootCertificate
var filter = ['rootCertificate'];
client.beid(reader_id).allCerts(parseCerts, { filters: filter}, callback);
Response:
{
"rootCertificate": {
...
}
}
As the Beid module incorperates Beid 1.7 and 1.8 there is a difference in the algorithms being used. In 1.7 we have the following;
md5
sha1
sha256
sha512
For beid 1.8 we have;
sha2_256
sha2_384
sha2_512
sha3_256
sha3_384
sha3_512
As we've noticed most integrators use sha256
and to make sure current integrations do not break we have made the Trust1Connector to map sha256
to sha3_256
for beid 1.8. Ofcourse if you want to use a specifc supported algorithm you can still select them.
By default the 1.7 will fall back to sha256
and 1.8 to sha3_256
if an incompatible algorithm is passed to the function.
The tables below explain which algorithm will be used when providing a certain algorithm value in the function;
Provided algorithm value
Selected algorithm by T1C
md5
md5
sha1
sha1
sha256
sha256
sha512
sha512
any other value
sha256
Provided algorithm value
Selected algorithm by T1C
sha2_256
sha2_256
sha2_384
sha2_384
sha2_512
sha2_512
sha3_256
sha3_256
sha3_384
sha3_384
sha3_512
sha3_512
sha256
sha3_256
sha384
sha3_384
sha512
sha3_512
any other value
sha3_256
Data can be signed using the Belgian eID smart card. To do so, the T1C facilitates in:
Retrieving the certificate chain (citizen-certificate, root-certificate and non-repudiation certificate)
Perform a sign operation (private key stays on the smart card)
Return the signed hash
To get the certificates necessary for signature validation in your back-end:
var filter = null;
client.beid(reader_id).allCerts(parseCerts, { filters: filter}, callback);
Response:
{
"rootCertificate": {
...
},
"authenticationCertificate": {
...
},
"nonRepudiationCertificate": {
...
},
"intermediateCertificates": {
...
},
"encryptionCertificate": {
...
}
}
Depending on the connected smart card reader. A sign can be executed in 2 modes:
Using a connected card reader with 'pin-pad' capabilities (keypad and display available)
Using a connected card reader without 'pin-pad' capabilities (no keypad nor display available)
Security consideration: In order to sign a hash, security considerations prefer using a 'pin-pad'.
When signing with a crelan card reader, it is additionally possible to optionally specify a transaction ID and the language. If the card reader is not a Crelan reader, these values will be ignored. This applies to all signing methods described below.
var data = {
"pin":"...",
"algorithm":"sha1",
"data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
"osDialog": true,
"txId": "1234",
"language": "fr"
}
client.beid(reader_id).sign(data, callback);
Crelan card readers only support nl
, fr
, and de
as languages
When the web or native application is responsible for showing the password input, the following request is used to sign a given hash:
var data = {
"pin":"...",
"algorithm":"sha1",
"data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
"osDialog": true
}
client.beid(reader_id).sign(data, callback);
Response is a base64 encoded signed hash:
{
"success": true,
"data": {
"data" : "W7wqvWA8m9S...="
}
}
When the pin entry is done on the pin-pad, the following request is used to sign a given hash:
var data = {
"algorithm":"sha1",
"data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E=",
"osDialog": false
}
client.beid(reader_id).sign(data, callback);
Response is a base64 encoded signed hash:
{
"success": true,
"data": {
"data" : "W7wqvWA8m9S...="
}
}
The core services lists connected readers, and if they have pin-pad capability. You can find more information in the Core Service documentation on how to verify card reader capabilities.
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.
SHA3 digest is used for the new Belgian eID cards (v1.8). The Trust1Connector falls back in this sitution by using implicitly a SHA2 digest.
Below you can find an example
var data = {
"algorithm":"sha256",
"data":"vl5He0ulthjX+VWNM46QX7vJ8VvXMq2k/Tq8Xq1bwEw=",
"osDialog": false
}
beid.signRaw(data, callback);
The function looks the same as a regular sign operation but expects a base64
data object that is unhashed.
Supported hash functions (SHA2) are;
SHA256
SHA384
SHA512
It is possible to bulk sign data without having to re-enter the PIN by adding an optional bulk
parameter set to true
to the request. Subsequent sign requests will not require the PIN to be re-entered until a request with bulk
being set to false
is sent, or the Bulk Sign Reset method is called.
When using bulk signing, great care must be taken to validate that the first signature request was successful prior to sending subsequent requests. Failing to do this will likely result in the card being blocked.
const data = {
algorithm: "sha256",
data: "E1uHACbPvhLew0gGmBH83lvtKIAKxU2/RezfBOsT6Vs=",
pin: "1234"
}
const bulk = true;
beid.sign(data, bulk).then(res => {
}, err => {
console.error(err)
})
The PIN set for bulk signing can be reset by calling this method.
beid.resetBulkPin().then(res => {
}, err => {
console.error(err)
})
Response will look like:
{
"success": true,
"data": true
}
In order to calculate a hash from the data to sign, you need to know the algorithm you will use in order to sign.
This is sample text to demonstrate siging with Belgian eID
You can use the following online tool to calculate the SHA256: calculate SHA256
Hexadecimal result:
135b870026cfbe12dec348069811fcde5bed28800ac54dbf45ecdf04eb13e95b
Notice that the length of the SHA256 is always the same. Now we need to convert the hexadecimal string to a base64-encoded string, another online tool can be used for this example: hex to base64 converter
Base64-encoded result:
E1uHACbPvhLew0gGmBH83lvtKIAKxU2/RezfBOsT6Vs=
Now we can sign the data:
var data = {
"pin":"...",
"algorithm":"sha256",
"data":"E1uHACbPvhLew0gGmBH83lvtKIAKxU2/RezfBOsT6Vs="
}
client.beid(reader_id).signData(data, callback);
Result:
{
"success": true,
"data": {
"data" : "W7wqvWA8m9S...="
}
}
Note: If you want to convert a binary signed hash to HEX (for development) you can use for example an online hexdump tool:
http://www.fileformat.info/tool/hexdump.htm
When the web or native application is responsible for showing the password input, the following request is used to verify a card holder PIN:
var data = {
"pin":"..."
}
client.beid(reader_id).verifyPin(data, callback);
Response:
{
"verified": true
}
When the pin entry is done on the pin-pad, the following request is used to verify a given PIN:
var data = {}
client.beid(reader_id).verifyPin(data, callback);
Response:
{
"verified": true
}
In order to inform a user upon the PIN retries left, the Belgian eID doesn't provide a request to retrieve this information. After an unsuccessful PIN verification, the error code indicates the number of retries left. For example, when executing:
$("#buttonValidate").on('click', function () {
var _body={};
_body.pin = $("#psw").val(); //only when no pin-pad available
var beid = client.beid(reader_id);
beid.verifyPin(_body, validationCallback);
});
Note that, when the user has at least one retry left, entering a correct PIN resets the PIN retry status
.
For more information about the error codes you can check the Error codes page
As the Beid module incorperates Beid 1.7 and 1.8 there is a difference in the algorithms being used. In 1.7 we have the following;
md5
sha1
sha256
sha512
For beid 1.8 we have;
sha2_256
sha2_384
sha2_512
sha3_256
sha3_384
sha3_512
As we've noticed most integrators use sha256
and to make sure current integrations do not break we have made the Trust1Connector to map sha256
to sha3_256
for beid 1.8. Ofcourse if you want to use a specifc supported algorithm you can still select them.
By default the 1.7 will fall back to sha256
and 1.8 to sha3_256
if an incompatible algorithm is passed to the function.
The tables below explain which algorithm will be used when providing a certain algorithm value in the function;
Provided algorithm value
Selected algorithm by T1C
md5
md5
sha1
sha1
sha256
sha256
sha512
sha512
any other value
sha256
Provided algorithm value
Selected algorithm by T1C
sha2_256
sha2_256
sha2_384
sha2_384
sha2_512
sha2_512
sha3_256
sha3_256
sha3_384
sha3_384
sha3_512
sha3_512
sha256
sha3_256
sha384
sha3_384
sha512
sha3_512
any other value
sha3_256
The T1C is able to authenticate a card holder based on a challenge. The challenge can be:
provided by an external service
provided by the smart card An authentication can be interpreted as a signature use case, the challenge is signed data, that can be validated in a back-end process.
External Challenge
An external challenge is provided in the data property of the following example:
var data = {
"pin": "...",
"algorithm": "sha1",
"data":"I2e+u/sgy7fYgh+DWA0p2jzXQ7E="
}
client.beid(reader_id).authenticate(data, callback);
Response:
{
"success": true,
"data": {
"data" : "W7wqvWA8m9S...="
}
}
Take notice that the PIN property can be omitted when using a smart card reader with pin-pad capabilities. The 'algorithm_reference' property can contain the following values: sha1, sha256, sha512, md5.
Generated Challenge
A server generated challenge can be provided to the JavaScript library. In order to do so, an additional contract must be provided with the 'OCV API' (Open Certificate Validation API).
The calculated digest of the hash is prefixed with:
DigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
digest OCTET STRING
}
Make sure this has been taken into consideration in order to validate the signature in a backend process.
Via the Trust1Connector modules you are able to retrieve available algorithms to use for Signing or Authenticate
generic.allAlgoRefs(module, callback);
The response you can expect is a list of algorithms, an example can be found below (the values below are purely examplatory)
{
"success": true,
"data": ["sha1", "sha256"]
}
The Trust1Connector
core services address communication functionality with local devices. The Trust1Connector
core exposes 2 main interfaces:
interface for web/native applications using JavaScrip/Typescript
REST API as a new approach and to incorporate the Trust1Connector
as a microservice in the application architecture
In this guide, we target only the use of Trust1Connector's
core interface for web/native applications.
The T1C-SDK-JS
exposes protected resources for administration and consumer usage.
The JavaScript library must be 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
.
T1CSdk.T1CClient.initialize(config).then(res => {
var coreService = res.core();
core.readers(callback);
}, err => {
console.error(err);
});)
The response will contains a list of card readers:
{
"success": true,
"data": [
{
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false,
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card (eID)"
],
"module": "beid"
}
}
]
}
When multiple readers are attached to a device, the response will show all connected card readers:
{
"data": [
{
"id": "ec3109c84ee9eeb5",
"name": "Identiv uTrust 4701 F Dual Interface Reader(2)",
"pinpad": false
},
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card"
]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
},
{
"id": "c8d31f8fed44d952",
"name": "Identiv uTrust 4701 F Dual Interface Reader(1)",
"pinpad": false
}
],
"success": true
}
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.
{
"data": [
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card"
]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
}
],
"success": true
}
As mentioned in the List card-readers
, when a card-reader has pin-pad capabilities, this will be mentioned in the response (notice the pinpad
property):
{
"data": [
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card"
]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
}
],
"success": true
}
The following example is the response for List card-readers
on a device with 4 different card-readers attached:
{
"data": [
{
"id": "ec3109c84ee9eeb5",
"name": "Identiv uTrust 4701 F Dual Interface Reader(2)",
"pinpad": false
},
{
"card": {
"atr": "3B67000000000000009000",
"description": [
"MisterCash & Proton card",
"VISA Card (emitted by Bank Card Company - Belgium)"
]
},
"id": "e5863fcc71478871",
"name": "Gemalto Ezio Shield Secure Channel",
"pinpad": true
},
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": [
"Belgium Electronic ID card"
]
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
},
{
"id": "c8d31f8fed44d952",
"name": "Identiv uTrust 4701 F Dual Interface Reader(1)",
"pinpad": false
}
],
"success": true
}
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.
T1CClient.initialize(config).then(client => {
var coreService = client.core();
core.readersCardAvailable(callback);
}, err => {
console.error(err);
});
Response:
{
"data": [
{
"card": {
"atr": "3B9813400AA503010101AD1311",
"description": []
},
"id": "57a3e2e71c48cee9",
"name": "Bit4id miniLector",
"pinpad": false
}
],
"success": true
}
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
T1CSdk.T1CClient.initialize(config).then(client => {
var coreService = client.core();
core.version().then(version => {
console.log(version)
});
}, err => {
console.error(err);
});
The ouput in the log of the code above should look like the following
3.5.3
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.
export interface AbstractCore {
getImplicitConsent(codeWord: string, durationInDays?: number, callback?: (error?: T1CLibException, data?: T1CClient) => void): Promise<T1CClient>;
validateConsent(consent: string, callback?: (error?: T1CLibException, data?: T1CClient) => void): Promise<T1CClient>;
updateJWT(jwt: string, callback?: (error: T1CLibException, data?: T1CClient) => void): Promise<T1CClient>
info(callback?: (error: T1CLibException, data: InfoResponse) => void): void | Promise<InfoResponse>;
reader(reader_id: string, callback?: (error: T1CLibException, data: SingleReaderResponse) => void): Promise<SingleReaderResponse>;
readers(callback?: (error: T1CLibException, data: CardReadersResponse) => void): Promise<CardReadersResponse>;
readersCardAvailable(callback?: (error: T1CLibException, data: CardReadersResponse) => void): Promise<CardReadersResponse>;
readersCardsUnavailable(callback?: (error: T1CLibException, data: CardReadersResponse) => void): Promise<CardReadersResponse>;
getUrl(): string;
getDevicePublicKey(): void;
dsCorsSync(): Promise<boolean>;
pushLogs(): Promise<boolean>;
version(): Promise<string>;
}