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

From DE4A
Jump to navigation Jump to search
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
''Back to [[Studying_Abroad_Pilot|Studying Abroad pilot main page]]''
 +
 
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.
 
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.
 +
 +
== 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.
 +
 +
==[[SA UC3 Implementation|Implementation]]==
 +
* [[SA UC3 Implementation#Verifiers|Verifiers]]
 +
* [[SA UC3 Implementation#Issuers|Issuers]]
 +
* [[SA UC3 Iterations|Iterations]]
 +
* [[SA UC3 Status|Status]]
  
 
== Interaction pattern ==
 
== Interaction pattern ==
 
This UC uses the [[Verifiable Credentials Pattern]].
 
This UC uses the [[Verifiable Credentials Pattern]].
 
==[[SA UC3 Data Model|Data model]]==
 
* [[SA UC3 Data Model#Data model diagram|Data model diagram]]
 
* [[SA UC3 Data Model#Attribute specification|Attribute specification]]
 
* [[SA UC3 Data Model#JSON|JSON definition]]
 
  
 
==[[SA UC3 Components|Components]]==
 
==[[SA UC3 Components|Components]]==
 
* [[SA UC3 Components#Common eIDAS components|Common eIDAS components]]
 
* [[SA UC3 Components#Common eIDAS components|Common eIDAS components]]
 
* [[SA UC3 Components#Common evidence exchange components|Common evidence exchange components]]
 
* [[SA UC3 Components#Common evidence exchange components|Common evidence exchange components]]
 +
 +
==[[Higher_Education_Diploma_Canonical_Evidence|Data model]]==
 +
* [[Higher_Education_Diploma_Canonical_Evidence#Data Model|Data model diagram]]
 +
* [[Higher_Education_Diploma_Canonical_Evidence#Attribute Specification|Attribute specification]]
 +
* [[SA UC3 Data Model#JSON|JSON definition]]
  
 
== [[SA UC3 Process|Process]] ==
 
== [[SA UC3 Process|Process]] ==
Line 39: Line 51:
 
**The [https://wiki.de4a.eu/index.php/Authority_Agent Authority Agent] integrated into the [https://wiki.de4a.eu/index.php/EProcedure_Portal 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 Authority Agent] uses the integrated EBSI/eSSIF Connector to check the VP against entries in the EBSI registries (TIR, TSR).
 
**The [https://wiki.de4a.eu/index.php/Authority_Agent Authority Agent] integrated into the [https://wiki.de4a.eu/index.php/EProcedure_Portal 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 Authority Agent] uses the integrated EBSI/eSSIF Connector to check the VP against entries in the EBSI registries (TIR, TSR).
  
== Pilot scenario ==
+
== Legal status ==
==== UC3 - DE4A ====
+
{| class="wikitable"
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.
+
|+
 +
! colspan="4" |Use case Diploma recognition
 +
|-
 +
| colspan="2" |'''Data provider country'''
 +
| colspan="2" |'''Data evaluator country'''
 +
|-
 +
|'''Member State name'''
 +
|'''Status in this use case'''
 +
|'''Member State name'''
 +
|'''Status in this use case'''
 +
|-
 +
|Portugal
 +
|Issuing real or test data.
 +
|Portugal
 +
|Receiving real or fake data, but not for a real procedure.
 +
|-
 +
|Slovenia
 +
|Issuing real data for a limited set of students.
 +
|Slovenia
 +
|Receiving real or fake data, but not for a real procedure.
 +
|-
 +
|Spain
 +
|Issuing real, but anonymized data.
 +
|
 +
|
 +
|-
 +
| colspan="2" |'''Identified risks / problems / incidents'''
 +
| colspan="2" |'''Implemented solutions or plan''' (note: use the same line as the risk/problem/incident, so
 +
that the solution/plan matches the risk/problem/incident next to it)
 +
|-
 +
|''[Member State(s) name(s)]''
 +
|Describe: ''dd/mm/yyyy, [description of the risk/problem/incident''
 +
| colspan="2" |Describe: ''dd/mm/yyyy, [description of the solution or plan]''
 +
|}
 +
'''Additional notes:'''
 +
 
 +
''[Provide any additional information that's required to describe the status of the use case, if applicable.]''
 +
 
 +
=== Pilot risk status ===
 +
{| class="wikitable"
 +
|+
 +
!Risk level
 +
!Tick if this level applies (tick only one)
 +
!Comments (if any)
 +
|-
 +
|Low
 +
|
 +
|
 +
|-
 +
|Medium
 +
|X
 +
|
 +
|-
 +
|High
 +
|
 +
|
 +
|}
 +
 
 +
=== Measures taken ===
 +
 
 +
{| class="wikitable"
 +
|+
 +
!Measure description
 +
!Tick if this measure was taken
 +
!Description or comments (if any)
 +
|-
 +
|Piloting partners will '''communicate proactively towards each other on issues or incidents''' ('''always mandatory''')
 +
|''x''
 +
|''Will be done when issues arise, which is not yet the case.''
 +
|-
 +
|Any real-life '''pilot participants (if applicable) are informed''' of the fact that they are involved in piloting activities,
 +
including any risks and countermeasures taken, and the (lack of) legal effects and consequences of participation.
 +
 
 +
Appropriate documentation should be retained to demonstrate that this information has been provided.
 +
 
 +
'''(mandatory for medium and high)'''
 +
|''x''
 +
|''Students are informed about involvement in piloting activities at the beginning of the procedure.''
 +
|-
 +
|If the piloting involves '''real-life persons''', piloting should be organised under the '''supervision of a DPO'''.
 +
'''(mandatory for medium and high)'''
 +
|''x''
 +
|''Hans Graux''
 +
|-
 +
|If the piloting would be done on a '''production environment''', all pilot partners should '''notify''' any operators of such environments in advance.
 +
Appropriate measures should be taken that piloting activities d'''o not result in negative legal or practical consequences''' for any real-life persons, real life data, or production environments.
 +
 
 +
The production environments should be '''cleaned''' if the piloting activity was not intended to have long term legal or practical consequences.
 +
 
 +
'''(mandatory for medium and high)'''
 +
|''x''
 +
|''Operators are informed and attend pilot run sessions. The Verifiers allow for submitting verifiable credentials, but without any legal or practical consequences for the students (no real procedures for recognition of diplomas in participating countries).''
 +
|-
 +
|All piloting activities should be '''monitored by pilot partners''' (each solely in relation to such components of the piloting activities which are under their responsibility)
 +
in a manner that allows any incidents to be detected and remedied (including by contacting any affected real-life persons where needed).
 +
 
 +
'''(mandatory for medium and high)'''
 +
|''x''
 +
|''Piloting activities are monitored by pilot partners.''
 +
|-
 +
|The '''DE4A project DPO''' (Hans Graux) should be informed prior to initiating piloting activity, and of any incidents that are reasonably likely to create legal effects or practical impacts on any real-life persons
 +
 
 +
'''(mandatory for high)'''
 +
|''x''
 +
|''This wiki informs the DPO.''
 +
|-
 +
|Implementation of a '''pilot monitoring and remediation strategy''' to assess whether exchanged evidences are reasonably capable of satisfying the requirements for high risk piloting documented in the deliverables,  
 +
and to ensure that any errors in the piloting activity can be detected and remediated in a manner that eliminates any negative legal or practical consequences.
 +
 
 +
'''(mandatory for high)'''
 +
|''x''
 +
|''Piloting activities are monitored by pilot partners.''
 +
|}

Latest revision as of 08:36, 28 March 2023

Back to Studying Abroad pilot main page

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.

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.

Implementation

Interaction pattern

This UC uses the Verifiable Credentials Pattern.

Components

Data model

Process

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

  • Obtaining a Verifiable Credential
    • A student accesses an 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 User Agent (mobile wallet) and the Authority Agent integrated into the 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 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 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.
  • Presenting a Verifiable Presentation
    • A student then accesses an 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 User Agent (mobile wallet) and the Authority Agent integrated into the 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 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 Authority Agent integrated into the 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 Authority Agent uses the integrated EBSI/eSSIF Connector to check the VP against entries in the EBSI registries (TIR, TSR).

Legal status

Use case Diploma recognition
Data provider country Data evaluator country
Member State name Status in this use case Member State name Status in this use case
Portugal Issuing real or test data. Portugal Receiving real or fake data, but not for a real procedure.
Slovenia Issuing real data for a limited set of students. Slovenia Receiving real or fake data, but not for a real procedure.
Spain Issuing real, but anonymized data.
Identified risks / problems / incidents Implemented solutions or plan (note: use the same line as the risk/problem/incident, so

that the solution/plan matches the risk/problem/incident next to it)

[Member State(s) name(s)] Describe: dd/mm/yyyy, [description of the risk/problem/incident Describe: dd/mm/yyyy, [description of the solution or plan]

Additional notes:

[Provide any additional information that's required to describe the status of the use case, if applicable.]

Pilot risk status

Risk level Tick if this level applies (tick only one) Comments (if any)
Low
Medium X
High

Measures taken

Measure description Tick if this measure was taken Description or comments (if any)
Piloting partners will communicate proactively towards each other on issues or incidents (always mandatory) x Will be done when issues arise, which is not yet the case.
Any real-life pilot participants (if applicable) are informed of the fact that they are involved in piloting activities,

including any risks and countermeasures taken, and the (lack of) legal effects and consequences of participation.

Appropriate documentation should be retained to demonstrate that this information has been provided.

(mandatory for medium and high)

x Students are informed about involvement in piloting activities at the beginning of the procedure.
If the piloting involves real-life persons, piloting should be organised under the supervision of a DPO.

(mandatory for medium and high)

x Hans Graux
If the piloting would be done on a production environment, all pilot partners should notify any operators of such environments in advance.

Appropriate measures should be taken that piloting activities do not result in negative legal or practical consequences for any real-life persons, real life data, or production environments.

The production environments should be cleaned if the piloting activity was not intended to have long term legal or practical consequences.

(mandatory for medium and high)

x Operators are informed and attend pilot run sessions. The Verifiers allow for submitting verifiable credentials, but without any legal or practical consequences for the students (no real procedures for recognition of diplomas in participating countries).
All piloting activities should be monitored by pilot partners (each solely in relation to such components of the piloting activities which are under their responsibility)

in a manner that allows any incidents to be detected and remedied (including by contacting any affected real-life persons where needed).

(mandatory for medium and high)

x Piloting activities are monitored by pilot partners.
The DE4A project DPO (Hans Graux) should be informed prior to initiating piloting activity, and of any incidents that are reasonably likely to create legal effects or practical impacts on any real-life persons

(mandatory for high)

x This wiki informs the DPO.
Implementation of a pilot monitoring and remediation strategy to assess whether exchanged evidences are reasonably capable of satisfying the requirements for high risk piloting documented in the deliverables,

and to ensure that any errors in the piloting activity can be detected and remediated in a manner that eliminates any negative legal or practical consequences.

(mandatory for high)

x Piloting activities are monitored by pilot partners.