Will “Verifiable Credentials” replace X.509 certificates in the future?

X.509 certificates have been around for over 40 years. They are used for the identification of subjects (web servers, persons, etc.). They are considered trusted and proven credentials and we rely on them every day. So why introduce Verifiable Credentials (VC), a new technology unknown to the general public? In order to be able to compare a Public Key Infrastructure (PKI) solution (which is based on X.509 certificates) with a Self-Sovereign Identity (SSI) solution, the difference and the characteristics of their credentials must first be illuminated.

In a user-centric approach, information about an identity is given to the holder in the form of a standardised container, because it follows the process of “issue-receive-possess and present-verify”. Figure 1: User-centred triangle

What does this process look like?

Credentials are created by an issuer. The evidence is then given to the holder, who stores it for later use. Unbeknownst to the issuer, the holder can prove something about themselves by presenting their evidence to a verifier. The verifier can then decide whether the evidence presented is sufficient to access a resource and whether they trust the publisher. This article does not investigate whether there are security vulnerabilities in VCs versus X.509 certificates. The aim is rather to make a comparison of the two vessels, because both VCs and X.509 certificates represent an identity that can be verified by a checking service.

Digital signatures

A digital signature is a basic cryptographic procedure whereby an owner of a private key can sign a message with that key, and anyone in possession of the corresponding public key can verify that signature. With a digital signature, the origin (authenticity) and integrity of the data can be verified.

X.509 certificate In order for a public key of a participant to be used in a trustworthy manner by someone else, it is packed together with information (e.g. the name) of the owner in a certificate and digitally signed by the issuer. In this way, the issuer makes the certificate forgery-proof and certifies that the information originates from him or her. Basically, an X.509 certificate can contain the following information:

• Name (optionally some attributes) of the subject to be protected
• Public key of the subject
• Additional information of the issuer, intended use of the key and the certificate
• Revocation information
• Signature of an issuer covering the entire certificate content

This format of an X.509 certificate has been standardised for a long time and has been widely used for decades.

Verifiable Credential (VC) VCs are digital credentials that allow an issuer to make an assertion about a holder. They are digitally signed by the issuer so that an auditor can verify the issuer’s claim. Figure 2 Example of a Verifiable CredentialX – .509 certificates and VCs have the same purpose and are similar in content.

So what is the difference between these two credentials?

An X.509 certificate is a rigid entity compared to a Verifiable Credential. X.509 certificates have a very specific format and the content has been agreed upon over time. Thus, the certificate of a server or a user has a predefined content depending on the quality class. There are some attempts and efforts to extend X.509 certificates and the underlying PKI system, such as attribute certificates. But is it worth it? Conversely, one can say that Verifiable Credentials are much more flexible in principle. A VC can contain anything from a simple statement (“true/false”) to a complex structure (e.g. IMS Comprehensive Learner Record[1]), as long as this statement conforms to certain formats (e.g. JSON-LD or JSON-JWT). The only thing that remains is the condition that an examiner must be able to interpret the content of a statement. For this purpose, the schema definition is given in the above example of a VC. This makes a VC versatile compared to an X.509 certificate. The most important difference between X.509 certificates and Verifiable Credentials, however, is privacy. When X.509 certificates were developed (the first publication was in 1988), there were no privacy requirements. These were only added later. In the past, “non-forgeability” was the only requirement at the centre. Today, non-forgeability of the proof and protection of privacy are required. Today, the main privacy requirements are as follows:

• Selective disclosure: A user must be able to choose which personal data to share with a verifying service.
• Misuse: A user must be able to ensure that a verifying service does not obtain a user-identifying identifier from them unless the user willingly hands it over.
• Anonymity: The user must be able to hide his identity from the verifying service.

With X.509 certificates, for example, the first requirement is very difficult to implement, as classic applications only allow “en-bloc” (all or nothing) verification. In contrast, with VCs – as long as they follow a certain protocol (for issuance and presentation) – this is easier to realise. On the other hand, a verifying service needs to be able to verify the claims presented to it and ensure that they are still valid and have been issued to that very user by a trusted issuer. X.509 certificates have long fulfilled this simple type of verification, due to their fixed structure. However, as soon as a minimum level of privacy is to be maintained, vessels and their applications are confronted with completely different challenges. A comparison in tabular form of the main requirements listed above:

Conclusion

Verifiable credentials have several advantages over X.509 certificates. Firstly, they are much more flexible in terms of their content and secondly, they address privacy better. Moreover, they are the basis of “Self-Sovereign Identity”, which could become a serious technological approach in the field of identities. However, VCs do not simply replace X.509 certificates. Both vessels will appear simultaneously in the future. Where the protection of a holder’s privacy is important, VCs will probably be increasingly used. For securing communication channels (secure channels), on the other hand, X.509 certificates will continue to be used in the future. At present, classic protocols such as S/MIME or TLS do not support VCs. However, this may change soon. It therefore makes sense to adapt existing environments so that they also support VCs in addition to X.509 certificates in order to enable the two technologies to coexist.

References

[1] https://www.imsglobal.org/activity/comprehensive-learner-record

[2] This would be possible with individual attribute certificates (an extension of X.509 identity certificates).

[3] With BBS+ signatures (BbsBlsBoundSignature2020).

[4] With a customised presentation (BbsBlsBoundSignatureProof2020)