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...
Check correct versions for backwards compatibility
Pin Obfuscation not working for all modules
base64 encode the PIN before sending it to the API
Pin Obfuscation not working for all modules
base64 encode the PIN before sending it to the API
I want to enable module for Certinomis
Migrate certigna integration with the latest token
Return interface to previous state to prevent breaking applications
Pkcs11 module and os dialog return decryption error
Update certificate model to correctly handle multiple certificates
Device-key endpoint gets called in error handler instead of successhandler
File-exchange ArrayBuffer should be Blob
Initialising with invalid JWT does not throw an error
Entity and type response object inconsistency
Remoteloading split TX, RX and SW value based on APDU response
Use Device certificate to encrypt the pin value sent in clear text
I want to enable the module for eHerkenning
I want to enable module for Print Writer
Aventra, Idemia, Oberthur callback functions not being triggered
FileExchange typing inconsistency
Add LuxeID to the token generic interface in JS SDK
Fix imports for Pkijs
Disbable implicit any typing
Fix for bulk sign reset in JS SDK causes the reader ID not to be included in certificate retrieval
Provide separate implementation for Belgian eID with Crelan reader
A Web Application interacts with the Trust1Connector on standalone devices or within a shared environment. The Web Application is not aware, but must take this into consideration upon integration.
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.
Integrating the Trust1Connector can be done via the Javascript SDK. This SDK is compiled in regular javascript and in Typescript. Each release of the Javascript SDK will have the following files;
dist
T1CSdk.js (complete SDK)
T1CSdk.js.map
lib (typings, default Typescript compilation)
lib-esm (typings, Compilation with ES6 module support)
In V3 of the Trust1Connector the javascript SDK is meant as a comparable manner of integrating like the V2. The SDK includes most of the API featureset but not all.
We strongly encourage to integrate via the API, since this will be the most feature-complete and the de-facto way of integration in the future.
All examples below will be shown in regular Javascript. All Javascript for changing UI will not be present but are purely displayed as part of the example.
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.
Next up 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, ...
When the configuration is set you can initialise the Trust1Connector with that Config and an optional property for clipboardData. This clipboard data is used for initialisation of the Trust1Connector in a shared environment. This will be handled later.
You can see in the code above we catch 3 errors;
814501: Consent error, this means the user is running in a shared environment and needs to provide his consent
812020: Initialisation error: The Trust1Connector is not able to initialise because it could not find any users with a Trust1Connector installed.
112999: T1C exception, this will be thrown when the T1C is not available, where you can display an URL where the user can download the T1C
To retrieve the reader after initialisation you can do the following;
After initialisation of the T1C you can start using it. For example the BEID module needs to be initialised with a readerId, That is why fetching the readers and providing the user-selected reader to the client is a necessity.
The code above will return a BEID client which can be used to execute the BEID functionality.
Initialisation of the Trust1Connector for shared environments is similar to the regular initialisation with the difference being a required consent. More information can be found in the Consent page.
For initialising the Trust1Connector in a shared environment you need to setup the config so that it contacts the Proxy. When initialising you need to provide a token that is residing on the user's clipboard, via this clipboard token the Proxy can determine which which user is trying to communicate and will return an updated configuration value for the API and the sandbox service.
This configuration update is handled by the SDK itself.
The code above is an example of how you can integrate a copy command in the webbrowser
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.
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
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 with a correct token in order to access the all resource. The security policy for Trust1Connector
v3 secured ALL endpoints.
Protected resources are administration resources. The JavaScript library must be initialized with a correct token in order to access the resource.
Download Trust1Connector
installer
Get Information of the device and user context
Register T1C for device
Update T1C on device (install new version)
Update DS (distribution server) metadata
Increment use case counter
Executing these functionality is explained further.
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
List modules
Get module
Get card-reader
Get card-reader with cards inserted
Get card-readers without card
Get consent (needed for shared environments)
Detect card for card-reader (polling utility resource)
Detect any card (polling utility resource)
Detect card-readers (polling utility resource)
Browser Information (utility resource)
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, ...
The client can be initialized by passing a T1CConfig
object in the constructor
Returns a list of available card readers. Multiple readers can be connected. Each reader is identified by a unique reader_id
.
The response will contains a list of card readers:
When multiple readers are attached to a device, the response will show all connected card readers:
Important to notice:
The response adds a card
-element when a card is inserted into the card reader.
The response contains card-reader pin-pad
capabilities
As mentioned in the List card-readers
, when a smart-card is inserted/detected, the reader will contain the cart-type based on the ATR. The ATR (Anwser To Reset), is the response from any smart-card when powered, and defines the card type.
The Trust1Connector
recognized more than 3k smart-card types.
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):
The following example is the response for List card-readers
on a device with 4 different card-readers attached:
In the above example you notice that 4 card-readers are connected. Each card-reader receives his temporary id
which can be used for other functions where a card-reader id is needed.
This method can be requested in order to list all available card-readers, and optional cards-inserted.
Each card-reader has a vendor provided name, which is retrieved from the card-reader itself.
An additional property pinpad
, a boolean
value, denotes if the card-reader has pin-pad capabilities. A pin-pad is a card-reader, most of the times with its own display and key-pad.
From a security perspective, it's considered best practice to use as much as possible pin-pad capabilities of a pin-pad card-reader.
When a reader has a smart-card inserted (contact interface) or detected (contactless interface), the card type will be resolved by the GCL in order to respond with a meaningful type.
In the above examples you see that; one card-reader has a Belgian eID card; another card-reader has a MisterCash
or VISA Card
available for interaction.
The readers returned, are the card-readers with a card available. The card-readers where no card is presented, are ignored.
Returns a list of available card readers with a smart card inserted. Multiple readers can be connected with multiple smart cards inserted. Each reader is identified by a unique reader_id
and contains information about a connected smart card. A smart card is of a certain type. The Trust1Connector
detects the type of the smart card and returns this information in the JSON response.
Response:
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.