Chapter 3
The contents of this chapter are:
- How a verifiable credential is constructed and what are its main elements?
- How can a verifiable credential guarantee be secure and scalable in the SSI Model?
- How can a verifiable credential satisfy optimal levels of privacy and security, through zero-knowledge-proof algorithms?
- What is the state of the art of the Self-Sovereign Identity in the European regulatory boundary?
Chapter 3
The contents of this chapter are:
- How a verifiable credential is constructed and what are its main elements?
- How can a verifiable credential guarantee be secure and scalable in the SSI Model?
- How can a verifiable credential satisfy optimal levels of privacy and security, through zero-knowledge-proof algorithms?
- What is the state of the art of the Self-Sovereign Identity in the European regulatory boundary?
Basic concepts of verifiable credentials
When two software exchanges data, they need to use terminology that both of them understand. Let’s see how dialogue is created that technically has what is referred to as “the context of the conversation”.
Verifiable credentials and presentations have different attributes and values which URIs identify. This specification uses the @context property to map URIs required by specific credentials and presentations.
Verifiable credentials and presentations have different attributes and values which URIs identify.
This specification uses the @context property to map URIs required by specific credentials and presentations.
The example above shows the basic URI context (https://www.w3.org/2018/credentials/v1), a DID document, to establish that the conversation is about verifiable credentials. The second URI (https://www.w3.org/2018/credentials/examples/v1) states that the conversation is specifically about “examples”.
Basic concepts of verifiable credentials
When two software exchanges data, they need to use terminology that both of them understand. Let’s see how dialogue is created that technically has what is referred to as “the context of the conversation”.
Verifiable credentials and presentations have different attributes and values which URIs identify. This specification uses the @context property to map URIs required by specific credentials and presentations.
Verifiable credentials and presentations have different attributes and values which URIs identify.
This specification uses the @context property to map URIs required by specific credentials and presentations.
The example above shows the basic URI context (https://www.w3.org/2018/credentials/v1), a DID document, to establish that the conversation is about verifiable credentials. The second URI (https://www.w3.org/2018/credentials/examples/v1) states that the conversation is specifically about “examples”.
ID Property
To express affirmations towards a specific subject, a type of identifier is used that helps all the entities involved to express themselves about the same subject in a precise way.
We then introduce the property “id”. The latter therefore has the purpose of unequivocally referring to an object, a person, a product, or an organization. Using this property then allows the expression of statements regarding a specific topic of the verifiable credential.
If the id property is present:
- The id property MUST express an identifier that other entities will use to expose claims about a specification; characteristic identified by the identifier;
- The id property MUST NOT have more than one value;
- The value of the id property MUST be a URI.
The example below uses two types of identifiers:
- The first is for the verifiable credential and uses an HTTP URL;
- The second identifier is for the subject of the credential and uses a decentralized identifier, the DID.
Types Property
Software that processes the objects specified in the document displays the “type” property to determine whether the given credential is appropriate or not. The “type” property, in other words, identifies the object of the credential.
Verifiable credentials and submissions MUST have the “type” property. Any unspoken credential or presentation is unverifiable.
For example, the object of a credential with the “type” UniversityDegreeCredential communicates to the verifier that the object associated with the “subject of the credential” property contains the identifier of:
- The subject of the property id.
- Type of diploma in the “type” property
- Title of the diploma in the “name” property
ID Property
To express affirmations towards a specific subject, a type of identifier is used that helps all the entities involved to express themselves about the same subject in a precise way.
We then introduce the property “id”. The latter therefore has the purpose of unequivocally referring to an object, a person, a product, or an organization. Using this property then allows the expression of statements regarding a specific topic of the verifiable credential.
If the id property is present:
- The id property MUST express an identifier that other entities will use to expose claims about a specification; characteristic identified by the identifier;
- The id property MUST NOT have more than one value;
- The value of the id property MUST be a URI.
The example below uses two types of identifiers:
- The first is for the verifiable credential and uses an HTTP URL;
- The second identifier is for the subject of the credential and uses a decentralized identifier, the DID.
Types Property
Software that processes the objects specified in the document displays the “type” property to determine whether the given credential is appropriate or not. The “type” property, in other words, identifies the object of the credential.
Verifiable credentials and submissions MUST have the “type” property. Any unspoken credential or presentation is unverifiable.
For example, the object of a credential with the “type” UniversityDegreeCredential communicates to the verifier that the object associated with the “subject of the credential” property contains the identifier of:
- The subject of the property id.
- Type of diploma in the “type” property
- Title of the diploma in the “name” property
CredentialSubject Property
A verifiable credential contains statements regarding one or more subjects. This specification defines the credentialSubject property.
A verifiable credential MUST have the credentialSubject property. The value of this property is defined by a set of objects that contain one or more characteristics referring to the subject of the credential
In a credential, it is also possible to express information regarding several subjects, for example, husband and wife.
It is possible to express information related to multiple subjects in a verifiable credential. The example below specifies two subjects who are spouses. Note the use of array notation to associate multiple subjects with the credentialSubject property.
Issuer Property
The verifiable credential MUST have the “issuer” property.
The value of the “issuer” property MUST be a URI or object containing the id property. It is also recommended that the URI results in a document containing information about the issuer that can be used to verify the credential.
It remains possible to express additional information about the issuer by associating a “credentialSubject” property with the “issuer” property.
CredentialSubject Property
A verifiable credential contains statements regarding one or more subjects. This specification defines the credentialSubject property.
A verifiable credential MUST have the credentialSubject property. The value of this property is defined by a set of objects that contain one or more characteristics referring to the subject of the credential
In a credential, it is also possible to express information regarding several subjects, for example, husband and wife.
It is possible to express information related to multiple subjects in a verifiable credential. The example below specifies two subjects who are spouses. Note the use of array notation to associate multiple subjects with the credentialSubject property.
Issuer Property
The verifiable credential MUST have the “issuer” property.
The value of the “issuer” property MUST be a URI or object containing the id property. It is also recommended that the URI results in a document containing information about the issuer that can be used to verify the credential.
It remains possible to express additional information about the issuer by associating a “credentialSubject” property with the “issuer” property.
IssuanceDate Property
The issuanceDate property expresses the date and time when a credential becomes valid.
The credential MUST have the issuanceDate property. The value of this property must be a string of values that includes date and time. The time indicated in the string defines the closest moment in which the information associated with the subject of the credential becomes valid.
ExpirationDate Property
The expirationDate property defines the expiration date of the information contained in the credential. If present, it MUST be a string of values including date and time indicating the exact moment in which the credential ceases to be valid.
IssuanceDate Property
The issuanceDate property expresses the date and time when a credential becomes valid.
The credential MUST have the issuanceDate property. The value of this property must be a string of values that includes date and time. The time indicated in the string defines the closest moment in which the information associated with the subject of the credential becomes valid.
ExpirationDate Property
The expirationDate property defines the expiration date of the information contained in the credential. If present, it MUST be a string of values including date and time indicating the exact moment in which the credential ceases to be valid.
Proof Property
At least one validation mechanism, and the details needed to evaluate such evidence, MUST be expressed for a credential or presentation to make it verifiable.
Two different mechanisms are identified: one external and one integrated. The external mechanism represents the expression of this data model, like the JSON Web token. In the integrated mechanism, however, the proof is included in the data such as a Linked Data Signature.
One or more cryptographic proofs can be used to detect tampering and verify the authority of a credential. The specific method used MUST be specified using the “type” property.
If a digital signature is used for the validation mechanism, the “proof” property must contain the name of the signatory, a reference, and the date on which he signed.
CredentialStatus Property
The credentialStatus property defines the current state of a credential, such as the suspension or revocation status.
This property MUST contain:
- the id property, in URL form.
- the type property, which expresses the current state of the credential.
These values are expected to provide enough information to determine the current state. For example, the object may contain a link to an external document certifying the suspension or revocation of the credential.
Proof Property
At least one validation mechanism, and the details needed to evaluate such evidence, MUST be expressed for a credential or presentation to make it verifiable.
Two different mechanisms are identified: one external and one integrated. The external mechanism represents the expression of this data model, like the JSON Web token. In the integrated mechanism, however, the proof is included in the data such as a Linked Data Signature.
One or more cryptographic proofs can be used to detect tampering and verify the authority of a credential. The specific method used MUST be specified using the “type” property.
If a digital signature is used for the validation mechanism, the “proof” property must contain the name of the signatory, a reference, and the date on which he signed.
CredentialStatus Property
The credentialStatus property defines the current state of a credential, such as the suspension or revocation status.
This property MUST contain:
- the id property, in URL form.
- the type property, which expresses the current state of the credential.
These values are expected to provide enough information to determine the current state. For example, the object may contain a link to an external document certifying the suspension or revocation of the credential.
Verifible Presentation
Presentations can be used to combine and present credentials. They can also be “packaged” in such a way as to demonstrate the authority of the data. The data in the presentations are usually related to the same subject, but there is no limit to which subjects can be included. The aggregation of information deriving from different credentials is the most common use of presentations.
The verifiable presentation usually consists of the following properties:
- ID: The id property is optional and can be used to provide a unique identifier for the presentation.
- Type: the “type” property is required and expresses the type of presentation, for example, VerifiablePresentation.
- Verifiable Credential: If present, the value of this property MUST be constructed from one or more credentials, or from data derived from verifiable credentials in a cryptographically verifiable format.
- Owner: if present, the associated value is a URI referring to the entity that generated the presentation.
- Proof: if present, the value of this property ensures the verifiability of the presentation.
Verifible Presentation
Presentations can be used to combine and present credentials. They can also be “packaged” in such a way as to demonstrate the authority of the data. The data in the presentations are usually related to the same subject, but there is no limit to which subjects can be included. The aggregation of information deriving from different credentials is the most common use of presentations.
The verifiable presentation usually consists of the following properties:
- ID: The id property is optional and can be used to provide a unique identifier for the presentation.
- Type: the “type” property is required and expresses the type of presentation, for example, VerifiablePresentation.
- Verifiable Credential: If present, the value of this property MUST be constructed from one or more credentials, or from data derived from verifiable credentials in a cryptographically verifiable format.
- Owner: if present, the associated value is a URI referring to the entity that generated the presentation.
- Proof: if present, the value of this property ensures the verifiability of the presentation.
Advanced concepts of verifiable credentials
The most common sequence of actions done by actors in the authorization and/or identification process is designed as follows:
- The issuer issues the credential to the holder.
- The owner hands the credential to the verifier
- The verifier verifies the credential.
However, all types of credentials that can be used by the user on the network must meet certain criteria and have certain characteristics that guarantee interoperability, scalability, and security.
Let’s find out which ones:
Advanced concepts of verifiable credentials
The most common sequence of actions done by actors in the authorization and/or identification process is designed as follows:
- The issuer issues the credential to the holder.
- The owner hands the credential to the verifier
- The verifier verifies the credential.
However, all types of credentials that can be used by the user on the network must meet certain criteria and have certain characteristics that guarantee interoperability, scalability, and security.
Let’s find out which ones:
Extendibility Property
One of the objectives of the SSI model is to enable innovation without authorizations. This approach is commonly called the “open world assumption”, meaning any entity can make claims about any other entity.
Let’s assume a developer wants to extend the credential with two more pieces of information: an identification number and favorite food. The first thing to do is to create a JSON-LD context containing the two new terms, as shown below.
After this step, the developer publishes the document so that verifiers can verify the credential.
Assuming the JSON-LD context is published at https://example.com/contexts/mycontext.jsonld, we can now extend this example by including the context and adding the two new properties to the verifiable credential.
DisputeCredential Property
There are at least two cases to consider in which an entity wants to contest an issued credential:
- A subject disputes a statement made by the issuer. For example, the “address” property is incorrect.
- An entity disputes a potential false claim made by the issuer. For example, a third party, an “impostor”, states the identification number of an entity.
The issuing mechanism of a DisputeCredential is the same as that of a correct credential except for the identifier of the credentialSubject in the DisputeCredential property which is instead that of the disputed credential.
For example, if a credential with the identifier https://example.org/credentials/245 is disputed, the subject can issue a credential like the one in the image below and present it to the verifier along with the disputed credential.
Extendibility Property
One of the objectives of the SSI model is to enable innovation without authorizations. This approach is commonly called the “open world assumption”, meaning any entity can make claims about any other entity.
Let’s assume a developer wants to extend the credential with two more pieces of information: an identification number and favorite food. The first thing to do is to create a JSON-LD context containing the two new terms, as shown below.
After this step, the developer publishes the document so that verifiers can verify the credential.
Assuming the JSON-LD context is published at https://example.com/contexts/mycontext.jsonld, we can now extend this example by including the context and adding the two new properties to the verifiable credential.
DisputeCredential Property
There are at least two cases to consider in which an entity wants to contest an issued credential:
- A subject disputes a statement made by the issuer. For example, the “address” property is incorrect.
- An entity disputes a potential false claim made by the issuer. For example, a third party, an “impostor”, states the identification number of an entity.
The issuing mechanism of a DisputeCredential is the same as that of a correct credential except for the identifier of the credentialSubject in the DisputeCredential property which is instead that of the disputed credential.
For example, if a credential with the identifier https://example.org/credentials/245 is disputed, the subject can issue a credential like the one in the image below and present it to the verifier along with the disputed credential.
TermOfUse Property
The terms of use are used by the issuer or the holder to communicate the terms under which the credential or presentation was issued. The issuer includes the terms in the verifiable credential, while the holder places them within the verifiable presentation.
The value of this property informs the verifier which actions he is obliged to do, which ones are not allowed and which ones are allowed.
In the example below, the issuer prohibits the verifier from archiving the data provided.
RefreshService Property
It is useful to enable a manual or automatic refresh system of the expired credential. This specification defines the refreshService property, which enables the broadcaster to include a link for the refreshing service.
This service is mainly used when the credential has expired or when the issuer does not publish the information status.
TermOfUse Property
The terms of use are used by the issuer or the holder to communicate the terms under which the credential or presentation was issued. The issuer includes the terms in the verifiable credential, while the holder places them within the verifiable presentation.
The value of this property informs the verifier which actions he is obliged to do, which ones are not allowed and which ones are allowed.
In the example below, the issuer prohibits the verifier from archiving the data provided.
RefreshService Property
It is useful to enable a manual or automatic refresh system of the expired credential. This specification defines the refreshService property, which enables the broadcaster to include a link for the refreshing service.
This service is mainly used when the credential has expired or when the issuer does not publish the information status.
CredentialSchema Property
Schemas are useful for reinforcing a specific structure referring to a given collection of data.
There are at least two types of schemes:
- A data validation scheme is used to verify that the structure and content of a credential conform to the published scheme.
- A data encoding scheme is used to map the content of a credential into another format, such as the binary format used for zero-knowledge testing.
Using the credentialSchema property to allow validation of the JSON schema:
In the example, the issuer is specifying a credentialSchema, which indicates a [JSON-SCHEMA-2018] file that can be used by the verifier to determine if the verifiable credential is well constructed.
The use of the credentialSchema property allows zero-knowledge validation.
In the example below, the issuer specifies a credentialSchema indicating a zero-knowledge binary data format capable of transforming a data input into a format that can be used by the verifier to determine if the proof provided with the credential is valid.
CredentialSchema Property
Schemas are useful for reinforcing a specific structure referring to a given collection of data.
There are at least two types of schemes:
- A data validation scheme is used to verify that the structure and content of a credential conform to the published scheme.
- A data encoding scheme is used to map the content of a credential into another format, such as the binary format used for zero-knowledge testing.
Using the credentialSchema property to allow validation of the JSON schema:
In the example, the issuer is specifying a credentialSchema, which indicates a [JSON-SCHEMA-2018] file that can be used by the verifier to determine if the verifiable credential is well constructed.
The use of the credentialSchema property allows zero-knowledge validation.
In the example below, the issuer specifies a credentialSchema indicating a zero-knowledge binary data format capable of transforming a data input into a format that can be used by the verifier to determine if the proof provided with the credential is valid.
Zero-Knowledge Proof
A zero-knowledge test is a cryptographic method in which an entity can try to another entity to know a certain value without revealing the actual value. For example, it can prove that a university has issued a diploma to Tom without revealing the identity of the boy or any other information related to his person contained in the diploma itself.
The key credential holder abilities introduced by this mechanism are:
- Combine different credentials, issued by different issuers in a single presentation without revealing the credential or subject to the verifier.
- Carefully choose the information in the credential to be provided to the verifier.
- Produce a derived credential that has a format compatible with the scheme used by the verifier, without the need to involve the issuer.
To use zero-knowledge credentials, the issuer must issue a credential such that the holder is able to present the information to the verifier while maintaining a certain level of privacy.
To this end, two requirements are fundamental, the credential MUST contain:
- A credential model, using the credentialSchema property, which can be used by all entities to perform zero-knowledge operations.
A proof, using the proof property, that can be used to derive verifiable presentations must have information present in the original zero-knowledge credential. However, the submission must not reveal any information that the holder has no intention of disclosing.
Zero-Knowledge Proof
A zero-knowledge test is a cryptographic method in which an entity can try to another entity to know a certain value without revealing the actual value. For example, it can prove that a university has issued a diploma to Tom without revealing the identity of the boy or any other information related to his person contained in the diploma itself.
The key credential holder abilities introduced by this mechanism are:
- Combine different credentials, issued by different issuers in a single presentation without revealing the credential or subject to the verifier.
- Carefully choose the information in the credential to be provided to the verifier.
- Produce a derived credential that has a format compatible with the scheme used by the verifier, without the need to involve the issuer.
To use zero-knowledge credentials, the issuer must issue a credential such that the holder is able to present the information to the verifier while maintaining a certain level of privacy.
To this end, two requirements are fundamental, the credential MUST contain:
- A credential model, using the credentialSchema property, which can be used by all entities to perform zero-knowledge operations.
A proof, using the proof property, that can be used to derive verifiable presentations must have information present in the original zero-knowledge credential. However, the submission must not reveal any information that the holder has no intention of disclosing.
Security and privacy considerations
People have different levels of comfort regarding the information they are willing to provide and the information that can be gleaned from the data they provide.
Therefore there is no one-size-fits-all approach that works in all cases, privacy solutions differ for each case.
Security and privacy considerations
People have different levels of comfort regarding the information they are willing to provide and the information that can be gleaned from the data they provide.
Therefore there is no one-size-fits-all approach that works in all cases, privacy solutions differ for each case.
Information that identifies an individual
The data associated with the verifiable credential stored in the credential.credentialSubject field is susceptible to privacy violations when shared with verifiers. Personal data, such as the identity card number, address, and full name, can be easily used to determine, track and correlate an entity.
Identifier-Based Correlation
Credential subjects are identified using the credential.credentialSubject.id field. Identifiers used to identify a subject create a great correlation risk when they themselves are long-standing or used multiple times.
Since the anti-correlation properties are a fundamental requirement within the verifiable credential system, it is strongly recommended that the identifiers are:
- Linked to a single origin
- Do use a verifiable once (single use only)
- Not used entirely, or replaced by new and single-use tokens.
Information that identifies an individual
The data associated with the verifiable credential stored in the credential.credentialSubject field is susceptible to privacy violations when shared with verifiers. Personal data, such as the identity card number, address, and full name, can be easily used to determine, track and correlate an entity.
Identifier-Based Correlation
Credential subjects are identified using the credential.credentialSubject.id field. Identifiers used to identify a subject create a great correlation risk when they themselves are long-standing or used multiple times.
Since the anti-correlation properties are a fundamental requirement within the verifiable credential system, it is strongly recommended that the identifiers are:
- Linked to a single origin
- Do use a verifiable once (single use only)
- Not used entirely, or replaced by new and single-use tokens.
Signature-Based Correlation
Even in this case it is essential to maintain a high degree of anti-correlation, it is recommended that the signatures made to the credentials are regenerated each time using technologies such as zero-knowledge proofs, group signatures, etc.
Principle of data minimization
With verifiable credentials, minimizing data for issuers means limiting the content of a credential to the minimum required by its use by the verifier. For verifiers, this approach is identified in the limitation of the information required for a specific purpose or access to certain services.
Verifiers are urged to request only information that is absolutely necessary for a transaction.
This is important for at least two reasons:
- Reduce the responsibility of the verifier who handles sensitive information that he does not need.
- Increase the privacy of the individual simply by requesting information required for a specific transaction.
Signature-Based Correlation
Even in this case it is essential to maintain a high degree of anti-correlation, it is recommended that the signatures made to the credentials are regenerated each time using technologies such as zero-knowledge proofs, group signatures, etc.
Principle of data minimization
With verifiable credentials, minimizing data for issuers means limiting the content of a credential to the minimum required by its use by the verifier. For verifiers, this approach is identified in the limitation of the information required for a specific purpose or access to certain services.
Verifiers are urged to request only information that is absolutely necessary for a transaction.
This is important for at least two reasons:
- Reduce the responsibility of the verifier who handles sensitive information that he does not need.
- Increase the privacy of the individual simply by requesting information required for a specific transaction.
Bearer credentials
A bearer credential is an information that promotes privacy; an example could be a concert ticket, which entitles the holder to enjoy this resource without revealing sensitive information about the holder. They are often used in low-risk cases where sharing credentials does not imply economic or reputational losses. They must be carefully created to ensure that they cannot accidentally disclose more information than requested. The use of these credentials in several different sites creates a high risk of correlation.
Issuers of bearer credentials must ensure that the credentials bring privacy benefits, namely:
- Disposable, where possible
- They do not contain any personal information
- They are not excessively correlatable.
Owners must be warned by their software if their credential containing sensitive information is issued or requested, or if there is a risk of correlation when the subject combines two credentials of this type.
Validity checks
When processing verifiable credentials, verifiers must perform several validity checks:
- The owner’s professional qualification status.
- License renewal or revocation date.
- Requirements of an individual.
- The existence of a relationship between the owner and the entity with which he is trying to interact.
- Information about the location of the owner.
The validity verification process can result in a privacy violation; for this reason, verifiers must consider the possibility of rejecting credentials that could cause an invasion of privacy.
Bearer credentials
A bearer credential is an information that promotes privacy; an example could be a concert ticket, which entitles the holder to enjoy this resource without revealing sensitive information about the holder. They are often used in low-risk cases where sharing credentials does not imply economic or reputational losses. They must be carefully created to ensure that they cannot accidentally disclose more information than requested. The use of these credentials in several different sites creates a high risk of correlation.
Issuers of bearer credentials must ensure that the credentials bring privacy benefits, namely:
- Disposable, where possible
- They do not contain any personal information
- They are not excessively correlatable.
Owners must be warned by their software if their credential containing sensitive information is issued or requested, or if there is a risk of correlation when the subject combines two credentials of this type.
Validity checks
When processing verifiable credentials, verifiers must perform several validity checks:
- The owner’s professional qualification status.
- License renewal or revocation date.
- Requirements of an individual.
- The existence of a relationship between the owner and the entity with which he is trying to interact.
- Information about the location of the owner.
The validity verification process can result in a privacy violation; for this reason, verifiers must consider the possibility of rejecting credentials that could cause an invasion of privacy.
Sharing information with the wrong counterpart
When the possessor decides to share information with the verifier, it may occur that the latter acts in bad faith and requests information that can be used to harm the possessor.
Issuers should try to minimize information as much as possible so as not to make it catastrophic if they share their information with the wrong counterparty. For example, instead of sharing the bank account number to enable the view of the balance, it is possible to provide a token that authorizes the verifier to find that the balance exceeds a certain amount.
Prefering one-time credentials
The use of disposable credentials provides several advantages.
The first is for verifiers who can ensure that the data provided is “fresh”. The second is for the owners, who can be sure that since there are no old identifiers, the credential cannot be used to track or correlate them online. Finally, there is no possibility of the data being stolen, making the entire system safe.
Sharing information with the wrong counterpart
When the possessor decides to share information with the verifier, it may occur that the latter acts in bad faith and requests information that can be used to harm the possessor.
Issuers should try to minimize information as much as possible so as not to make it catastrophic if they share their information with the wrong counterparty. For example, instead of sharing the bank account number to enable the view of the balance, it is possible to provide a token that authorizes the verifier to find that the balance exceeds a certain amount.
Prefering one-time credentials
The use of disposable credentials provides several advantages.
The first is for verifiers who can ensure that the data provided is “fresh”. The second is for the owners, who can be sure that since there are no old identifiers, the credential cannot be used to track or correlate them online. Finally, there is no possibility of the data being stolen, making the entire system safe.
Examples of privacy loss
Despite numerous efforts to ensure data protection, the use of verifiable credentials can lead to the loss of privacy. This can happen when:
- The same credential is presented to the same verifier more than once. The verifier can infer that the individual is the same.
- The same credential is presented to several verifiers, but these verifiers cooperate. They can then assume that the person who presented the credential is the same.
- The identifier of a subject refers to the same subject in multiple presentations or to multiple verifiers. Even when various credentials are presented, but the identifier is the same, the verifier can infer that the owner of the credential is the same.
- The information contained in a credential can be used to identify an individual. The verifier can relate the owner to an existing profile using this information.
In part, these risks can be mitigated:
- Use a universal identifier for any subject’s credential and not reusing the same credential.
- Build revocation APIs that do not depend on the credential id.
- Avoid the association of personal information with any long-standing identifier.
Examples of privacy loss
Despite numerous efforts to ensure data protection, the use of verifiable credentials can lead to the loss of privacy. This can happen when:
- The same credential is presented to the same verifier more than once. The verifier can infer that the individual is the same.
- The same credential is presented to several verifiers, but these verifiers cooperate. They can then assume that the person who presented the credential is the same.
- The identifier of a subject refers to the same subject in multiple presentations or to multiple verifiers. Even when various credentials are presented, but the identifier is the same, the verifier can infer that the owner of the credential is the same.
- The information contained in a credential can be used to identify an individual. The verifier can relate the owner to an existing profile using this information.
In part, these risks can be mitigated:
- Use a universal identifier for any subject’s credential and not reusing the same credential.
- Build revocation APIs that do not depend on the credential id.
- Avoid the association of personal information with any long-standing identifier.
Security and privacy considerations
There are several security considerations that issuers, holders, and verifiers should be aware of when processing data. Ignoring or not understanding the implications can lead to numerous vulnerabilities.
The security in the protocols must remain at the center of the first considerations of efficiency: the actors must have the same incentives and the root of trust must be cryptographically secure and public while guaranteeing privacy.
Other security considerations:
Security and privacy considerations
There are several security considerations that issuers, holders, and verifiers should be aware of when processing data. Ignoring or not understanding the implications can lead to numerous vulnerabilities.
The security in the protocols must remain at the center of the first considerations of efficiency: the actors must have the same incentives and the root of trust must be cryptographically secure and public while guaranteeing privacy.
Other security considerations:
Cryptography rooms and libraries
Some aspects of the model described can be protected through the use of cryptography. It is important for actors to understand the meaning of the rooms and cryptographic libraries used to create and process credentials and presentations. Implementing and overhauling cryptographic systems requires a high level of experience.
These libraries have a limited lifespan and can be subject to attack or technological advancements. The quality control systems must ensure mechanisms that are able to update these rooms if they have expired and invalidate the credentials contained by replacing them with new ones. Monitoring is important to ensure the validity of these credential processing systems over time.
Protection of the integrity of the content
Verifiable credentials often contain a URL for data that remains outside the credential itself. Linked content, such as images, JSON-LD Contexts, and other data, is often not protected from tampering as it remains outside the protection of verifiable credential proof.
The authors of these documents, who want to ensure the protection of the information contained therein, must use URL schemes that ensure integrity. Two examples of schemes are [HASHLINK] and [IPFS].
Cryptography rooms and libraries
Some aspects of the model described can be protected through the use of cryptography. It is important for actors to understand the meaning of the rooms and cryptographic libraries used to create and process credentials and presentations. Implementing and overhauling cryptographic systems requires a high level of experience.
These libraries have a limited lifespan and can be subject to attack or technological advancements. The quality control systems must ensure mechanisms that are able to update these rooms if they have expired and invalidate the credentials contained by replacing them with new ones. Monitoring is important to ensure the validity of these credential processing systems over time.
Protection of the integrity of the content
Verifiable credentials often contain a URL for data that remains outside the credential itself. Linked content, such as images, JSON-LD Contexts, and other data, is often not protected from tampering as it remains outside the protection of verifiable credential proof.
The authors of these documents, who want to ensure the protection of the information contained therein, must use URL schemes that ensure integrity. Two examples of schemes are [HASHLINK] and [IPFS].
Unsigned Affirmations
These types of credentials are not verifiable as the authenticity is unknown or cannot be verified anyway.
Check the dynamic information
Expiration dates prior to the end of the validity period expressed by the credential create a problem for the owner and the verifier.
It is therefore important to establish validity periods appropriate to the use case and to the life cycle of the information contained in the verifiable credential.
Unsigned Affirmations
These types of credentials are not verifiable as the authenticity is unknown or cannot be verified anyway.
Check the dynamic information
Expiration dates prior to the end of the validity period expressed by the credential create a problem for the owner and the verifier.
It is therefore important to establish validity periods appropriate to the use case and to the life cycle of the information contained in the verifiable credential.
Device theft or impersonation
When credentials are stored on a device and the device is stolen or lost, it is possible for someone to log into the system using the victim’s verifiable credentials.
The ways to avoid this risk are:
- Enable passwords, pins, and biometric protection devices on the device.
- Enable passwords, biometrics, or multi-factor authentication for the wallet.
- Enable passwords, biometrics, or multi-factor authentication when using cryptographic keys.
- Use a separate signature device
- All or some of the above indications.
Device theft or impersonation
When credentials are stored on a device and the device is stolen or lost, it is possible for someone to log into the system using the victim’s verifiable credentials.
The ways to avoid this risk are:
- Enable passwords, pins, and biometric protection devices on the device.
- Enable passwords, biometrics, or multi-factor authentication for the wallet.
- Enable passwords, biometrics, or multi-factor authentication when using cryptographic keys.
- Use a separate signature device
- All or some of the above indications.
The European and Community market and the regulation on digital identity
The eIDAS Regulation (electronic IDentification Authentication and Signature) – EU Regulation n ° 910/2014 on digital identity – aims to provide a regulatory basis on digital identity at EU level for trust services and electronic identification means of member states . Thanks to the FICEP project, “Italian cross-border server”, with the creation of a national eIDAS node it is possible for Italian citizens to access the online services of other EU countries using the credentials obtained in the public SPID digital identity system, as well as with the Card of Electronic Identity (CIE).
The European Commission is currently evaluating this regulatory framework and conducted an open consultation from 24 July to 2 October 2020. The aim of the consultation was to gather feedback on the drivers and obstacles to the development and deployment of trust services and eID in Europe. The study also considered the impact of options for building an EU digital identity.
The European and Community market and the regulation on digital identity
The eIDAS Regulation (electronic IDentification Authentication and Signature) – EU Regulation n ° 910/2014 on digital identity – aims to provide a regulatory basis on digital identity at EU level for trust services and electronic identification means of member states . Thanks to the FICEP project, “Italian cross-border server”, with the creation of a national eIDAS node it is possible for Italian citizens to access the online services of other EU countries using the credentials obtained in the public SPID digital identity system, as well as with the Card of Electronic Identity (CIE).
The European Commission is currently evaluating this regulatory framework and conducted an open consultation from 24 July to 2 October 2020. The aim of the consultation was to gather feedback on the drivers and obstacles to the development and deployment of trust services and eID in Europe. The study also considered the impact of options for building an EU digital identity.
Eidas Bridge and the role of the Trust Service Provider
The new proposal for digital identity regulation is intended to identify the limitations present in eIDAS, improving the effectiveness of the framework and extending the benefits to the private sector.
The eIDAS SSI bridge assists the issuer in the process of signing a verifiable credential, and the verifier, in the verification process, helping him to identify the issuer (legal person) behind his DID. By “crossing” the eIDAS Bridge, the verifiable credential is securely tested.
The European Self-Sovereign Identity (SSI) framework (ESSIF), by defining the necessary specifications, will allow citizens to create, control and use their digital identity. ESSIF aims to be compliant with the GDPR and the lines defined by eIDAS to ensure the benefits deriving from the existence of this new framework. ESSIF is part of the European blockchain service infrastructure (EBSI). EBSI is a joint initiative of the European Commission and the European Blockchain Partnership (EBP) created to provide public services to European citizens using blockchain technology.
Trust Service Providers are the entities that have the task of guaranteeing first of all the certainty and integrity of identification for the electronic signature, for authentication, and for the management of digital certificates. eIDAS requires the European Union to create a special trust list for all “qualified” TSP service providers. Within the SSI context, Trusted Service Providers have a new role and function, namely that of Trusted Issuers.
Eidas Bridge and the role of the Trust Service Provider
The new proposal for digital identity regulation is intended to identify the limitations present in eIDAS, improving the effectiveness of the framework and extending the benefits to the private sector.
The eIDAS SSI bridge assists the issuer in the process of signing a verifiable credential, and the verifier, in the verification process, helping him to identify the issuer (legal person) behind his DID. By “crossing” the eIDAS Bridge, the verifiable credential is securely tested.
The European Self-Sovereign Identity (SSI) framework (ESSIF), by defining the necessary specifications, will allow citizens to create, control and use their digital identity. ESSIF aims to be compliant with the GDPR and the lines defined by eIDAS to ensure the benefits deriving from the existence of this new framework. ESSIF is part of the European blockchain service infrastructure (EBSI). EBSI is a joint initiative of the European Commission and the European Blockchain Partnership (EBP) created to provide public services to European citizens using blockchain technology.
Trust Service Providers are the entities that have the task of guaranteeing first of all the certainty and integrity of identification for the electronic signature, for authentication, and for the management of digital certificates. eIDAS requires the European Union to create a special trust list for all “qualified” TSP service providers. Within the SSI context, Trusted Service Providers have a new role and function, namely that of Trusted Issuers.
SSI with GPPR: Selective Disclosure and Data Minimization
A further element that enhances Self-Sovereign Identity as a new digital identity model is its relationship with the GDPR. In the 10 principles on which this new framework is based, number 9 is the concept of “data minimization”, which allows what is called “selective disclosure”: to show only the information requested by the SP.
Within the GDPR, we find this principle in several articles such as:
- Art. 5 “Principles relating to the processing of personal data”,
- Art. 47 “Binding corporate rules”,
- Art. 25 “Data protection by design and by default”,
- Art 89 “Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes”.
SSI with GPPR: Selective Disclosure and Data Minimization
A further element that enhances Self-Sovereign Identity as a new digital identity model is its relationship with the GDPR. In the 10 principles on which this new framework is based, number 9 is the concept of “data minimization”, which allows what is called “selective disclosure”: to show only the information requested by the SP.
Within the GDPR, we find this principle in several articles such as:
- Art. 5 “Principles relating to the processing of personal data”,
- Art. 47 “Binding corporate rules”,
- Art. 25 “Data protection by design and by default”,
- Art 89 “Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes”.
Case Studies: Citizenship by descent
Sam wants to claim his US citizenship as his mom is American. Sam has a digital certificate from Kenya, the country where he was born while his mother was a UN soldier. He also has a digital version of his mom’s US passport. As his mom’s surname changed following the marriage, Sam also presents the marriage document with the maiden and married surnames. Sam is applying to the Secretariat of State.
Scenario:
Sam’s mom has forwarded the certificate, documents, and passport to her son as verifiable credentials, and he creates a digital presentation that includes these credentials and affirms the relationship. He then visits the Secretariat of State website, creates an account, begins the procedure, and uploads his verifiable submission as proof. At the end of the trial, Sam gets the traditional passport and a digital version.
List of Verifiable Credentials:
- birth certificate: establishes the relationship with the mother with the maiden name
- marriage document: verifies the change of the mother’s surname
- mother’s passport: affirms the mother’s citizenship
- Sam’s passport: states that Sam is the child on the birth certificate
Verifiable Presentation:
A verifiable submission must include these credentials, add a name, photo, and date of birth along with other statements:
- Sam is the child indicated by the certificate.
- The mother on the birth certificate, the person on the passport, and the bride on the marriage document are the same woman.
- Sam is legally responsible for his own citizenship rights claims. Sam is legally liable for his claim to the rights of citizenship. The State Department verifies the credentials provided by Sam, correlating the data with those already in possession.
Threats and Response to an identification process
Threats: Terrorism/identity theft.
A disingenuous person can pretend to be Sam to get a passport. Obviously, he must be able to collect all the documents required to complete the passport-obtaining process.
- Response: identification based on the presentation and other data that go far beyond what is contained in the presentation itself and the information provided previously.
- Response: identity confirmation based on the content of the statements provided, potentially with integrated data; such as data not currently contained in the passport, birth certificates, and marriage documents. For example, a biometric template could be included in the birth certificate and can therefore be used concretely to assert your identity when submitting your presentation.
Threat: Exposure of private information.
By storing potentially tamper-proof information and sending it out of your network, you face a potential attack by cybercriminals.
- Response: Encrypt the data
- Response: Encrypt the statements for each verifier.
- Response: Send the statements in blind copies to each verifier.
- Response: Encrypt the presentation for each verifier. In this way, no broadcasters will be involved.
Case Studies: Citizenship by descent
Sam wants to claim his US citizenship as his mom is American. Sam has a digital certificate from Kenya, the country where he was born while his mother was a UN soldier. He also has a digital version of his mom’s US passport. As his mom’s surname changed following the marriage, Sam also presents the marriage document with the maiden and married surnames. Sam is applying to the Secretariat of State.
Scenario:
Sam’s mom has forwarded the certificate, documents, and passport to her son as verifiable credentials, and he creates a digital presentation that includes these credentials and affirms the relationship. He then visits the Secretariat of State website, creates an account, begins the procedure, and uploads his verifiable submission as proof. At the end of the trial, Sam gets the traditional passport and a digital version.
List of Verifiable Credentials:
- birth certificate: establishes the relationship with the mother with the maiden name
- marriage document: verifies the change of the mother’s surname
- mother’s passport: affirms the mother’s citizenship
- Sam’s passport: states that Sam is the child on the birth certificate
Verifiable Presentation:
A verifiable submission must include these credentials, add a name, photo, and date of birth along with other statements:
- Sam is the child indicated by the certificate.
- The mother on the birth certificate, the person on the passport, and the bride on the marriage document are the same woman.
- Sam is legally responsible for his own citizenship rights claims. Sam is legally liable for his claim to the rights of citizenship. The State Department verifies the credentials provided by Sam, correlating the data with those already in possession.
Threats and Response to an identification process
Threats: Terrorism/identity theft.
A disingenuous person can pretend to be Sam to get a passport. Obviously, he must be able to collect all the documents required to complete the passport-obtaining process.
- Response: identification based on the presentation and other data that go far beyond what is contained in the presentation itself and the information provided previously.
- Response: identity confirmation based on the content of the statements provided, potentially with integrated data; such as data not currently contained in the passport, birth certificates, and marriage documents. For example, a biometric template could be included in the birth certificate and can therefore be used concretely to assert your identity when submitting your presentation.
Threat: Exposure of private information.
By storing potentially tamper-proof information and sending it out of your network, you face a potential attack by cybercriminals.
- Response: Encrypt the data
- Response: Encrypt the statements for each verifier.
- Response: Send the statements in blind copies to each verifier.
- Response: Encrypt the presentation for each verifier. In this way, no broadcasters will be involved.