Difference between revisions of "Verifiable Credentials Pattern"

From DE4A
Jump to navigation Jump to search
m
(Started adding content from D2.4)
Line 1: Line 1:
−
The Verifiable Credentials Pattern is one of the cross-borer interaction pattern of the DE4A [[Reference Architecture]]. It is a User-manages Access Pattern in terms (cf.   
+
The Verifiable Credentials Pattern is one of the cross-borer interaction pattern of the DE4A [[Reference Architecture]]. It is a User-manages Access Pattern in terms (cf. [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/2844e6_ec9fb88703ef431c8a55c63b294fb2cd.pdf 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 (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) 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.
 +
 
 +
== 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.
 +
{| class="wikitable"
 +
|'''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 [6]
 +
|-
 +
|Multiple, complementary, overlapping or conflicting  evidence equivalents
 +
|Multi-evidence cases must in principle be supported  – Identical to Intermediation (see 4.2.1)
 +
|Identical to Intermediation (see 4.2.1)
 +
|-
 +
|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 (see 4.2.1)
 +
|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 (see 4.2.1)
 +
|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 (chapter 4.2), however  not relevant for the PSA
 +
|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 (see 4.2.1)
 +
|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.
 +
[[File:Verifiable Credentials process.jpg|alt=BPMN 2.0 Collaboration diagram explaining the interaction between the User and the Data Consumer on the one side and the Data Provider on the other side in exchanging evidence in form of Verifiable Credentials and Verifiable Representations|none|thumb|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.
 +
 
 +
Table 33: Business Activities of the Verifiable Credential Pattern
 +
{| class="wikitable"
 +
|'''Activity / UC'''
 +
|'''Role'''
 +
|'''Type'''
 +
|'''Description'''
 +
|-
 +
|Request or resume (public) service procedure
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|Request authentication
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|Provide authentication details
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern, see Table  6
 +
|-
 +
|Establish user identity
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|Redirect user to another channel
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|Abort eProcedure
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|Determine procedural requirements
 +
|DE
 +
|Service
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|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.
 +
|-
 +
|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 he requests the  evidence in the form of VC's by way of following the link displays in the  Procedure portal. This action starts the process of the preparation for a DID  Connection 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.
 +
|-
 +
|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, see Table 23
 +
|-
 +
|Request additional identification attributes
 +
|DO
 +
|Service
 +
|Identical with the User -supported Intermediation  pattern, see Table 23
 +
|-
 +
|Provide additional identification information
 +
|U
 +
|User
 +
|Identical with the User -supported Intermediation  pattern, see Table 23
 +
|-
 +
|Extract evidence
 +
|DO
 +
|Service
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|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,  see Table 23
 +
|-
 +
|Save or abort (public) service request
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|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, see Table 6
 +
|-
 +
|Submit eProcedure
 +
|U
 +
|User
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|Provide public service
 +
|DE
 +
|Subprocess
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|-
 +
|Receive acknowledgment or receipt
 +
|U
 +
|Receive
 +
|Identical with the User-supported Intermediation pattern,  see Table 23
 +
|-
 +
|Receive (public) service result
 +
|U
 +
|Receive
 +
|Identical with the Intermediation Pattern, see Table 6
 +
|}
 +
 
 +
 
 +
Table 34: Verifiable Credentials Pattern Conversations
 +
{| class="wikitable"
 +
|'''From'''
 +
|'''Message'''
 +
|'''To'''
 +
|'''Description'''
 +
|-
 +
|U
 +
|(Public) service request
 +
|DC
 +
|Identical with the Intermediation Pattern, see Table 7
 +
|-
 +
|DC/DP
 +
|Authentication request
 +
|U
 +
|Identical with the Intermediation Pattern, see Table 7
 +
|-
 +
|U
 +
|Authentication details
 +
|DC/DP
 +
|Identical with the Intermediation Pattern, see Table 7
 +
|-
 +
|DC
 +
|Alternative channel information
 +
|U
 +
|Identical with the Intermediation Pattern, see Table 7
 +
|-
 +
|DC
 +
|Request for evidence
 +
|U
 +
|Identical with the Intermediation Pattern, see Table 7
 +
|-
 +
|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, see Table 26
 +
|-
 +
|U
 +
|Additional information
 +
|DP
 +
|Identical with the User-Supported Intermediation Pattern, see Table 26.
 +
|-
 +
|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
 +
|}
 +
 
 +
 
  
−
== Used by the following use cases ==
 
  
−
[[Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3)]]
 
  
 
== Application collaborations ==
 
== Application collaborations ==

Revision as of 09:53, 2 June 2021

The Verifiable Credentials Pattern is one of the cross-borer interaction pattern of the DE4A Reference Architecture. It is a User-manages Access Pattern in terms (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 (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) 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.

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 [6]
Multiple, complementary, overlapping or conflicting evidence equivalents Multi-evidence cases must in principle be supported – Identical to Intermediation (see 4.2.1) Identical to Intermediation (see 4.2.1)
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 (see 4.2.1) 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 (see 4.2.1) 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 (chapter 4.2), however not relevant for the PSA 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 (see 4.2.1) 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.

BPMN 2.0 Collaboration diagram explaining the interaction between the User and the Data Consumer on the one side and the Data Provider on the other side in exchanging evidence in form of Verifiable Credentials and Verifiable Representations
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.

Table 33: 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, see Table 6
Request authentication DE Service Identical with the Intermediation Pattern, see Table 6
Provide authentication details U User Identical with the Intermediation Pattern, see Table 6
Establish user identity DE Service Identical with the Intermediation Pattern, see Table 6
Redirect user to another channel DE Service Identical with the Intermediation Pattern, see Table 6
Abort eProcedure U User Identical with the Intermediation Pattern, see Table 6
Determine procedural requirements DE Service Identical with the Intermediation Pattern, see Table 6
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.
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 he requests the evidence in the form of VC's by way of following the link displays in the Procedure portal. This action starts the process of the preparation for a DID Connection 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.
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, see Table 23
Request additional identification attributes DO Service Identical with the User -supported Intermediation pattern, see Table 23
Provide additional identification information U User Identical with the User -supported Intermediation pattern, see Table 23
Extract evidence DO Service Identical with the Intermediation Pattern, see Table 6
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, see Table 23
Save or abort (public) service request U User Identical with the Intermediation Pattern, see Table 6
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, see Table 6
Submit eProcedure U User Identical with the Intermediation Pattern, see Table 6
Provide public service DE Subprocess Identical with the Intermediation Pattern, see Table 6
Receive acknowledgment or receipt U Receive Identical with the User-supported Intermediation pattern, see Table 23
Receive (public) service result U Receive Identical with the Intermediation Pattern, see Table 6


Table 34: Verifiable Credentials Pattern Conversations

From Message To Description
U (Public) service request DC Identical with the Intermediation Pattern, see Table 7
DC/DP Authentication request U Identical with the Intermediation Pattern, see Table 7
U Authentication details DC/DP Identical with the Intermediation Pattern, see Table 7
DC Alternative channel information U Identical with the Intermediation Pattern, see Table 7
DC Request for evidence U Identical with the Intermediation Pattern, see Table 7
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, see Table 26
U Additional information DP Identical with the User-Supported Intermediation Pattern, see Table 26.
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



Application collaborations

Authority Agent

User Agent

eProcedure Portal

Evidence Portal

Evidence Retrieval

Information Desk

Trust Architecture

Retrieved from ‘https://wiki.de4a.eu/index.php?title=Verifiable_Credentials_Pattern&oldid=1713’