Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Shows an overview of all information retrieved from a selected smart card or token
Starting form the readers page, when a token has been detected and recognized, a 'select' button can be used to start dumping all known information of the selected token:
The first section of the 'Card Details Page' shows a visual representation of the card, this contains the 'biometric' information from a card. Note that this information can be retrieved when:
the smart card or token has a custom application exposing this information
the smart card or token has basic user information in the certificates present on the tokenC
The visual representation can vary depending on the selected token type (each card type is called a 'module' in the Trust1Connector context.
When a specific visual representation is not available for a given/selected token, the default visualization schema will be applied.
Trust1Team can add new token visualizations to the connector's extension framework.
The second part contains specific data for the selected token, and can vary depending on the schema used. In the given example, the address is not available in the card certificates, but is read out of the Belgian eID application directly. As this is feature which is not supported by all tokens, it is possible that the address is not visualized.
The next section displays all available certificates from the token
The certificate details perform a Certification Validation process. This is done using the Trust1Connector Validation Service, which is service hosted by Trust1Team.
The service is performing all validation needed and returns a 'color-code' accompanied by a short descriptive on the reponse obtained by the valdiation service.
The example, using the test card, shows a warning (as this is a test card):
When selecting the option 'Show Details', a short summary of the validation feedback can be obtianed:
When performing the same flow with a valid card, the result is the following:
The retuned certificates are in base64 binary format. Future releases of the ReadMyCards will parse the obtained certificate and show the resulting certificate properties in a readable format.
The following ceritificate types are used by the connector:
Some tokens can have multiple certificates of the same type. Those are returned form the Trust1Connector and can be used in the application context. In the ReadMyCards application, only one will be displayed.
| Certificate Type | Description |
|---|---|
NON REPUDIATION CERTIFICATE
The certificate which is used to perform a digital signature
AUTHENTICATION CERTIFICATE
The certificate which is used to perform an authentication
ENCRYPTION CERTIFICATE
The certificate used for encpryption/decryption of payloads
ISSUER CERTIFICATE
The certificate used for validation of the read card data
INTERMEDIATE CERTIFICATE
The intermediate certificate of the issuer
ROOT CERTIFICATE
The root certificate of the issuer
Trust1Connector Web Application and Diagnostics
The ReadMyCards web application acts as an example implementation of the Trust1Connector. The application facilitates the following use cases:
Visualizing available smart card readers and physical tokens
Retrieving certificates, certificate chains
Visualizing smart cards and phyisical token personalisation information
User authentication
Digitally sign a PDF document
Print content to available printers
Local file mapping for file upload, download and synchronization
The ReadMyCards is available on: https://rmc.t1t.io/
This document describes the available functionalities for ReadMyCards and how this can be valuable of partners or end-consumers.
Main Navigation and Application Settings
The left menu depicts the ReadMyCards capabilities:
| Menu | Description |
|---|
The ReadMyCards application is customised depending on the hosting URL. This is when a specific ReadMyCards instance has been provided in a partner context using its own domain name. The menu can have limited possibilities depending on the hosting context.
On the right top, the settings menu is depicted as a 'cog-wheel'. When clicked the following options are available:
The ReadMyCards application is following a seperate semantic versioning policy when compared to the Trust1Connector. The application version is depicted on the top-left underneath the logo:
The user "has" a token and "knows" a PIN for the application of a digital signature using a PDF document
For more in-depth details on the technical flow for PIN validation, check out:
A user can digitally sign a document using ReadMyCards
At the bottom of the page, there are 3 use cases available:
authenticate user with browser OR operating system pin dialo
upload a PDF document as a prerequisite to the process of performing a digital signature
digitally sign a PDF document
The Trust1Connector ask the user for a PIN when performing an authentication or a digital signature. When a user enters the PIN in a browser dialog, the Trust1Connector has the necessary functions in the SDK to encrypt the PIN sent from the browser towards the Trust1Connector instance. The reasoning behind this approach is:
the Trust1Connector does NOT rust a local browser: the browser can be corrupted with a 'dirty' plugin for example; no pin code will be visible in the 'debug console' of the browser
applications are not trusted, except when presenting a valid token, and when performing a key exchang prior to the use of the connector
When enabling the toggle 'Use operating system pin dialog', you ask to ignore entering the PIN in the browser by delegating the PIN entry to the operating system. When this option has been enabled, the Trust1Connector will ask the underlying operating system to deal with the PIN entry. This means that the PIN entry is COMPLETELY separated from the web application or browser.
This topic has different motiviations depending on the use case and security policies applied in an organizatoion. The Trust1Connector want to guarantee a safe implementation for both use cases mentioned
When the use case completes succesfully, in the top right, the following message will appear for a short amount of time:
The ReadMyCard application allows a user to sign a PDF document using baseline PAdES-LTV Profile (Long Term). It’s the long-lived signature format. This profile allows you to extend the validity of signatures in PDF format indefinitely. It can be used in conjunction with other PAdEs profiles. This profile is used to ensure validation many years after the completion of the signature. That is, it guarantees long-term validation.
Start uploading a PDF document, this can be done by selecting the 'file-drop'-zone or drag-and-drop a file to the 'file-drop'-zone.
Once a file has been uploaded, the filename will appear in the drop-zone.
Start the signature flow using the 'Sign uploaded document':
When the flow completes succesfully, the following pop-up will be shown:
From the pop-up you can:
download the signed PDF document (using the download link)
close the pop-up and go back to previous screen
Opening the document in Adobe Acrobat Reader, will demonstrate the application of the digital signature
Opening the signature details, the signature properties can be verified:
There are no guarantees for the documented properites using the ReadMyCards application. As the application can be altered for demo purpose, some details can or may change over time
| Setting | Description |
|---|
Mode | Toggle for light or dark mode. The option for system alignment is available |
Language | The application support the listed languages. Additional languages can be added on demand |
Connection Settings | The URL and port which is used from the targetted connector. This option is especially important when targetting an other connector instance. Multiple connectors can be installed on a single device, this option can target for example development, acceptance or production variants |
Readers | List all readers and interact with smart cards or physical tokens |
Admin | Administration page showing device information, user information and status information for dependencies |
File Explorer | Example implementation of the file explorer module. Allows for abstract mapping of folders in the web application, independant of the underlying operating system |
Contact | A contact page to connect with Trust1Team for improvements and product related questions |
OS Independant and Secure File Management for Web Applications
The File Exchange container allows Trust1Connector to manage files and directories, to upload or download files to/from the filesystem from/to the requesting party (especially for web application). The user of the device must give a consent prior of file operations.
The File Explorer exposes a controlled and secured abstraction for file operations.
The File Exchange container provides the following functionalities:
selecting a folder based on application type
listing files in selected application type
downloading one or more files into selected application type
uploading one or more files from the selected application type
creating sub directories in 'mapped' folders (application types)
The Trust1Connector does NOT allow the deletion of folders or files residing on the user's device.
An application type resolves locally to an absolute file system path.
An application can create additional folders for a given application type, those folders are relative to the absolute path which has been locally mapped on the application type. This means that the web application can ask the user to create subdirectories in an application type which has been already mapped.
The File Exchange container provides additionally:
optional user notification for file transfer completion
copy and move files between application types
user consent to allow the consuming application to perform file operations
application/domain scoped, application types are bound to the application domain
OS native files and directory chooser dialogs
Detailed developers documentation can be found in the technical documentation:
The user "has" a token and "knows" a PIN code
For more in-depth details on the technical flow for PIN validation, check out:
A user authentication can be executed from the ReadMyCards application.
At the bottom of the page, there are 3 use cases available:
authenticate user with browser OR operating system pin dialog
upload a PDF document as a prerequisite to the process of performing a digital signature
digitally sign a PDF document
The Trust1Connector ask the user for a PIN when performing an authentication or a digital signature. When a user enters the PIN in a browser dialog, the Trust1Connector has the necessary functions in the SDK to encrypt the PIN sent from the browser towards the Trust1Connector instance. The reasoning behind this approach is:
the Trust1Connector does NOT trust a local browser: the browser can be corrupted with a 'dirty' plugin for example; no pin code will be visible in the 'debug console' of the browser
applications are not trusted, except when presenting a valid token, and when performing a key exchang prior to the use of the connector
When enabling the toggle 'Use operating system pin dialog', you ask to ignore entering the PIN in the browser by delegating the PIN entry to the operating system. When this option has been enabled, the Trust1Connector will ask the underlying operating system to deal with the PIN entry. This means that the PIN entry is COMPLETELY separated from the web application or browser.
This topic has different motiviations depending on the use case and security policies applied in an organizatoion. The Trust1Connector want to guarantee a safe implementation for both use cases mentioned
When the use case completes succesfully, in the top right, the following message will appear for a short amount of time:
Overall Application Structure
Initially when starting the application, and no Trust1Connector has been installed the following layout will be presented:
The Home Page allows the user to download the Trust1Connector or view which version is currently installed. Although the connector can determine which operating system is running the browser, the page shows all possible downloads. Available installers are provided for:
Windows 32/64 bit (LTS)
Mac Intel/ARM (LTS)
Linux (Ubuntu/Debian or other upon request)
After the downloaded, the signed package can be installed on your system. The connector has been build to have a small footprint. After a succesfull installation, the page must be refreshed. The application has been build to avoid explicit polling of readers prior to the installation.
The installation wizard will be started when the downloaded installer is executed:
After a succesfull installation, and when the page is refreshed, a consent will be asked from the user. The consent is needed to allow access to card readers on the user's device.
When allowing the consent, the previous page will disappear and a new page will be loaded, searching for available card readers. The following screen shows the result, when no card readers are present:
The administration page provided general information available from the connector.
The Readers-menu provides an overview of all detected system tokens
When one or more readers are connected to the device, the application will display an overview with basic card reader or physical token information.
The table informs about the following reader semantics:
| Column | Semantics |
|---|---|
The card ATR (ref: https://en.wikipedia.org/wiki/Answer_to_reset - Answer-To-Reset) is used to determine the smart card schema which can be used with the Trust1Connector.
When a card is unknown to the connector, a module can be proposed. This will trigger an override for the selected token. The connector will load the correct module to parse the card information and execute the use cases using the selected module.
There are no guarantees on a correct execution when 'module-override' has been altered. This is used most of the time to verify if an ATR can be forceably read and only when the user has kowledge on how smart cards and physical tokens are technically working.
File Explorer Functionalities
Selecting the 'File Explorer' menu show the following applciation screen:
The File Explorer contextualizes folder mapping based on the connected application (done virtually using an application identifier).
Each application can have one or more 'Entities'. The example entity used in this application is called 'RMC'. You can have more application Entities defined using the Trust1Connector. For the example applciation, one has been predefined.
Within an Entity, one or more folder-mappings can be defined, this is called a 'Type' mapping. Basically it means you create a virtual name, and link it to an existing folder on your local device.
Select the button 'create type and assign location':
After defining the name, a file-chooser will pop-up from the Trust1Connector, now you can create and select a folder. The folder will be linked to the 'type', which means all files in the folder will become available for the web application. In order to do so, a user consent is needed:
The result of the file creation and mapping is show in the main application overview:
| Property | Description |
|---|---|
| Property | Description |
|---|---|
| Indicator | Description |
|---|---|
Reader name
Displays the system reader name, and the reader technical id (the reader-id used when interacting programmatically)
Modules
Lists all the modules available. A module is selected automatically when a card is detected and recognized. For more information on module selection and override, read:#card-atr
Proposed Modules
The module proposed by the Trust1Connector. When a card is recognized, the proposed schema for card interaction is selected by setting the inferred module. The proposed module has an identifier which can be used as module selector during integration and an optional description upon recognition
PinPad
Shows when the card reader has a pinpad, inferred by the Trust1Connector. Unrecognized readers can be added to the connector if needed
Card Inserted
Determines when a smart card or token has been found for the reader. This can be a smart card in a reader device, or a token including an embedded secured element
Actions
Actions allowed on the selected reader. When selected, a full dump of a token will be started with the targetted connector
API version
Trust1Connector API version. The connector has an local API running in the background on a random assigned port (or fixed depending on the configuration). The API version is retrieved and displayed for debuging purpose
Javascrip version
Trust1Connector SDK Javascrip version used in the web application. The SDK communications with the former mentioned connector API. The version is displayed mainly for debuging purpose
Status
Trust1Connector Status displays ACTIVATED when initialized correctly and optionally established connection and registration with a central Distribution Server ( https://t1t.gitbook.io/t1c-distribution-service-v3-guide/ )
Log Level
Log level configured in the connector. The following options can be displayed: INFO, DEBUG, WARN, ERROR
Operating System
The inferred operating system (Windows, Mac or Linux)
Version
Operating System Version
Device ID
The unique device ID of the device where the connector is installed. The ID is unique and remains the same after upgrade, install, reinstall, even after a complete deletion of the connector middleware
Name
Logged-in user name
Username
System username
Home Directory
The home directory of the user running the connector instance
Trust1Connector API
Check the connection to the running connector (see #application-settings)
Validation Service
The service used to validate certificate chains, EUTL, LOTL, certificate revocation etc.
Distribution Service
Check the connectivity with to the distribution server targetted by the installed connector. The connector is packaged with a preconfigured distribution URL (can be overriden through configuration)
For an existing 'Type' (see ), you can create a new folder within the root directory:
A file can be uploaded to the web application from the local device.
When copying files to the linked folder (linked to the 'type' definition), the files will also appear/be accissable in/for the web applciation. Remember the web application can access all data from the root folder recursively.
After selecting and confirming the file upload, the file will be show in the application overview
With a file selected, additional options are available:
download file
print file
rename file
move file
copy file
The meaning of 'Download File' is from the perspective of the local device - aka - the local device downloads a file form the web application (upload and download MUST be seen from the perspective of the local device).
When donwloading a a file, the user can perform this off course in any system folder.
The Trust1Connector has a printer module enabled, which means that a printer (available on the operating system) can be selected and triggered for a print job.
Rename a file from the web application as would be the case using the local operating system.
Move a file from the web application as would be the case using the local operating system, but with the additional restriction that this can only be done between accessible folders, or within the same folder. Moving files to unaccessible folders are not allowed and will be prevented from the Trust1Connector.
Copy a file from the web application as would be the case using the local operating system, but with the additional restriction that this can only be done between accessible folders, or within the same folder. Copying files to unaccessible folders are not allowed and will be prevented from the Trust1Connector.
| Nr | Function | Description |
|---|
1 | Type - linked to local (root)-folder | Folder acting as an isolated file space for the web application |
2 | Upload File | Upload a file from your web application to the local file system |
3 | Create Folder | Create new folder within the selected 'Type' |
4 | Create Type | Add another/new Type mapping |
5 | Delete Type |
Deletes only the virtual mapping, NOT the real data from the local device
