SSI & eduID

eduID is a digital student identity, independent of any institution. Currently, eduID offers a way for educational institutions to grant guests - for example lecturers and researchers from other institutions and external advisors - access to internal systems. That, however is just the beginning for eduID. A possible future for eduID lies in the concept of Self-Sovereign Identity (SSI), a novel approach to digital identity which puts the user at the center. During the second half of 2021, on behalf of the eduID project team, I explored what eduID could look like as an SSI and what standards could be used to implement such an SSI system.

What is Self-Sovereign Identity?

Schematic description of an SSI system
Figure 1: Roles and information flows within SSI environments

Self-Sovereign Identity represents the idea that a person should own and control their digital identities themselves instead of having to rely on an external party like SURFconext or Google to act as a broker for their digital identity. Users should also control when they wish to share personal data as well as which personal data they share with other parties. In such a system users authenticate themselves by presenting so-called claims to a service (also called a Verifier) to prove certain properties about themselves. Such a verifier might for example be webshop offering study material for students (like SURFspot).

claim, sometimes also called an attribute, is essentially a statement about the user. Examples of a claim/attribute are birth date, first name, second name or a student number. These claims are usually taken from a so-called credential. A credential is like a digital version of a physical ID card. Like their physical equivalents, these credentials contain a number of different claims about their subject. Credentials and the claims within them always have an authoritative source (called an Issuer), who is asserting these claims and issued this digital ID card to the user. This is usually a party that services recognise as a legitimate source for the specific type of credential and the claims within the credential. An issuer could for example be your university asserting that you are a student or professor at their institution.

Verifiers accept the claims presented to them because they trust the authoritative source(s) behind those claims. For this purpose users usually also present a digital proof to the verifiers to proof that the claims indeed come from trusted sources and have not been manipulated.

If you want to learn more about the technical characteristics, possibilities and challenges of SSI, I recommend reading SURF's Technical exploration on Ledger-based self-sovereign identity report.

Where does eduID come in?

Within an SSI environment, users use a so-called digital wallet, a piece of software, usually a smartphone app, to store their digital cards, i.e. credentials, akin to a physical wallet, where one usually carries around a bunch of different cards. However a digital wallet does much more than just store credentials. It also facilitates interaction with other parties (i.e. issuers and verifiers) and derives so-called presentations from the credentials within the wallet. These presentations contain a selection of claims (or even just one claim), that have been requested by a verifier in a way that only the requested claims need to be presented instead of having to present entire credentials, which also contain claims that the verifier does not need to know. This minimises the amount of data that users need to share and thus enhances their privacy.

The wallet is thus the component with which users interact with the wider SSI environment and is as such a very crucial part of an SSI ecosystem. This is where eduID comes in:

  • eduID could become such a wallet in the form of an app.
  • But eduID could also be an issuer that provides certain credentials such as a credential showing you are a student.

What open standards could be used in the implementation of an SSI system?

To implement such an SSI system, it is important to utilise open standards wherever possible. Two such standards that are used in most SSI systems are Verifiable Credentials (VCs) and Decentralised Identifiers (DIDs).

Schematic construction of a Verifiable Credential
Figure 2: Basic components of a verifiable credential

Verifiable Credentials define a standardised data model for credentials within an SSI system, which prescribes a certain structure. They include a proof, usually in the form of a digital signature to prove their validity. A wallet can then derive so-called verifiable presentations from these verifiable credentials, which only contain specific claims that have been requested.

Example image of a DID
Figure 3: A simple example of a decentralized identifier (DID)

Decentralized Identifiers are a type of globally unique identifiers that are generated by their subject (like e.g. a user, an issuer or a verifier) themselves, of which they prove control via cryptographic proofs such as digital signatures.
Together with a so-called DID method, a DID is resolved to a DID document, which contains the actual data associated with the identifier, like a verification key and an endpoint.
DIDs can either be public, i.e. shared openly with other parties, or private/pairwise, where they are only shared with one other party. In eduID, users would ideally have a different private DID for each issuer and verifier they are interacting with to prevent tracking.

Additionally, protocols for the communication between the user and services (Issuers and Verifiers) are necessary and some do exist already. During my internship I examined two standards that are actually used in practice by some SSI systems, namely DIDComm, protocols that are based on relationships between parties that are based on their DIDs, and OpenID Connect Self-Issued OpenID Provider, an extension of the popular OpenID Connect protocol. However both standards currently suffer from a lack of widespread adoption and a lack of maturity (which to a lesser extends is also true for the data model standards).

What could this look like in practice?

Image of the potential home screen and credential inspection screen within a potential eduID app

These illustrations demonstrate how an eduID wallet app could look like. Users see an overview of all credentials in their wallet, which they can also inspect in more details to see which claims they contain. To add a credential to their wallet, users usually scan a QR code.

