Suggestions for further developments by third parties

EBSI integration: EBSI was not integrated due to lack of responsiveness from the EBSI group team providing any answer to our application (beta test, wave 3). The system should be compatible with EBSI and integration should not be complex. Prerequisite: EBSI is publicly available

Signup authentication system: An OIDC workflow to exchange credentials between the wallets and 3rd party platforms was implemented. However, direct signup and sign-in of new users into 3rd party platforms using information from the wallet still needs to be developed. This implementation should be straightforward in a very similar way to the use cases already implemented within the project. Prerequisite: It could be done as soon as there are trustable issuers, such as identity providers from different EU countries, that generate VerifiableIDs containing basic user data.

SSI EduWallets provides third parties with a kit to issue and verify verifiable credentials from the users’ wallets. With this implementation, any third party can leverage the use of VCs and DIDs to perform:

1. Issuance and verification of new types of verifiable credentials.

2. Cross-device flow on verification.

3. Improve or create new schemas to add more information to the verifiable credentials issued.

4. SSI onboarding creating user profiles into a platform streamlining the process & the user data privacy.

Real use case example

Another possibility would be to implement a real use case scenario ready to go live into production.

This real use case scenario could consist, for example, of generating a certificate after completion of an online course. This certificate would be generated by the LMS and could be verified by the educational institution. The implementation of this use case would require the following steps:

1. Define what needs to be stored in the credential (event/course name, teacher/presenters, small description, unique identifier for the online content, etc.). The definition of this data is the schema of the certificate and will depend on the final intended use of the credentials. Some validation would be needed to make sure the course details are not tampered in the LMS platform once exported into the credential and the contents in the credential cannot be confused with any other course.

2. Validate the personal data of the user (email, name, etc.). Depending on the real use case of the certificate. Some validation of the identity of the user may be required since the wallet will only communicate the DID from the user, maybe it is needed to validate that the owner of the DID is the same user registered in the learning platform and not someone else. This process can be challenging since no official institution is issuing identity credentials at the moment, but this process may not be totally necessary if the level of trust needed for the credentials is not high.

3. Implementation of a fully featured wallet APP (this may be avoided if the decision is made to work with a wallet provider owning an already existing wallet solution)

4. The restrictions for the registration with EBSI could be a blocker, for this reason, the usage of a DID system without registries, based on peer-to-peer interactions (key), could be more suitable.

This would require different actors:

• Educational technology provider implementing an LMS or similar platform.

• Educational institution making use of the real use case with real users.

• Wallet provider, implementing a ready-to-production wallet APP.