Verifiable Credentials Pattern - Revision history

Ictu alexander.bielowski: /* Business activities of the Verifiable Credential pattern */

2021-07-07T06:59:23Z

Business activities of the Verifiable Credential pattern

Ictu alexander.bielowski: /* Business activities of the Verifiable Credential pattern */

2021-07-07T06:56:36Z

Business activities of the Verifiable Credential pattern

Ictu alexander.bielowski: /* Business activities of the Verifiable Credential pattern */

2021-07-07T06:51:05Z

Business activities of the Verifiable Credential pattern

Ictu alexander.bielowski: /* Business activities of the Verifiable Credential pattern */

2021-07-06T18:36:34Z

Business activities of the Verifiable Credential pattern

Ictu alexander.bielowski: /* Business activities of the Verifiable Credential pattern */

2021-07-06T18:36:14Z

Business activities of the Verifiable Credential pattern

Ictu alexander.bielowski: /* Business activities of the Verifiable Credential pattern */

2021-07-06T18:30:05Z

Business activities of the Verifiable Credential pattern

Ictu alexander.bielowski: /* Working hypotheses and implementation principles */

2021-07-01T15:18:54Z

Working hypotheses and implementation principles

Ictu mavi.cristache: Added table captions

2021-06-29T13:45:49Z

Added table captions

Ictu mavi.cristache: typos after migration to doc

2021-06-29T11:05:59Z

typos after migration to doc

Ictu alexander.bielowski at 08:33, 28 June 2021

2021-06-28T08:33:22Z

@@ Line 303: / Line 303: @@
 |DT
 |Service
-|The DT issue evidence in the form of VC to a U.
+|The DT issues evidence in the form of VC to a U.
 |-
 |Preview and accept requested evidence (VC)

@@ Line 164: / Line 164: @@
 |DE
 |Service
-|Both parties (agents) create a DID connection in  case none-existed before, otherwise the DID connections is just initialised.
+|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.
@@ Line 246: / Line 246: @@
 |DT
 |Service
-|Both parties (agents) create a DID connection in  case none-existed before, otherwise the DID connections is just initialised.
+|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.

@@ Line 214: / Line 214: @@
 |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.
+|The user informs a DP that they request the  evidence in the form of VC's by way of following the link displayed in the Procedure portal; Note that the URL will need to include a parameter specifying the VC schema requested. This action starts the process of the preparation for a DID Connection and VC issuing process between U and DT.
 |-
 |Request authentication for evidence (VC) retrieval

@@ Line 274: / Line 274: @@
 |Service
 |Identical with the Intermediation Pattern:
-The DO extracts the requested evidence form their registry and forwards it to the DT.
+The DO extracts the requested evidence from their registry and forwards it to the DT.
 |-
 |Digitise evidence

@@ Line 219: / Line 219: @@
 |DT
 |Service
-|The DO requests the U to authenticate themself. This can happen in two ways, either using eIDAS (default) or  using the eID of the DP MS, in case that the U has the national eID of the DP  country available (case 1 and 2 in Table 4). The case of  using the national eID scheme would consequently be quite common.
+|The DO requests the U to authenticate themself. This can happen in two ways, either using eIDAS (default) or  using the eID of the DP MS, in case that the U has the national eID of the DP  country available. The case of  using the national eID scheme would consequently be quite common.
 The DP provides both options to the U.
@@ Line 241: / Line 241: @@
 |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 encrypted VCs, however, we hope that this vulnerability would be closed by the new European identity wallet.
+|The U responds with accepting or rejecting an  invitation for a DID connection generated by DE by scanning a QR code  presented on the DT portal. Note that this step is vulnerable for a "shoulder attack", meaning that a different mobile agent could be used than the one of the user, authenticated in the previous step via eIDAS. The pilot could attempt to use encrypted VCs, however, we hope that this vulnerability would be closed by the new European identity wallet.
 |-
 |Establish DID connection with User

@@ Line 159: / Line 159: @@
 |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 encrypted VCs, however, we this vulnerability should be closed by the new European identity wallet.
