This post is based on my understanding and feedback after studying the Self Sovereign Identity concepts (SSI ) via all the documents and videos provided by Damien Bod in his blog post about SSI.
In addition, the following version of W3C specifications was used:
| Specification name | Version | URL |
| Decentralized Identifiers (DIDs) | 1.0 | https://www.w3.org/TR/2021/PR-did-core-20210803/ |
| Verifiable Credentials Data Model | 1.1 | https://www.w3.org/TR/2022/REC-vc-data-model-20220303/ |
| Linked Data Cryptographic Suite Registry | Draft Community Group Report 29 December 2020 | https://w3c-ccg.github.io/ld-cryptosuite-registry/ |
| RSA Signature Suite 2018 | Draft Community Group Report 26 May 2020 | https://w3c-ccg.github.io/lds-rsa2018/ |
What is SSI?
To quote Damien: “Self-sovereign identity is an emerging solution built on blockchain technology for solving digital identities which gives the management of identities to the users and not organizations.”
The two schemas below give a high-level view (a detailed view is provided in the next section):
Some terminologies
Before deep-diving into involved flows and actors, it is important to define different terms used in SSI (definitions are from the corresponding W3C specification).
Decentralized identifier (DID):
A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically.
DID document:
A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.
Example of DID identifier and associated DID document taken from the specification :
Verifiable credential:
A standard data model and representation format for cryptographically verifiable digital credentials as defined by the W3C “Verifiable Credentials” specification. (source)
Note about a verifiable presentation of a verifiable credential: “a verifiable presentation expresses data from one or more verifiable credentials, and is packaged in such a way that the authorship of the data is verifiable. If verifiable credentials are presented directly, they become verifiable presentations“. (page.74 source)
An example of a verifiable credential issued: A national identity card.
Holder:
It might perform by possessing one or more verifiable credentials and generating presentations from them. A holder is usually, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories (wallet) (source).
A wallet is a secure container for credentials and private keys.
Issuer:
A role that an entity can perform by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder (source).
Example of issuer: Government.
Verifier:
A role that an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation for processing. Other specifications might refer to this concept as a relying party (source).
Example of verifier: Bank.
Blockchain:
A blockchain is a growing list of records, called blocks, that are linked together using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (source).
Who are the actors involved in an SSI system?
Below is a high-level overview of the flows involved in an SSI system taking a university diploma as an example (page 28 of source):
A blockchain is a growing list of records, called blocks, that are linked together using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (source).
Here:
- The academic institution represents the Issuer of the verifiable credentials.
- The user represents the Holder of the verifiable credentials.
- The employer represents the Verifier of the verifiable credentials.
Let’s deep dive into the two flows involved:
- Issuing of a verifiable credential by an Issuer to a Holder.
- Validation, by a Verifier, of a verifiable presentation provided by the Holder.
Verifiable credentials issuing flow:
Verifiable presentation validation flow:
SSI key aspects
- It is possible to verify a verifiable credential even if the Issuer is not available or does not exist anymore.
- There is no direct communication between an Issuer and a Verifier during the issuing of a verifiable credential or validation of a verifiable presentation.
- Once stored in a blockchain, a DID document cannot be modified or deleted.
- Holder fully controls the level of information provided to a Verifier within the verifiable credentials provided to it.
- Digital signature, using asymmetric RSA/EC key pair, is a critical pillar of SSI and trust/integrity foundation.
- Availability of the blockchain used by the Issuer/Verifier is a critical pillar of SSI.
Remarks about SSI providers
- For the moment; it is not possible to use any wallet with any SSI solution. Each solution is locked to its own wallet (October 2021 – source).
- An SSI provider (or solution) provides the Issuer and Verifier posture of a verifiable credential and it seems not to be possible to currently mix 2 different SSI providers (one for Issuer and one for Verifier) even if it is theoretically possible (source):
- An SSI provider (or solution) provides a REST API providing an abstraction over the Issuing and Verification operation of verifiable credentials, the wallet management as well as the blockchain to store DID identifier + DID document.
Cryptographic algorithms and SSI-related W3C specifications
Algorithms supported by the “Verifiable Credentials Data Model” are defined in the specification named “Linked Data Cryptographic Suite Registry”. It is important to note that this one was in the “Unofficial Draft“ status when this post was written (March 2022). Therefore, there is not currently W3C official standard regarding supported and recommended signature algorithms.
Among the list of mentioned signature algorithms in the document, there is one, named “RsaSignature2018” :
This one is using a signature algorithm, named “RSASSA-PKCS1-v1_5”, identified as not recommended for future cryptographic operation by the Cryptosense company in 2014:
This document (page 2), named “On the Security of the PKCS#1 v1.5 Signature Scheme”, also mentioned that “RSASSA-PKCS1-v1_5” algorithm should not be used for new applications:
However, even if “RsaSignature2018” is present in the “Linked Data Cryptographic Suite Registry” specification, the GitHub repository of the algorithm specification explicitly indicates to not use it anymore:
It shows that the “Linked Data Cryptographic Suite Registry” specification needs to be finalized to remove any deprecated signature algorithms to prevent any issue by the implementer of SSI systems.
Security attention points noticed
In addition to the challenge points identified by Damien Bod (source [16]), the following attention points regarding an SSI system were identified:
- Private identification information disclosure via the data stored in the DID document stored on the blockchain.
- Same thing via the DID identifier itself.
- Security issues of the cryptographic algorithms used for keys and signatures.
- Attacks on deserialization processes used on Issuer and Verifier sides when manipulating serialized data coming from the blockchain or from the holder.
- Security issues affecting the quality of the implementation of the credential verification operation performed by the Verifier: signature validity, signature coverage (like unsigned claims ), type of credentials received against expected, expiration date, revocation state, issuer expected, alteration of properties without affecting the signature, credential replay attack, etc.:
- Also, include the validation of the integrity of the elements stored outside a verifiable credential as mentioned in the “Verifiable Credentials” specification (source):
- Attacks on the wallet itself targeting the holder side: Protection strength of the secret keys like ensuring that access to a credential requires entering a secret or a physical action like pushing a button (reference in the “Verifiable Credentials” specification).
- Attack to perform unexpected alteration of DID documents in the blockchain (verifiable data registry) because the “Verifiable Credentials” specification defines the following statement in its Trust Model: “All entities trust the verifiable data registry to be tamper-evident and to be a correct record of which data is controlled by which entities.” (source).
- Misusage of verifiable credentials for an authorization decision. Indeed, verifiable credentials are intended as a means of reliably identifying subjects and not for authorization purposes (source).
- Specific security issues affecting “Bearer Credentials”: Are not single-use where possible, contain personally identifying information and/or are correlatable (source).
- Secure protocols are not used on Issuer and/or Verifier sides (source).
Real-world use cases
The company TYKN implemented SSI in different contexts, for example, in a humanitarian aid one. The objective was to allow Syrian refugees to prove their identity, to Turkish companies, to find a job via a digital work permit stored on their mobile in an SSI mobile wallet.
SSI playground
In addition to the free tiers offered by some SSI providers (source section “Companies”), the “Hyperledger Indy” open-source project offers a complete SSI playground in the form of a collection of docker images.
Using this playground, it is possible to deep dive into the different elements involved in SSI flows such as the reception by a Holder of a verifiable credential from an Issuer.
A demonstration video was performed to show an example of the usage of this playground.
Conclusion
Self-Sovereign Identity (SSI) is a very interesting approach to significantly enhance the resiliency of any delivered credentials, as well as a boost for the dematerialization of official identification documents like passports, driver’s licenses, national identity cards and so on.
However, it misses nowadays a point from an SSI provider perspective because of the need to strictly follow the W3C specification to get interoperability between providers. In addition, the W3C specification for “Linked Data Cryptographic Suite Registry” must be finalized and released. It is needed to provide a clear guidance about cryptographic algorithms for secure handling of the keys and signature aspects of SSI flows.
Did you like this article? Find some more articles in our blog section.
