Difference between revisions of "Verifiable Credentials Pattern"
m (→Business process collaboration: image size and alignment) |
m (→Business activities of the Verifiable Credential pattern: references) |
||
| Line 92: | Line 92: | ||
|U | |U | ||
|User | |User | ||
| − | |Identical with the Intermediation Pattern, see | + | |Identical with the Intermediation Pattern, see [[Intermediation Pattern|Business Activities of the Intermediation Pattern]]. |
|- | |- | ||
|Request authentication | |Request authentication | ||
Revision as of 12:16, 8 June 2021
The Verifiable Credentials Pattern is one of the cross-border interaction patterns of the DE4A Reference Architecture. It is a user-managed 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.
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, see Business Activities of the Intermediation Pattern. |
| 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 |
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 |
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 public service, and via Trust Architecture provides his authentication details. At this point, the User can decide to abort the process or choose the form of evidence needed for (public) service. Besides different options, the User can request 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 DE4A 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 DE4A 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 in DE4A User Agent. Moreover, the User can follow evidence status 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 on DE4A 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 DP, 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.
Data Consumer, through the Trust Architecture, authenticates and establishes the User’s identity. Next, through the eProcedure Portal, the determination of procedural requirements is performed, and the later through 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. In the case that all required pieces of evidence are provided and successfully validated and evaluated, the public service is provided.
If the user does not hold all the necessary pieces of evidence, a DP lookup where the missing evidence can be acquired is prepared.
Figure 28 below shows how the DP process (cf. Figure 25) is served by application services. The application services are realized by application collaborations, which
Data Provider authenticates the User through the Trust Architecture, and if needed, request for additional identification attributes and re-establish 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. DE4A 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. In the case of an error or delay within the process mentioned above, the User is informed through the Evidence portal.