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
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:
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
ROOT CERTIFICATE
The root 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.
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
Next up click Select for the reader and it will use the define PKCS11 library to try and read the card information
