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).

The Verifiable Credentials 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) under his possession. 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.

[needs explanatory text] Mock-up of user journey: 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.
Multiple, complementary, overlapping or conflicting evidence equivalents	Multi-evidence cases must in principle be supported – Identical to Intermediation: Multi-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.	It is to be investigated whether the pilot cases and MS combinations of the pilots entail multi-evidence cases at all. If that is not the case, the MVP could be restricted to a single request to single evidence case.
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 becomes 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 (handing it on).	We are not considering the exchange without user request and approval in the VC pattern (i.e. based on national or Union law).
Identity and Record Matching	The assumption can be relaxed in comparison to the Intermediation pattern: From experience on MS-level we see that a reasonably good match can result from the use of the (mandatory) eIDAS attributes. The working hypothesis is that this insight can be generalised to all pilot MSs. Two consequences of this hypothesis are that a) the user does not need to provide supplementary attributes and b) a second eIDAS authentication at the DP (potentially multiple DP) is not required.	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: After 12.12.2023, the SDGR and the legal task of the DC provide the legal basis for the exchange of user or data subject data from DC to DP. We assume that the development in preparation of the SDGR (i.e. piloting) is part of the public authorities’ tasks covered by the SDGR (i.e. Article 14 (11)), hence that the SDGR provides the legal basis for the pilots. Adding a GDPR consent in the explicit request is not a valid legal basis for the case that the identification does include personal data of other data subjects than the requestor (change of address for families).	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 rooting 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 PSA: The mandate and proxy challenge can be resolved by an extension of the eIDAS node.	The matching of interaction pattern to pilot use cases means that the DBA pilot is not intending to use the VC pattern, hence mandates and powers are not in scope.
Encryption Gap	The assumption can be relaxed in comparison to the Intermediation pattern: OOP in the public sector does not require true E2E encryption. The exchange between DR and DP must be encrypted and signed, as well as the transfers (if applicable on national level) between DR and DE on DC side and DT and DO on DP side (i.e. using the national OOP layer), but the encryption gap within the systems of the DR and DT is acceptable.	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 will need to 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 was 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 should be compatible with the VC pattern proposed in this document.

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 point 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.

Business Process Collaboration view of the Verifiable Credential Pattern

The business collaboration diagram can be roughly divided in three section: 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 data consumers. 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 the Figure 25 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 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 his (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 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 represented 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 attach", 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 ancrypted 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 (VC's) 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 (VC's) 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 him 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 in an interactive way 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 displays 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 for to authenticate themselves. 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 (case 1 and 2 in Table 4). 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 him 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 attach", 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 ancrypted VCs, however, we this vulnerability should 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: WHICH ONE? MISSING IN USI HM: I think "Provide additional identification information" is meant?
Provide additional identification information	U	User	Identical with the User-supported Intermediation pattern: Exception handling activity: Interactive form- of 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 form 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 his 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 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 heterogenous 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.

Process Realization of the User Process

Through the EProcedure Portal, the User requests or resumes a public service, and via the Trust Architecture provides his 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 his 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 the pieces of 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 evidence status (Evidence Interchange Management) to check which evidence has already been provided to the DC. In the 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 DP. Now, the User’s DE4A User Agent can accept DID connection with DP.

In the 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 in the case that all required pieces of evidence are successfully presented to 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.

Process Realization of the Data Consumer Process

The Data Consumer, through the Trust Architecture, authenticates the User and establishes his/her 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.

Process Realization of the Data Provider Process

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.