Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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:
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:
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.
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
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:
The Readers-menu provides an overview of all detected system tokens
The Trust1Connector provides a way for user's to test out a PKCS11 library.
Using the ReadMyCards application you can load your configuration.
On the admin page you will be able to update the path towards a PKCS11 library.
Here you must set this to the path where the Pkcs11 library is located on your system. Then click update
Then we go to the readers tab and use the pkcs11 module as an override
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:
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.
T1C-2606 When T1C version (mac, win or other) is not available in RMC, manage a user friendly expection
T1C-2391 As a User I would like to be able to remove my consent
T1C-2401 As a User I want to see all supported PKI modules
T1C-2402 As a User I want to use a specific Token module
T1C-2404 As a User I want to use a specific PKI module
T1C-2506 As a User I would like to have a specific visualisation for EMV cards
T1C-2509 As a User I would like to have a specific visualisation for Luxembourg ID cards
T1C-2832 Add Truststore menu and activate this menu as default for version >3.8
T1C-2835 As a user I want to see all non-rep and auth certificates available in my Truststore
T1C-2841 As a user I want to see a parsed version of my certificates
T1C-2848 Visualize CORS list from API in RMC (2nd level)
T1C-2861 As a user I want to see the contents of my cors list
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
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:
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
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.
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
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.
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:
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:
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
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:
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
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:
Readers
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:
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
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.
Next up click Select for the reader and it will use the define PKCS11 library to try and read the card information
user information
dependency status
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 ( )
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)
Name
Logged-in user name
Username
System username
Home Directory
The home directory of the user running the connector instance
Check the depending services used by the application
Trust1Connector API
Check the connection to the running connector (see )
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)
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:
ROOT CERTIFICATE
The root certificate of the issuer
❗Deletes only the virtual mapping, NOT the real data from the local device
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
