Verifiable Credentials Pattern
The Verifiable Credentials Pattern (VC Pattern) is one of the cross-border interaction patterns of the DE4A Reference Architecture. It is a user-managed access pattern in D2.1 terminology (cf. D2.1 Architecture Framework). It is used by the following use case: Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3).
Data stored in the form of Verifiable Credentials (VC) are data representations in the form of a set of claims about some subject (i.e. User) issued by the issuer (i.e. Data Provider). Verifiable Credentials can be cryptographically verified by any third party i.e. Data Consumer (DC) to whom Verifiable Credentials is presented (usually in the form of a Verifiable Presentation (VP)).
The VC Pattern utilizes blockchain technology features in several ways. First, storing decentralized identifiers (DIDs) and its correlating DID documents, which includes all relevant entity pieces of information about the issuer, including associated cryptographic keys, endpoints, etc. that can be used to authenticate the issuer (i.e. Data Provider (DP), and cryptographically validate VC that was issued by its DID. Second, storing and maintaining a list of verified/trusted issuers, i.e. DPs. Third, keep the list of revoked VCs. Furthermore, all other entities (i.e. DC, and Users) also have DIDs, and related DID documents, that are different than the DC information stored directly on their devices, i.e. Agents (edge or cloud). These DIDs are used for setting direct, i.e. DID communication between entities.
The VCs are issued to a User in a cryptographically secure manner collected in a user-maintained digital wallet that is part of the edge agent (i.e. mobile phone) in their possession. An Edge agent serves as an instrument with which all secure interchanges are managed (i.e. Initiate DID connection, Accept DID connection, Accept Verifiable Credential, Present Verifiable Credential). Moreover, the managing of DID connections, VC issuing and verifying operated by DPs and DCs is handled through a dedicated cloud agent.
A mock-up of the user journey was created using Wireframes (see Wireframe Mock-up).
Working hypotheses and implementation principles
The present reference architecture is valid under several working hypotheses and implementation principles, which are working hypotheses that are either validated or decided upon by the members of DE4A.
| Interdisciplinary Topic | Hypotheses / Principle | Implications and Limitations |
| Orchestration / Choreography | The orchestration of the evidence exchange is performed by the User, who is supported in identifying the right DP to communicate with. | The VC pattern is a version of a User-managed access pattern as identified in D2.1 Architecture Framework. |
| Complementary, overlapping or conflicting evidence equivalents | Complementary evidence cases must in principle be supported by the technical system. Deep analysis on whether they are jointly valid or are contradicting each other is left to the public service provider and not included as functionality in the cross-border OOP sequence. | The DE4A pilot case applying this pattern does not to suffer from this issue and the common VC schema approach also means that this issue is usually resolved at the DP-side. |
| Interrupted vs. Uninterrupted exchange | The VC pattern can support interrupted procedures and deferred responses based on established DID connection and the user agent as uncoupling point. | The “save and resume” functionality of the eProcedure portal of the DC is required for the VC pattern to function. |
| Explicit request and transitivity between actors | The VC pattern does not include an explicit request for evidence transfer as it is a User-manages Access pattern. | The user requests the use of verifiable credentials. Requesting the VC from the DP can be considered an implicit user request. |
| Preview & Approval UI | The user agent provides the preview between getting the Verifiable Credential (VC) issued by the DP and providing the Verifiable Presentation (VP) to the DC. | We are not considering the exchange without user request and approval (i.e. based on national or Union law) in the VC pattern. |
| Identity and Record Matching | The assumption can be relaxed in comparison to the Intermediation pattern: The user has direct interaction with both the DC and the DP and can easily assist with additional information. | In case of a user authentication at the DP, using an eID of the DP country, record matching is not needed. If eIDAS is used, then the DP can solicit additional information from the U to perform the match. |
| Transitivity of user identity | The assumption can be relaxed in comparison to the Intermediation pattern, because the user plays the central role in this pattern. | The user authenticates themselves at the DP |
| Hand-on of UI between actors | The User navigates from the DC eProcedure portal to the DP evidence portal – this hand-on of the user is facilitated by the DC | The routing information for the VC pattern consists of URLs of the respective evidence portals, not DIDs. The DID connection is established directly between User and DP. |
| Mandate and Proxy | Identical to Intermediation, however not relevant for the VC Pattern in the scope of DE4A. | Mandates and powers are not in scope for the Studying Abroad Pilot's VC Use Case. |
| Encryption Gap | The assumption can be relaxed in comparison to the Intermediation pattern. | Encryption is handled by the DID connection between U and DC and between U and DP respectively |
| Structured data vs. unstructured data | All evidence using this pattern are represented as structured and machine-readable data in the form of Verifiable Credentials adhering to a common VC schema for any given evidence-type | For each evidence-type in scope of the pilot, a common VC schema must be agreed. |
| Automated re-use of data | Adherence to a common VC schema makes automated re-use much more likely | This is not to say that the provision of the (public) service can be end-to-end automated. In the diploma recognition use case, for example, the matching of study subjects and requirements will remain an expert task for the foreseeable future. |
| Data transferor re-issues the evidence in the form of VC | We assume that the DT can re-issue the evidence in the form of VC again in the name of the data owner. | Issuing of the VC is not equivalent to the issuing of the original evidence. For the diploma user case this means, for example, that the VC is an evidence that a diploma is existing, meaning is different from the diploma issued by a university previously. |
| Issuing VC with diploma claims | We are not issuing new diplomas but VCs, which have those claims that a diploma, already in the registry, has. | This does not preclude that in the future, a university can directly issues a diploma in form of a VC that corresponds to the VC schema adopted by DE4A. This case is compatible with the VC pattern proposed in this document. |
| Multi-evidence Case | Only the Multiple Data Providers case is relevant for the VC pattern as each evidence is equated to one VC that is issues separately.
If Data Providers (Issuers) are not highly integrated on MS-level, then the users need to re-authenticate on several different platforms and establish DID connection with different SSI Authority agents. |
The Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3) does not involve multiple evidences. |
Business process collaboration
The Figure below models the Verifiable Credential pattern in BPM notation. Using the colouring of the tasks in the BPMN, the different points of interaction of users is clarified. The yellow colour represents the agent (digital wallet) activity. The green colour represents the activities performed in the DC portal and interaction management, while the blue colour represents the activities performed in the DP portal. In the table of this section all business activities are described.
The business collaboration diagram can be roughly divided into three sections: The first section shows the dialogue between the User and the DP via the eProcedure portal concerned with setting up the communication (i.e. DID connection) and submitting credentials in form of Verifiable Presentations (VP), leading up to the user task ‘Follow evidence status’. This task is central for the management of the evidence exchange. The second section shows the conversation between User and DP and is required if the User has not all VCs available in their wallet and wants to collect additional credentials from one of several DPs. Note that in this pattern, there is no direct conversation between DC and DP. The third section concerns the evaluation of the evidence by the DP, the submission of the (public) service request and includes the subprocess ‘Provide (public) service’.
In the case that the user needs to collect additional VCs, the processes need to return to the first section for the submission of the VC to the DC. This is modelled using a process pattern called “ad-hoc loop”. They are drawn bold to make them stand-out as they are part of the normal flow [ad-hoc loops are more typically used to model corrective exception flows]. It helps the understanding to recall the BPMN collaboration diagrams [2] models the participant processes (here User, DC and DP) as essentially independent sequence flows that communicate via message flows (dashed lines).
Looking first at the user process and following the bold ad-hoc loops that return the user to submitting the VC to the DC after they received a new VC from a DP, you can see that the user first returns to the activity ‘Follow evidence status’ in the DC portal. Here they select to submit the required VC. This throws a message to the DC to trigger the (re-)submission and then waits for the receipt of new ‘Proof request’. A parallel gateway is used in this return flow to depict the fact that the user returns to the evidence status overview in the DC portal while in parallel interacting with their (mobile) wallet. Upon receiving the ‘Proof request’ the user follows the normal “forward” flow submitting the VP.
In the DC process, we see that the fact that a required VC is not available moved the DC on a process path ‘Prepare DP lookup’ and wait for the receipt of the above mentioned ‘(re-)submission trigger’ from the user (or alternatively for a session time out, which would require a re-authentication of the user to resume the Procedure). Upon receiving the trigger, the DC process follows via the bold return flow to ‘Generate VC-based evidence proof request’ from where they follow again the “forward” path to receiving the Verifiable Presentation and on to validating it.
Business activities of the Verifiable Credential pattern
| Activity / UC | Role | Type | Description |
| Request or resume (public) service procedure | U | User | Identical with the Intermediation Pattern:
The user navigates to the eProcedure in the DC country and requests a (public) service. This means they fill in the required information and start the eProcedure. It is specific to the MS and the eProcedure how much information is provided by the user (i.e. which fields to be filled out) in this activity (i.e. prior to authentication) or when submitting the eProcedure later in the process. Email should be included as means to contact the user or provide updates. If the user is returning to a previously started procedure, the eProcedure will return to original instance after authentication. |
| Request authentication | DE | Service | Identical with the Intermediation Pattern:
The DE requests the U to authenticate themselves. This can happen in two ways, either using eIDAS (default) or using the eID of the DC MS, in case that the U has the national eID of the DC country available (see cases 3) and 4) in Table 4 above). The DE provides both options to the U. |
| Provide authentication details | U | User | Identical with the Intermediation Pattern:
The U uses the means available to them to provide the authentication details. This can happen at the user’s discretion using the eID of the DC MS or eIDAS. In the second case, the user is forwarded to the authentication service of the identity provider of their means of authentication. If the user is representing another entity (typically a legal person), this relation is also retrieved as part of this authentication. |
| Establish user identity | DE | Service | Identical with the Intermediation Pattern:
The DE establishes the identity of the U in the DC MS environment. In the eIDAS case, this means that the eIDAS uniqueness ID must be linked to the national identification number used to access the MS registries. In the national eID case, this means that the eIDAS attributes (mandatory and optional) must be retrieved for further use in the process. In case of a business user, the company identification must be matched. The match of the representing natural person to a population register is not required in all MS. |
| Redirect user to another channel | DE | Service | Identical with the Intermediation Pattern:
Exception handling activity: The U cannot be identified in an automated way by the DC and alternative digital or non-digital channel information (depending on the eProcedure at hand user and potentially dependent on the type of identification error) is collected and provided to the U. |
| Abort eProcedure | U | User | Identical with the Intermediation Pattern: Exception handling activity: Alternative channel information is displayed to the user and the user exits the e-procedure. |
| Determine procedural requirements | DE | Service | Identical with the Intermediation Pattern:
The DE compares the available information (i.e. in the DC MS registries via the national OOP layer) with the information required by the eProcedure. The result can be a (list of) required evidence, defined in terms of the DC country, which is then displayed to the user as a request to provide the evidence, together with the option for the user to request the evidence via the OOTS. This activity is not trivial and should prevent that we ask a User for evidence that is readily available in the DC MS and might not be available in the OOTS cross-border scope. Example: It would not make any sense for a Dutch DC to ask a German national born in the Netherlands to provide a birth certificate (which he could not get via the OOTS as it is not cross-border). A similar situation would be asking a French national with a Belgian university diploma to provide that diploma in order to be admitted for a PhD in another Belgian university. |
| Request VC-based transfer of evidence | U | User | The U chooses to request the transfer of evidence in the form of Verifiable Credentials (VC). This action starts the process of the preparation for a DID Connection between the U and DE. |
| Generate DID invitation | DE | Service | The DE generates an invitation for a DID connection with a U. The invitation is presented to the user in the form of a QR code. The invitation holds data about the DID document of the DE, stored on a distributed ledger. The DID document also holds the DE endpoint, which is used for DID communication with U agent. |
| Accept DID connection with DC | U | User | The U responds with accepting or rejecting an invitation for a DID connection generated by DE by scanning a QR code presented on the eProcedure portal. Note that this step is vulnerable for a "shoulder attack", meaning that a different mobile agent could be used than the one of the user authenticated in the previous step via eIDAS. The pilot could attempt to use encrypted VCs, however, we this vulnerability should be closed by the new European identity wallet. |
| Establish DID connection with User | DE | Service | Both parties (agents) create a DID connection in case none existed before, otherwise the DID connections is just initialised.
The DE informs U about the success of the connection establishment. |
| Generate VC-based evidence proof request | DE | Service | Based on the procedural requirements, the DE generates an evidence request for the U. |
| Provide available evidence (VP) | U | User | The U is informed about available evidence (VCs) that matches the procedural requirements and has the option to select which proofs in the form of Verifiable Presentation (VP) he will share with DE. After the VC's are chosen, a VP of those is provided to the DE. |
| Inform that evidence (VC) is not available | U | User | The user is informed about available evidence (VCs) that matches the procedural requirements and has the option to select which proofs in the form of Verifiable Presentation (VP) he will share with DE. If the user does not have any required evidence or does not select any of the matched ones to share with DE, the DE is informed that VC is not available. |
| Prepare DP lookup | DE | Service | The DE retrieves the technical routing information (e.g. rooting identifier or URL of the evidence portal provider), based on the evidence type (in terms of DP country) and the issuing competent authority (or geographic scope of authority). |
| Save (public) service request | DE | Service | The DE saves public service request and determines the amount of time window in which the user can provide required evidence in the form of VP. |
| Follow evidence status | U | User | After the U chooses to provide the evidence required in the form of a VC and establishes a DID connection with the DE, the eProcedure portal shows them an evidence status overview.
It essentially shows the progress of the request for each separate requested evidence (VC). These statuses should include: 1) Required 2) Provided In the case the evidences are required, the U has the option to PROVIDE the EVIDENCE or LOOK UP THE VC-ISSUER. |
| Choose VC issuer | U | User | The U chooses a DP that is capable to provide evidence in the form of VC's that are needed for U to submit eProcedure. |
| Request the evidence (VC) | U | User | The user informs a DP that they request the evidence in the form of VC's by way of following the link displayed in the Procedure portal; Note that the URL will need to include a parameter specifying the VC schema requested. This action starts the process of the preparation for a DID Connection and VC issuing process between U and DT. |
| Request authentication for evidence (VC) retrieval | DT | Service | The DO requests the U to authenticate themself. This can happen in two ways, either using eIDAS (default) or using the eID of the DP MS, in case that the U has the national eID of the DP country available. The case of using the national eID scheme would consequently be quite common.
The DP provides both options to the U. |
| Provide authentication details for evidence (VC) retrieval | U | User | The U uses the means available to them to provide the authentication details. This can happen to the user’s discretion using the eID of the DP MS or eIDAS. In the second case, the user is forwarded to the authentication service of the identity provider of their means of authentication. |
| Evaluate evidence (VC) request | DT | Service | The DT receives the request and checks whether the request meets formal requirements and can be accepted. It should e.g. be checked whether the requesting U can reasonably and rightfully request that specific type of evidence. |
| Generate DID invitation for evidence (VC) retrieval | DT | Service | The DT generates an invitation for a DID connection with a U. The invitation is represented to the user in the form of a QR code. The invitation holds data about the DID document of the DT, stored on a distributed ledger. The DID document also holds the DT endpoint, which is used for DID communication with U agent. |
| Accept DID connection with DP | DT | Service | The U responds with accepting or rejecting an invitation for a DID connection generated by DE by scanning a QR code presented on the DT portal. Note that this step is vulnerable for a "shoulder attack", meaning that a different mobile agent could be used than the one of the user, authenticated in the previous step via eIDAS. The pilot could attempt to use encrypted VCs, however, we hope that this vulnerability would be closed by the new European identity wallet. |
| Establish DID connection with User | DT | Service | Both parties (agents) create a DID connection in case none existed before, otherwise the DID connections is just initialised.
The DT informs U about the success of the connection establishment. |
| Re-establish user identity | DO | Service | Identical with the User-supported Intermediation pattern:
The DO matches the information about the user (i.e. eIDAS mandatory and optional attributes) with DP country records to identify the user in their systems. This amounts to matching the eIDAS attributes to a national identification number. (If the national eID is used, this task is skipped). Data Owner activity, because in a distributed scenario, the data transferor might not have a legal basis to do so. |
| Request additional identification attributes | DO | Service | Identical with the User-supported Intermediation pattern:
If the User identity cannot be easily matched, the DO displays to user a UI requesting additional identification attributes to improve the match. |
| Provide additional identification information | U | User | Identical with the User-supported Intermediation pattern:
Exception handling activity: Interactive form- or chat-based Q&A for additional identification information (beyond eIDAS attributes). The requested information clearly depends on the available information at the data provider. |
| Extract evidence | DO | Service | Identical with the Intermediation Pattern:
The DO extracts the requested evidence from their registry and forwards it to the DT. |
| Digitise evidence | DO | Subprocess | The DO digitize required evidence if evidence details are in the paper archive. |
| Communicate non-available or delay of evidence | DT | Service | Exception handling activity: The DT informs the U that they cannot be identified unequivocally and the OOTS cannot be used to transfer the evidence or that the requested evidence cannot be provided or cannot be provided within the agreed SLA. |
| Receive error or delay notification | U | User | Identical with the User-supported Intermediation pattern:
Exception handling activity: The DP displays error or delay information to the User. These error messages are listed above in the activity ‘Establish non-availability of OOP’ In addition, the exception UI informs the U to return to the eProcedure portal of the DC. |
| Save or abort (public) service request | U | User | Identical with the Intermediation Pattern:
Exception handling activity: The U is informed that not all required evidence could be received, hence that there are still missing evidences preventing the eProcedure to be completed. It depends (only) on the functionality of the specific eProcedure portal what options are provided to the U. We expect that in most cases the user can save the procedure in order to return at a later stage, to repeat the cross-border OOP request or to provide the missing evidence themselves. |
| Issue requested evidence (VC) | DT | Service | The DT issue evidence in the form of VC to a U. |
| Preview and accept requested evidence (VC) | U | User | The U receives requested evidence in the form of VC from the DT, review it, and decide to accept or reject the storage of this evidence to their digital wallet. |
| Verify evidence (VP) | DE | Service | The DC receives evidence in the form of VP. In this activity, the following pieces of information inside the VP are verified:
· evidence issuer (DP) is checked (is evidence issuer competent in issuing such evidence?) · evidence issuer (DP) digital signature is validated (is provided evidence issued from stated evidence issuer) · U verification (is the authenticated U subject of provided evidence?), · The validity in time of evidence is checked (is provided evidence valid at the time of presentation, i.e., revoked, etc.). |
| Evaluate evidence (VC) | DE | Service | Identical with the Intermediation Pattern:
The DE checks whether all requested evidences are available and validates that they conform to the evidence type requested. In the positive scenario that all evidences are available, the DE communicates to the user that the procedure can be submitted. In the negative case that not all evidences are received, the DE communicates this back to the U. The Procedure can then not be completed. |
| Submit eProcedure | U | User | Identical with the Intermediation Pattern:
The U fills the remaining fields required for the eProcedure. It is specific to the MS and the eProcedure which fields to be filled out in this activity or when requesting the eProcedure at the start of the process. Usually the U is prompted to verify the provided information in an overview before hitting the Submit button. |
| Provide public service | DE | Subprocess | Identical with the Intermediation Pattern:
This is a subprocess that is very heterogeneous in composition and timeline, depending on which public service is provided and by which competent authority. Theoretically, the subprocess could be fully automated in some cases, but typically this is a back-office process involving multiple activities of public servants and might take days to several weeks. In many countries the maximum time for this process is defined by law. |
| Receive acknowledgment or receipt | U | Receive | Identical with the User-supported Intermediation pattern:
The U is waiting to receive the acknowledgment that their (public) service request is received in order and that the service will be provided, oftentimes incl. an indication of the expected time needed. The acknowledgment can be is displayed in the eProcedure portal or sent by e-mail or deposited in a government-hosted, secure message box or a combination of the above. |
| Receive (public) service result | U | Receive | Identical with the Intermediation Pattern:
Once the public service is completed, the result is provided to the U. This communication is fully dependent on the functionalities of the eProcedure portal (e.g. e-mail and/or government-hosted, secure message box). |
Verifiable Credentials Pattern Conversations
| From | Message | To | Description |
| U | (Public) service request | DC | Identical with the Intermediation Pattern:
The choice of public service requested and an initial set of information from the user required for the initiation of the request (breadth and type of information can vary between MS and requested service and can be substantial in some cases. Essentially this includes all information that the user provides prior to the point in the procedure where authentication is required). Inclusion of e-mail could facilitate (additional) messages to the user. |
| DC/DP | Authentication request | U | Identical with the Intermediation Pattern:
Link to UI or identity service provider, potentially to several alternative eID services. |
| U | Authentication details | DC/DP | Identical with the Intermediation Pattern:
Identity information of the user (i.e. uniqueness ID + identification data set). |
| DC | Alternative channel information | U | Identical with the Intermediation Pattern:
Contact information (e.g. email, telephone or address) of an alternative channel to request the public service or to complete authentication/registration. |
| DC | Request for evidence | U | Identical with the Intermediation Pattern:
List of evidences (in terms of the DC country) that are required to complete the eProcedure. |
| U | Evidence (VC) initiation | DC/DP | A user request to the eProcedure portal to start an evidence exchange in the form of VC using DID communication |
| DC/DP | DID invitation | U | The authority (DC/DP) prepares a QR code which is sent to the user to be scanned. The QR code presents a DID invitation, which includes all required information for the establishment of DID communication between users’ agent and authority (DC/DP) agent. The invitation can also be sent in other forms, e.g., HTTP, NFC, Bluetooth. |
| U | DID connection request | DC/DP | By scanning the QR code, the user’s agent decodes the QR code into a human-readable form, which is shown on the agent’s UI (information about the authority’s agent with which the DID connection will be established). After the review, the user decides to accept the DID invitation. The information about the user agent is sent to the authority (DC/DP). |
| DC/DP | DID connection response | U | The information about the success of the DID communication establishment. |
| DC | Evidence (VC) Proof request | U | The information, which evidences in the form of VC’s are required for public service. |
| U | Evidence (VC) non-availability notification | DC | The information that some of the required VC’s are not currently available in the digital wallet that is part of the user agent. |
| U | Evidence (VC) Verifiable presentation | DC | Evidence (VC) in the form of a Verifiable Presentation. |
| DC | Evidence status update with DP lookup (VC not provided) | U | The information, which holds the status of required evidence and the information, also includes a list of DPs, which can provide required evidence (VC) in case some evidence is missing. |
| DC | Evidence status update + email (VC provided) | U | The information, which holds the status of the required evidence. Furthermore, it also includes a list of DPs which can provide required evidence (VC) in case some evidence is missing. |
| U | Evidence (Re)submission trigger | DC | The information that triggers new evidence (VC) proof request. |
| U | Implicit user request | DP | The choice for a DP to provide the evidence (issuance of VC) and an initial set of information about requested evidence (VC), such subject and evidence type. |
| DP | Request for additional information | U | Identical with the User-supported Intermediation pattern:
Depending on the information on record at the DP this request can include different attributes (e.g. matriculation number for universities, national identifiers for ministries, maiden name….) |
| U | Additional information | DP | Identical with the User-supported Intermediation pattern:
The information attribute that the DP requested to perform the extended identify matching. |
| DP | Evidence not available | U | The information that evidence cannot be provided. |
| DP | Evidence response (VC) | U | Requested evidence in the form of verifiable credentials. |
| U | (Public) service response completed | DC | The information about the submission of the eProcedure. |
| DC | Acknowledgment of receipt | U | The information that submission of the eProcedure has been received. |
| DC | (Public) service response | U | The result of public service |
Process realization
Figure 26 below shows how application services serve the User process (cf. Figure 25). The application services are realized by application collaborations, which are presented in section 4.6.4. In Table 35, the application services are described.
Through the EProcedure Portal, the User requests or resumes a public service, and via the Trust Architecture provides their authentication details. At this point, the User can decide to abort the eProcedure or choose the form of evidence needed for (public) service. User Agent, amongst other things, supports the User requesting to provide evidence in the form of a VC, which are (if already acquired) stored in their edge agent (i.e. mobile phone). Next, the QR code as the method of initiation of the DID connection establishment is presented to the User. By scanning the QR code by the User Agent information about the Data Consumer agent (cloud) are presented to the User who now has the choice to accept (or reject) the establishment of DID connection.
After the connection is established, the User Agent checks if proper evidence is already present. Alternatively, the User has a choice to inform the DC that evidence in the form of VC is not available. Moreover, the User can follow the status of the evidence (Evidence Interchange Management) to check which evidence has already been provided to the DC. In case that the User does not hold the required evidence, through the Information Desk, the User can perform a search for the Data Provider who can contribute relevant evidence (in the form of a VC).
After the DP is found, the User can request the re-issuance of the evidence in the form of a VC. For this action, via Trust Architecture, the User needs to provide authentication details to (possibly, with additional identification data) to the DP. In case of any exception, a notification about the error or delay is provided, and the (public) service request can be saved or aborted. After the authentication, the Evidence Portal shows the User QR code, which includes all information about the DID connection establishment with the DP. Now, the User’s DE4A User Agent can accept DID connection with DP.
In case of a successful DID connection establishment between the User and DP, the requested re-issued evidence in the VC form is delivered. The User can preview the evidence and choose to accept the requested evidence. As a result of acceptance, the evidence is stored in a digital wallet in the User Agent. Now the User can provide available evidence in the form of Verifiable Presentation to the DC, and when all required pieces of evidence are successfully presented to the DC, submit the eProcedure. After this, the User receives an acknowledgment of receipt and finally receive (public) service result.
Figure 27 below shows how the DC process (cf. Figure 25) is served by application services (dark blue: DE4A specific, light blue: EIRA). The application services are realized by application collaborations, which are presented in section 4.6.4. In Table 35, the application services are described.
The Data Consumer, through the Trust Architecture, authenticates the User and establishes their identity. Next, through the EProcedure Portal, the determination of procedural requirements is performed, and later, through the portal cloud agent (i.e., DE4A authority agent), the DID connection with user is established, including the generation of DID invitation and DID connection response. Subsequently, the evidence (VC) proof request is generated, and after the proof is provided (in the form of Verifiable Presentation) by the user, this proof is cryptographically validated and evaluated from the business requirements standpoint of view. When all required pieces of evidence are provided and successfully validated and evaluated, the public service is provided to the User.
If the User does not hold all the necessary pieces of evidence, a DP lookup where the missing evidence can be acquired is prepared (Evidence Interchange Management).
Figure 28 below shows how the DP process (cf. Figure 25) is served by application services. The application services are realized by application collaborations.
The Data Provider authenticates the User through the Trust Architecture, and if needed, requests additional identification attributes and re-establish the User’s identity. An evaluation of the User's request for (re)issuing of evidence in the form of VC is performed. Later, through the Portal cloud agent (i.e. Authority Agent), the DID connection with the User is established, including the generation of a DID invitation and DID connection response.
The requested evidence is extracted through Evidence Retrieval (if necessary, also digitized) and (re)issued to the User in the form of VC (through Authority Agent). In case of an error or delay within the process mentioned above, the User is informed through the Evidence Portal.