Difference between revisions of "Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3)"

From DE4A
Jump to navigation Jump to search
Line 14: Line 14:
  
 
== [[SA UC3 Process|Process]] ==
 
== [[SA UC3 Process|Process]] ==
 +
 +
In MVP 1.0, the UC3 process flow includes the following steps:
 +
*A student accesses an [https://wiki.de4a.eu/index.php/Evidence_Portal] of a Data Provider (DP) to obtain a Verifiable Credential (VC).
 +
*The student is asked to authenticate at the DP using a legally recognized electronic identity (eIDAS identity).
 +
*After successful authentication, the student explicitly requests that he/she wants to obtain diploma evidence from the DP in the form of a Verifiable Credential.
 +
*If the DID connection between the student's [https://wiki.de4a.eu/index.php/User_Agent] (mobile wallet) and the [https://wiki.de4a.eu/index.php/Authority_Agent] integrated into the [https://wiki.de4a.eu/index.php/Evidence_Portal] has not yet been established, he/she requests a new QR code to be generated in order to establish the DID connection between two agents.
 +
*The student scans the QR code displayed in the [https://wiki.de4a.eu/index.php/Evidence_Portal] in his mobile wallet application and accepts the DID connection invitation.
 +
*Once the DID connection is established, the student requests the DP to send him his/her diploma evidence as a Verifiable Credential to his mobile wallet.
 +
*The DP retrieves the student's diploma from a registry, transforms it into a canonical format according to the [https://wiki.de4a.eu/index.php/SA_UC3_Data_Model] and to the JSON-LD format of a Verifiable Credential, digitally signs it with its DID key and sends it for preview on the student's mobile phone.
 +
*The student previews the Verifiable Credential offered by the DP and accepts the DP's VC offer.
 +
*The DP sends the final Verifiable Credential to the student who accepts the received VC and stores it under an arbitrary name in his/her mobile wallet for any future use.
 +
*A student then accesses an [https://wiki.de4a.eu/index.php/EProcedure_Portal] of a Data Consumer (DC) to submit a Verifiable Presentation (VP) for the required procedure.
 +
*The student is asked to authenticate at the DC using a legally recognized electronic identity (eIDAS identity).
 +
*After successful authentication, the student explicitly requests that he/she wants to submit diploma evidence to the DC in the form of a Verifiable Presentation.
 +
*If the DID connection between the student's [https://wiki.de4a.eu/index.php/User_Agent] (mobile wallet) and the [https://wiki.de4a.eu/index.php/Authority_Agent] integrated into the [https://wiki.de4a.eu/index.php/EProcedure_Portal] the has not yet been established, he/she requests a new QR code to be generated in order to establish the DID connection between two agents.
 +
*The student scans the QR code displayed in the [https://wiki.de4a.eu/index.php/EProcedure_Portal] in his mobile wallet application and accepts the DID connection invitation.
 +
*Once the DID connection is established, the student requests the DC to send him his/her a request for a VP submission.
 +
*The DC sends a request to the student containing information on the expected VP format to be submitted for procedural requirements.
 +
*The student accepts the received request on his/her mobile phone by selecting the requested VP conforming to the request format from his/her mobile wallet and submitting it as a response to the DC's request.
 +
*The DC receives and stores the VP submitted by the student under a specific name for any future references.
 +
*The student explicitly requests the DC to validate the submitted VP.
 +
*The [https://wiki.de4a.eu/index.php/Authority_Agent] integrated into the [https://wiki.de4a.eu/index.php/EProcedure_Portal] validates the submitted VP in terms of the VC issuer (DP), holder (student) and the VC schema, and displays validation results. During the validation, the [https://wiki.de4a.eu/index.php/Authority_Agent] uses the integrated EBSI/eSSIF Connector to check the VP against entries in the EBSI registries (TIR, TSR).
  
 
== Pilot scenario ==
 
== Pilot scenario ==
 
==== UC3 - DE4A ====
 
==== UC3 - DE4A ====
 
The pilot scenario involves the SSI approach for requesting diploma recognition in the eVŠ system in Slovenia and at the University of Lisbon in Portugal. Students will request their diploma evidence in the form of verifiable credentials from the data providers (issuers) in Portugal, Slovenia and Spain, store them in their mobile digital wallets, and present them in the form of verifiable presentations to the two data consumers (verifiers) in Slovenia and Portugal. The data consumers will be able to check the validity of the verifiable presentations using the EBSI infrastructure, in particular that they correspond to a registered schema, that the issuers are also registered as such in EBSI, and that the identity of the student in the diploma matches the authentication data of the student authenticated at the DE.
 
The pilot scenario involves the SSI approach for requesting diploma recognition in the eVŠ system in Slovenia and at the University of Lisbon in Portugal. Students will request their diploma evidence in the form of verifiable credentials from the data providers (issuers) in Portugal, Slovenia and Spain, store them in their mobile digital wallets, and present them in the form of verifiable presentations to the two data consumers (verifiers) in Slovenia and Portugal. The data consumers will be able to check the validity of the verifiable presentations using the EBSI infrastructure, in particular that they correspond to a registered schema, that the issuers are also registered as such in EBSI, and that the identity of the student in the diploma matches the authentication data of the student authenticated at the DE.

Revision as of 14:20, 29 June 2021

Use Case "Diploma/Certs/Studies/Professional Recognition" of the Studying Abroad Pilot (SA UC3) focuses on diploma recognition in order to facilitate the use of such information by government and other sectors. This procedure corresponds to the "Requesting academic recognition of diplomas, certificates or other proof of studies or courses" procedure from Annex II of the SDGR. Portugal, Slovenia and Spain are involved in this use case.

Interaction pattern

This UC uses the Verifiable Credentials Pattern.

Data model

Components

Process

In MVP 1.0, the UC3 process flow includes the following steps:

  • A student accesses an [1] of a Data Provider (DP) to obtain a Verifiable Credential (VC).
  • The student is asked to authenticate at the DP using a legally recognized electronic identity (eIDAS identity).
  • After successful authentication, the student explicitly requests that he/she wants to obtain diploma evidence from the DP in the form of a Verifiable Credential.
  • If the DID connection between the student's [2] (mobile wallet) and the [3] integrated into the [4] has not yet been established, he/she requests a new QR code to be generated in order to establish the DID connection between two agents.
  • The student scans the QR code displayed in the [5] in his mobile wallet application and accepts the DID connection invitation.
  • Once the DID connection is established, the student requests the DP to send him his/her diploma evidence as a Verifiable Credential to his mobile wallet.
  • The DP retrieves the student's diploma from a registry, transforms it into a canonical format according to the [6] and to the JSON-LD format of a Verifiable Credential, digitally signs it with its DID key and sends it for preview on the student's mobile phone.
  • The student previews the Verifiable Credential offered by the DP and accepts the DP's VC offer.
  • The DP sends the final Verifiable Credential to the student who accepts the received VC and stores it under an arbitrary name in his/her mobile wallet for any future use.
  • A student then accesses an [7] of a Data Consumer (DC) to submit a Verifiable Presentation (VP) for the required procedure.
  • The student is asked to authenticate at the DC using a legally recognized electronic identity (eIDAS identity).
  • After successful authentication, the student explicitly requests that he/she wants to submit diploma evidence to the DC in the form of a Verifiable Presentation.
  • If the DID connection between the student's [8] (mobile wallet) and the [9] integrated into the [10] the has not yet been established, he/she requests a new QR code to be generated in order to establish the DID connection between two agents.
  • The student scans the QR code displayed in the [11] in his mobile wallet application and accepts the DID connection invitation.
  • Once the DID connection is established, the student requests the DC to send him his/her a request for a VP submission.
  • The DC sends a request to the student containing information on the expected VP format to be submitted for procedural requirements.
  • The student accepts the received request on his/her mobile phone by selecting the requested VP conforming to the request format from his/her mobile wallet and submitting it as a response to the DC's request.
  • The DC receives and stores the VP submitted by the student under a specific name for any future references.
  • The student explicitly requests the DC to validate the submitted VP.
  • The [12] integrated into the [13] validates the submitted VP in terms of the VC issuer (DP), holder (student) and the VC schema, and displays validation results. During the validation, the [14] uses the integrated EBSI/eSSIF Connector to check the VP against entries in the EBSI registries (TIR, TSR).

Pilot scenario

UC3 - DE4A

The pilot scenario involves the SSI approach for requesting diploma recognition in the eVŠ system in Slovenia and at the University of Lisbon in Portugal. Students will request their diploma evidence in the form of verifiable credentials from the data providers (issuers) in Portugal, Slovenia and Spain, store them in their mobile digital wallets, and present them in the form of verifiable presentations to the two data consumers (verifiers) in Slovenia and Portugal. The data consumers will be able to check the validity of the verifiable presentations using the EBSI infrastructure, in particular that they correspond to a registered schema, that the issuers are also registered as such in EBSI, and that the identity of the student in the diploma matches the authentication data of the student authenticated at the DE.