+|The U responds with accepting or rejecting an invitation for a DID connection generated by DE by scanning a QR code presented on the eProcedure portal. Note that this step is vulnerable for a "shoulder attack", meaning that a different mobile agent could be used than the one of the user authenticated in the previous step via eIDAS. The pilot could attempt to use encrypted VCs, however, we this vulnerability should be closed by the new European identity wallet.
 |-
 |Establish DID connection with User

@@ Line 73: / Line 73: @@
 |We are not issuing new diplomas but VCs, which have those claims that a diploma, already in the registry, has.
 |This does not preclude that in the future, a  university can directly issues a diploma in form of a VC that corresponds to  the VC schema adopted by DE4A. This case is compatible with the VC pattern  proposed in this document.
 |}

@@ Line 7: / Line 7: @@
 The VCs are issued to a User in a cryptographically secure manner collected in a user-maintained digital wallet that is part of the edge agent (i.e. mobile phone) in their possession. An Edge agent serves as an instrument with which all secure interchanges are managed (i.e. Initiate DID connection, Accept DID connection, Accept Verifiable Credential, Present Verifiable Credential). Moreover, the managing of DID connections, VC issuing and verifying operated by DPs and DCs is handled through a dedicated cloud agent.
-A mock-up of the user journey was created using Wireframes (see [[:File:DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf|Wireframe Mock-up]]). <span style="background:yellow">[can be referenced from the PSA if it is a public deliverable or be removed. AB: it is not a public deliverable, but it is publicly available on this Wiki and can hence be referenced. I would remove it from the formal D2.5 document nevertheless.]</span>
+A mock-up of the user journey was created using Wireframes (see [[:File:DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf|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.
 {| class="wikitable"
 |'''Interdisciplinary Topic'''
 |'''Hypotheses / Principle'''
@@ Line 87: / Line 88: @@
 === Business activities of the Verifiable Credential pattern ===
 {| class="wikitable"
 |'''Activity / UC'''
 |'''Role'''
@@ Line 351: / Line 353: @@
 === Verifiable Credentials Pattern Conversations ===
 {| class="wikitable"
 |'''From'''
 |'''Message'''

@@ Line 1: / Line 1: @@
 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. [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)|Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3).]]
-Data stored in the form of Verifiable Credentials (VC) are data representations in the form of a set of claims about some subject (i.e. User) issued by the issuer (i.e. Data Provider). Verifiable Credentials can be cryptographically verified by any third party i.e. Data Consumer (DC) to whom Verifiable Credentials is presented (usually in the form of a Verifiable Presentation(VP)).
+Data stored in the form of Verifiable Credentials (VC) are data representations in the form of a set of claims about some subject (i.e. User) issued by the issuer (i.e. Data Provider). Verifiable Credentials can be cryptographically verified by any third party i.e. Data Consumer (DC) to whom Verifiable Credentials is presented (usually in the form of a Verifiable Presentation (VP)).
-The VC Pattern utilizes blockchain technology features in several ways. First, storing decentralized identifiers (DIDs) and its correlating DID documents, which includes all relevant entity pieces of information about the issuer, including associated cryptographic keys, endpoints, etc. that can be used to authenticate the issuer (i.e. Data Provider(DP), and cryptographically validate VC that was issued by its DID. Second, storing and maintaining a list of verified/trusted issuers, i.e. DPs. Third, keep the list of revoked VCs. Furthermore, all other entities (i.e. DC, and Users) also have DIDs, and related DID documents, that are different than the DC information stored directly on their devices, i.e. Agents (edge or cloud). These DIDs are used for setting direct, i.e. DID communication between entities.
+The VC Pattern utilizes blockchain technology features in several ways. First, storing decentralized identifiers (DIDs) and its correlating DID documents, which includes all relevant entity pieces of information about the issuer, including associated cryptographic keys, endpoints, etc. that can be used to authenticate the issuer (i.e. Data Provider (DP), and cryptographically validate VC that was issued by its DID. Second, storing and maintaining a list of verified/trusted issuers, i.e. DPs. Third, keep the list of revoked VCs. Furthermore, all other entities (i.e. DC, and Users) also have DIDs, and related DID documents, that are different than the DC information stored directly on their devices, i.e. Agents (edge or cloud). These DIDs are used for setting direct, i.e. DID communication between entities.
 The VCs are issued to a User in a cryptographically secure manner collected in a user-maintained digital wallet that is part of the edge agent (i.e. mobile phone) in their possession. An Edge agent serves as an instrument with which all secure interchanges are managed (i.e. Initiate DID connection, Accept DID connection, Accept Verifiable Credential, Present Verifiable Credential). Moreover, the managing of DID connections, VC issuing and verifying operated by DPs and DCs is handled through a dedicated cloud agent.
@@ Line 77: / Line 77: @@
 The Figure below models the Verifiable Credential pattern in BPM notation. Using the colouring of the tasks in the BPMN, the different points of interaction of users is clarified. The yellow colour represents the agent (digital wallet) activity. The green colour represents the activities performed in the DC portal and interaction management, while the blue colour represents the activities performed in the DP portal. In the table of this section all business activities are described.
 [[File:Verifiable Credentials process.jpg|thumb|Business Process Collaboration view of the Verifiable Credential Pattern|alt=Business Process Collaboration view of the Verifiable Credential Pattern|center|800x800px]]
-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 DPs. Note that in this pattern, there is no direct conversation between DC and DP. The third section concerns the evaluation of the evidence by the DP, the submission of the (public) service request and includes the subprocess ‘Provide (public) service’.
+The business collaboration diagram can be roughly divided into three sections: The first section shows the dialogue between the User and the DP via the eProcedure portal concerned with setting up the communication (i.e. DID connection) and submitting credentials in form of Verifiable Presentations (VP), leading up to the user task ‘Follow evidence status’. This task is central for the management of the evidence exchange. The second section shows the conversation between User and DP and is required if the User has not all VCs available in their wallet and wants to collect additional credentials from one of several DPs. Note that in this pattern, there is no direct conversation between DC and DP. The third section concerns the evaluation of the evidence by the DP, the submission of the (public) service request and includes the subprocess ‘Provide (public) service’.
 In the case that the user needs to collect additional VCs, the processes need to return to the first section for the submission of the VC to the DC. This is modelled using a process pattern called “ad-hoc loop”. They are drawn bold to make them stand-out as they are part of the normal flow [ad-hoc loops are more typically used to model corrective exception flows]. It helps the understanding to recall the BPMN collaboration diagrams [2] models the participant processes (here User, DC and DP) as essentially independent sequence flows that communicate via message flows (dashed lines).
@@ Line 152: / Line 152: @@
 |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.
+|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 encrypted VCs, however, we this vulnerability should be closed by the new European identity wallet.
 |-
 |Establish DID connection with User
@@ Line 169: / Line 169: @@
 |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.
+|The U is informed about available evidence (VCs)  that matches the procedural requirements and has the option to select which  proofs in the form of Verifiable Presentation (VP) he will share with DE.  After the VC's are chosen, a VP of those is provided to the DE.
 |-
 |Inform that evidence (VC) is not available
 |U
 |User
-|The user is informed about available evidence  (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.
+|The user is informed about available evidence  (VCs) that matches the procedural requirements and has the option to select which proofs in the form of Verifiable Presentation (VP) he will share with  DE. If the user does not have any required evidence or does not select any of  the matched ones to share with DE, the DE is informed that VC is not  available.
 |-
 |Prepare DP lookup
@@ Line 261: / Line 261: @@
 |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.
+Exception handling activity: Interactive form- or chat-based Q&A for additional identification information (beyond eIDAS attributes). The requested information clearly depends on the available information at the data provider.
 |-
 |Extract evidence

@@ Line 212: / Line 212: @@
 |DT
 |Service
-|The DO requests the U to authenticate himself. 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 DO requests the U to authenticate themself. This can happen in two ways, either using eIDAS (default) or  using the eID of the DP MS, in case that the U has the national eID of the DP  country available (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.
@@ Line 219: / Line 219: @@
 |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.
+|The U uses the means available to them to provide  the authentication details. This can happen to the user’s discretion using  the eID of the DP MS or eIDAS. In the second case, the user is forwarded to  the authentication service of the identity provider of their means of  authentication.
 |-
 |Evaluate evidence (VC) request