Illustration of a screen to add credentials (similar to the one in IRMA)

In the prototype I build, it is also possible to add a credential by selecting them from a list. This should make it easier for users to get started since it makes it easy to fill the wallet with simple credentials from the get-go.

When a service (verifier) wants to know certain properties about the user or simply wants to authenticate them, they will usually display either a QR code, that the user needs to scan with their wallet app. The service will then display which properties they like to know about the user.

Illustration of a potential request to disclose data to a service

If the user is willing to share these claims, they can accept the request, otherwise they can just decline it.

For eduID, this wallet app should also log past interactions in order to offer users some transparency, especially where some of their data is stored.

Illustration of the Data & Activity screens within the eduID app

What would an eduID SSI ecosystem look like?

Schematic overview of a potential eduID trust framework

The illustration above shows the participants in a potential eduID SSI ecosystem and their interactions. In addition to the already listed participants, there is also the Verifiable Data Registry. The Verifiable Data Registry is used by participant to share data that is meant to be publicly accessible. In many existing SSI systems, this registry takes the form of a distributed ledger, i.e. a blockchain, but is also possible to use a central database or some other data structure for this.

A very important aspect in this system is the trust relationships between the different participants. It is very important that users and verifiers can trust issuers to issue a legitimate credential and that the issuer is a trusted source for the type of information contained in the credentials they provide to users. To establish this trust, issuers will most likely enter a contract with SURF to specify what kind of credentials they may issue and define their responsibilities. SURF as the provider of the eduID wallet would in this case be a trusted third party that vouches for these issuers.

Conversely, it is also important that users in particular can trust verifiers in the sense that:

  • verifiers only request data they absolutely need
  • verifiers treat privacy-sensitive data responsibly

Since the set of potential verifiers is quite large, not everyone can enter an individualised contract. One potential approach that the illustration models takes a hybrid approach with two categories of verifiers:

  • trusted verifiers, who did sign a contract with SURF and may request privacy-sensitive data in specific contexts
  • untrusted verifiers, who did not sign a contract and may thus only request non-privacy sensitive data

Conclusions

SSI offers a very interesting future for digital identity and eduID as it offers many advantages and opportunities to the actual users. However it is still a long way to get there due to the lack of maturity in many areas. In the future, there will probably be many SSI systems for different contexts and it will be important for these systems to be interoperable, i.e. that they are compatible with each other. For this purpose open standards need to mature and conventions on their implementation within the wider SSI community need to be established. SURF will closely follow the future developments of existing and new standards as well as conventions on the implementation of data models and protocols. 

Want to know more?

If you have further questions or would like to learn more about my research you can read my full internship report or contact michiel.schok@surf.nl

Auteur

Reacties

Dit artikel heeft 5 reacties

Reactie van Peter Walgemoed

Hello Matti,

Congratulations on your great thesis. I am working with SURF Research Cloud and SRAM. I also developed a NGI Ledger GeneConsent MVP with Waag Society, which used ZKP and SSI developed by the NGI community. We just presented a use/show case for SURF Research Week where we used SRAM and eduGAIN to create a collaborative Dutch-Finnish research team. I am curious what you think could be a roadmap to connect SURF/EU-Research identities to NGI-SSI?
Best, Peter

Als antwoord op door Peter Walgemoed

Reactie van Arnout Terpstra

Hi Peter,
SURF is engaged in various scouting and pilot activities concerning researcher identity and research access management based on SSI. A roadmap for connecting SSI related technology to production level SURF research services however does not yet exist.
Best, Arnout

Als antwoord op door Arnout Terpstra

Reactie van Peter Walgemoed

Hi Arnout,
Thanks for your feedback. I am looking into setting up an open source community to share experiences and see which technologies have a big potential to be used in research production. What do you think about connecting to enclosed Microsoft development? https://techcommunity.microsoft.com/t5/azure-active-directory-identity/…
Best, Peter

Als antwoord op door Peter Walgemoed

Reactie van Peter Clijsters

Hi Peter,
The Microsoft development you are referring to is indeed very interesting. We're already cooperating with Microsoft in developing a proof-of-concept between eduID and MS VC. This should materialize in the coming weeks and we're thinking about issueing an eduID as an MS VC and then using it at a service as a verifier.

Als antwoord op door Peter Clijsters

Reactie van Peter Walgemoed

Hi Peter,
That is great news. Would it be interesting to connect to Finland? We just presented this SRAM-eduGain cancer collaboration show case between NKI and Helsinki University at the SURF Research Week. https://youtu.be/E_UQzl27v9A Helsinki University Hospital is a reference site for Microsoft. The other international contact we can learn a lot from is Keio University. They are connected to eduGain via GakuNin and have implemented an open source development for their VCs with Microsoft.
Best, Peter

Gerelateerde artikelen