|
Quali-Sign | In cooperation with |
|
| Specialists in mobile apps for eID and Strong Customer Authentication | |||
Resources > Demonstration & Evaluation
| Perform SCA on an E-Mandate | |
|---|---|
| A merchant requests their customer sign an electronic mandate, allowing the merchant to collect/pull payments (Merchant Initiated Transactions - MIT) from the customer's bank account. | |
| This allows the customer to use their merchant issued (physical or virtual) loyalty card to pay with a tap & go at the checkout. | |
| Evaluation Requests | |
|---|---|
| ◆ | If you would like to evaluate our app, we can provide you with a profile on our demonstration server. |
| ◆ | Please contact us for more details. |
| The following flavours of the app are available: | |
| Android: | Available on Google Play. |
| iOS: | Available in the App Store. |
| Visit Our Demo Site | |
|---|---|
| Once you have QS-DIW set up on your smartphone, visit here to try some of these demos. | |
| You can email yourself the SCA proof. Here are some useful links: | |
| ◆ | Verify the SCA proof. Under 'More Options', please select following Validation level: 'Validation process for Basic Signatures'. |
| ◆ | Pretty Print the XML Advanced Electronic Signatures (XAdES). |
| ◆ | View the contents of an X.509 Certificate. |
| ◆ | Decode the Base64 encoded data |
| Person-to-Person Payment | |
|---|---|
| A payment between two digital identity wallets. The payee prepares a Request-to-Pay and signs the request (performing Strong Customer/User Authentication). A proximity connection is established between both wallets and mutual authentication is performed before any payment data is exchanged. The payer authorises the payment and the payee wallet responds with a receipt. | |
| This scenario is especially relevant for CBDC where the settlement and finality will occur on completion of the (offline) procedure between the two wallets. The payee is then able to respend the funds received before going back online. | |
| Offline Payment incl. Attributes | |
|---|---|
| An payment between a merchant terminal and Digital Identity Wallet, both of which are offline. When authorising the payment, the payer is asked to present attribute attestation. | |
| Two Offline Payments | |
|---|---|
| Two people exchange payments between their smartphone Wallet apps. The procedure involves the payee preparing a 'Request To Pay'. The payer then selects the debtor account and provides their approval. The payee wallet then provides a receipt to the payer wallet. The SCA proof is represented by a chain of three electronic signatures. | |
| The smartphones communicate via a proximity connection (BLE). An internet connection is not required to complete the procedure. Even while offline, both wallets fully verify the signatures of the counterparty. All certificates are verified up to a trusted root certificate, which is sourced independently by each wallet and stored locally for offline use. | |
| The recording finishes with the SCA proof being exported from one of the wallets. This is in an Associated Signature Container (ASiC) ZIP structure. The ASiC is uploaded to the EU DSS Verify a Signature site for verification. The EU DSS successfully verifies the signature, however it does not recognise the root certificates, which were created for demo purposes. | |
| Online Payment at the Point of Interaction (POI) | |
|---|---|
| This demo simulates a person completing an online purchase at a merchant website. At the online checkout, the user scans a QR code with their Digital Identity Wallet (DIW) app. | |
| The DIW app estabishes an end-to-end encrypted session with the merchant website and downloads a 'Request-to-Pay', signed with the merchant's QSEAL. The DIW authenticates the merchant by verifying the merchant signature/QSEAL and then presents the payment request to the user. The user selects the debtor account and then authorises the payment (performs SCA). The user's SCA proof is transmitted to the merchant who verifies the user signature. The procedure is completed by the merchant responding with a receipt, again signed with the merchant's QSEAL | |
| Perform Customer Due Diligence offline | |
|---|---|
| A person is asked to present their core identity attributes by a Relying Party who is required to perfom Customer Due Diligence (CDD) checks, e.g. for Anti-Money Laundering (AML) and Countering the Financing of Terrorism (CFT) purposes. | |
| In this demo, both the DIW app and the Relying Party terminal are offline. The devices communicate via a proximity connection (BLE). | |
| The Relying Party app first prepares a signed request, which lists the attributes that it requires to perform CDD. The signed request is transmitted to the DIW which verifies the signature in order to authenticates the Relying Party. The DIW then presents the request to the person for their approval, listing the attributes that are required. The person touches the fingerprint sensor to countersign and their CDD attributes are included in the countersignature. The Relying Party app then verifies the person's countersignature and checks their CDD attributes. | |
| Open a bank account | |
|---|---|
| This recording was commissioned by the eIDAS enabled i-Banking project. The project has received funding from the European Union's Innovation and Networks Execuitve Agency (INIA), under Grant Agreement No INEA/CEF/ICT/A2018/1633440. | |
| A person who holds an Electronic Identification (eID) wallet app opens a new bank account online with NewBank. | |
| Before the account can be opened, the person must sign the Terms & Conditions and NewBank must also perform Customer Due Diligence (CDD) on the customer. | |
| The person launches their eID app and scans a QR code displayed on NewBank's web site. | |
| The eID app asks the person to sign the T's & C's and lists the attributes that are required. They sign with a touch of the fingerprint sensor. | |
| The signed (eID) proof includes the person's Identity Certificate and an Attribute Certificate for each attribute that is required. | |
| Links to copies of the eID proof and the EU DSS Validation Report. | |
| Present eHealth Travelpass (Covid status) offline | |
|---|---|
| A person is asked to present their Covid-19 status using their Digital Identity Wallet (DIW). In this demo, both the DIW app and the Relying Party terminal are offline. The devices communicate via a proximity connection (BLE). | |
| The Relying Party app first transmits a signed request, which the DIW verifies and then presents to the person for approval. The person touches the fingerprint sensor to countersign and their Covid-19 status attribute attestation (X.509 certificate) is included in the countersignature. The Relying Party app then verifies the person's countersignature and checks their covid status attribute. | |
| In this procedure, no personal data is shared with the Relying Party. The Relying Party insteads trusts the issuers of the person's digital identity and attributes to provide confirmation that the person touching the fingerprint sensor is deemed to have a green pass. | |
| Perform eID at a turnstile to access a sports stadium | |
|---|---|
| In order to access the stand at a football stadium, a person must present their match ticket, their Covid-19 certification status and also their ID. | |
| At the turnstile the ticket holder scans a QR code with their eID wallet app. They then touch the fingerprint sensor to present their ticket and their covid status (Green/Red) at the same time (in the form of attributes). The whole procedure takes 14 seconds. | |
| In this demo the person's smartphone is offline. It communicates with the turnstile via a proximity connection (BLE). The procedure can also work with both the smartphone and the turnstile offline. The eID wallet app is still able to authenticate the turnstile/stadium (Relying Party) and the turnstile is still able to verify the eID proof (including ticket and covid attributes). | |
| NulaBG - Login and approve payments | |
|---|---|
| NulaBG is a Payment Initiation Service Provider (PISP). They are the first to implement the Embedded SCA APIs proposed in the Berlin Group 'Signed Payment Request' (AdES flavour) Change Request(CR). This CR proposes extensions to the NextGenPSD2 Open Banking Standard. | |
| In this demo, the PSU logs into the NulaBG site using their Dedicated Authentication/EUeID App. | |
| The PSU then proceeds to approve a tax payment. | |
| Embedded SCA - Merchant Point of Sale (POS) | |
|---|---|
| At the checkount in a shop, the customer pays using their bank issued Dedicated Authentication App (DA-App). | |
| The DA-App is on the left and the Merchant POS is on the right. | |
| The user scans the QR code, reviews the payee and amount, selects an account to debit and then signs. The end-to-end procedure takes 20 seconds. | |
| Their smartphone does not have a network connection. It connects with the POS terminal using proximity technologies (QR codes and BLE). | |
| Watch carefuly and you will see the BLE communication progress on both devices. | |
| Embedded SCA - Initiate payments via a 3rd party website. | |
|---|---|
| A user visits the website of a Third Party Provider (TPP). They log in by scanning a QR code displayed on the TPP website with a Dedicated Authentication App, provided by their bank. | |
| Having logged in, the user proceeds to initiate a variety of payments (single, bulk and recurring) and also consents to the TPP accessing their account data. | |
| The user signs each payment/consent request via their Dedicated Authentication App. | |
| The TPP then initiates the signed payment/consent requests via PSD2 APIs. No further authorisation is required. | |
| eID - Website Login | |
|---|---|
| A user visits the website of a Third Party Provider (TPP). The website gives the user the option of logging in using an eID app previously issued to the user by an Identity Service Provider (e.g. a bank). The TPP performs the role of Identity Consumer. | |
| The TPP website displays a QR code for the user to scan with their eID app. The content of the QR code includes an identifier of the browser session and the URL of the TPP server. | |
| When the user scans the QR code, a secure end-to-end encrypted connection is established between the eID app and server of the TPP. | |
| The TPP then prepares an Authentication Request, this takes the form of an Advanced Electronic Signature (AdES) and contains the TPP's QSEAL (machine signature) and corresponding certificate chain. | |
| The eID app first identifies and authenticates the TPP by verifying the QSEAL. | |
| The eID app then presents the user with the authentication request and asks them to approve it by touching the biometric sensor on their smartphone. | |
| The Authentication Proof extends the TPP's AdES by adding the user's countersignature. This countersignature includes the user's certificate chain. | |
| The countersignature is transmitted back to the TPP via the secure connection. The TPP can then identify and authenticate the user by verifying the signature either themselves or via a verification service. | |
| Decoupled SCA - Corporate - Multi-User Approval (3 minutes) | |
|---|---|
| A corporate ERP/Treasury platform prepares: a) a bulk file of credit transfers, b) a file direct debits, c) an account opening request and d) an e-mandate proposal. | |
| All files (orders) are transmitted to the bank via an SFTP host-to-host connection. On receipt, the bank places the orders into its Decoupled SCA procedure. All require dual approval. | |
| Two authorised representatives of the corporate are notified by their bank issued Dedicated Authentication App (installed on their phones) that they have new orders to approve. | |
| They are able to review the details of each order before approving or cancelling it. | |
| In the recording below, one user's iPhone is on the left, the other user's Android smartphone is on the right. The SFTP upload tool is in the middle. In the browser below is the IBM Sterling File Gateway (SFG) status reporting tool. SFG manages the Decoupled procedure. | |
| Decoupled SCA - Corporate Bulk Payments - Multi-User Approval (1.5 minutes) | |
|---|---|
| A corporate ERP/Treasury platform prepares a bulk file of 1000 SCT transactions. | |
| The bulk payments file is transmitted to the bank via an SFTP host-to-host connection. On receipt, the bank places the payment order into its Decoupled SCA procedure. This payment order requires dual approval. | |
| Two authorised representatives of the corporate are notified by their bank issued Dedicated Authentication App (installed on their phones) that they have a new order to approve. | |
| They are able to review payment details before approving the payment order. | |
| Once dual approval is completed, the status of the payment order changes to RCVD (received). The bank then releases it for further processing. | |
| In the recording below, one user's iPhone is on the left, the other user's Android smartphone is on the right. The SFTP upload tool is in the middle. In the browser below is the IBM Sterling File Gateway (SFG) status reporting tool. SFG manages the Decoupled procedure. | |
| Bill Payment via QR Scan | |
|---|---|
| A paper invoice is received containing a QR code (EPC SCT format). | |
| To pay the invoice, the user scans the QR code with their bank issued app. | |
| An SCT payment request is generated and transmitted to the bank. | |
| The payment request is verified a bank's ISO20022 test platform. | |