Managing and Using Identities in Concordium

The Concordium Blockchain has an identity layer built into the core protocols. This means that before an individual or entity can send transactions to the Concordium Blockchain their real-world identity must be verified by an Identity Provider. The identity layer allows sufficiently many (as defined by a threshold) pre-defined third parties to identify account holders in case of an official investigation. Except for this users can create accounts and use them privately and these accounts can neither be linked to the account holder nor to each other.

In this note, we will not look further at anonymity revocation but rather dive deeper into the wider use of the identity layer and describe how the user can manage and control private information within the identity layer. Furthermore, we will discuss how this is supported by the upcoming Concordium Identity Libraries.

Setting the Scene

Not considering anonymity revocation, the overall requirement to the identity layer is that it must ensure that all personal information is correct and allow the user to control their information. Let us take a brief look at each of these requirements.

By correctness, we mean that the personal data has been validated by an entity which we will call Identity Provider. Relying parties trusting that the Identity Provider validates personal information correctly can then act on that information. The system must support several identity providers as different identity providers may be needed for different jurisdictions and there can be additional objective and subjective reasons for trusting an Identity Provider. A relying party may in particular trust that a specific Identity Provider does the validation to a sufficient degree for some applications but not for others. The Identity Provider and the overall solution must therefore provide enough information to enable relying parties to make this decision.

The other part of the solution is that the user must be in control of which personal data is revealed in a particular situation. While many existing ID solutions force users to present much more data than required for a specific purpose, time is running out for such solutions as users should only present the data necessary for the purpose. The typical example is that if a user should be of a certain age, it is sufficient to show the age or, even better, prove to be older than required without revealing the age. There is no need to disclose other personal information.

In a blockchain solution such as Concordium Blockchain, another important aspect to handle is where the data is published. Let us look at two possibilities. The first one that comes to mind is to publish personal data on the blockchain. There can be good reasons for this as some blockchain applications may need this (again, a smart contract may require that persons using it are beyond a certain age). A good identity solution must therefore allow that personal data can be accessible on the blockchain. However, as data on the blockchain cannot be deleted one should in general be careful about and simply avoid publishing personal data here.

Therefore, to get the full benefit of the identity layer it must also support the use of identities and personal data off-chain. Here users show or prove properties as part of specific applications without revealing personal data on the chain. The relying party can use this information as part of the business application and relate this information to the transactions on the blockchain (e.g. in smart contracts) that relate to the business application. In such cases it will be the responsibility of the relying party to protect the received information according to laws and regulations — e.g. according to the provisions of GDPR.

Examples

1. Say Alice wants to transfer 5 GTU to Bob. Upon receiving Bob’s account Alice may want to be assured that the account really belongs to Bob. Alice, therefore, asks Bob to prove to her that the account matches his identity. Bob should be able to do so without revealing this fact on the chain as he only wants Alice to know that he holds the account.
2. A marketplace (e.g., for buying NFTs or streaming movies) may require that users must be older than 21 years. As part of the marketplace, the user must therefore show his/her age or prove to be old enough before using the marketplace. Note that this must be done in such a way that the marketplace can relate this proof to the blockchain transactions related to the marketplace.

The Concordium ID Layer

We will now take a look at the ID layer in the Concordium Blockchain, which is based on the principles described by Damgaard et al. The three central concepts are user identity certificates, accounts and credentials. These are described in detail below but very briefly they are related as follows.

In order to submit any transaction to the blockchain, a user must have an account. All transactions from the user are authorized using private/public keys associated with the account through a credential, which also contains the user’s personal information. A multi-user account has several credentials associated as well as a threshold defining the number of signatures required for submitting a transaction. Each credential is based on user information contained in a user identity certificate that has been issued by an Identity Provider during an initial identification process, where the personal data is also validated.

In the following, we will describe each of these concepts in more detail and explain how the user can manage his identity.

User Identity Certificate

Before an individual or entity can use the Concordium Platform, their real-world identity must be verified and recorded by an Identity Provider. One result of this validation is that the Identity Provider issues a user identity certificate to the user.

The user identity certificate includes attributes such as name, age and nationality. When the Identity Provider has validated the attributes it issues a user identity certificate, which is basically the Identity Provider’s signature over some cryptographic keys of the user and the validated personal attributes. Unlike usual public key certificates such as X.509 certificates, the user identity certificate is private to the user. In particular, it is not submitted to the chain. Note that the Identity Provider also stores some information, but this is only used for a possible, subsequent investigation of the user’s activities (i.e. anonymity revocation). The Identity Provider is not involved in any subsequent use of the user identity certificate. The user identity certificate is signed using the Pointcheval-Sanders signature scheme.

Accounts and Credentials

Accounts on the Concordium Blockchain contain information needed to use the account such as account number and other “administrative” data. But in relation to the identity layer, the interesting part is the credential associated with the account. As mentioned, in the general case multiple credentials can be associated with the account and a threshold in the administrative account information defines how many of these must be involved when signing transactions on the account. However, to ease the reading we will just consider the case of one credential associated with the account.

Among other data the credential contains

• Public key needed to validate signatures from that credential (the user has the corresponding private key)
• Reference to Identity Provider that has issued the user identity certificate underlying this credential. This allows relying parties to decide whether the information in the credential can be trusted in a particular situation based on the jurisdiction and the policies of the Identity Provider.
• User attributes that have been validated by the Identity Provider. User attributes may be revealed on the chain or remain hidden in privacy-protecting commitments. In any case, when creating the credential the user proves that all attributes have been validated by the Identity Provider by means of a zero-knowledge proof, which proves that the user has a user identity certificate from the Identity Provider containing these attributes. This zero-knowledge proof does not reveal the user identity certificate and can therefore be sent to the chain when creating the credential.

An essential property of this construction is that anyone knowing the public key of the Identity Provider can verify the zero-knowledge proof and hence be assured that all attributes have been approved by the Identity Provider. Furthermore, the user can select which attributes to reveal on the chain and which attributes to keep secret. At a high level the user can therefore manage his identity by creating different accounts with different credentials. The identity layer ensures that such accounts and credentials can be created from the same user identity certificate and that they cannot be linked to each other.

Example

If a user sometimes has to reveal his/her nationality, the user can create one account with no revealed attributes for general usage and another account revealing the nationality. In applications requiring the nationality to be known the user will then use the latter account and otherwise the former.

Now, while handling different credentials by creating different accounts and credentials gives the user a good level of control over his personal data, this is not sufficient. One reason is that it may be cumbersome to manage too many accounts and another is that, as mentioned previously, one should generally refrain from publishing personal data on the blockchain.

We will therefore now take a closer look at the granularity of user control over personal data in existing accounts and the ability to reveal personal information in off-chain applications.

Controlling Personal Information

Recall that the user has three types of private information in relation to the user identity certificate and the credential.

The private information in the user identity certificate basically allows the user to create new credentials corresponding to new expressions of his identity. On the blockchain this is used when creating new accounts but it may be applied in other applications not related to the blockchain as well.

There are two types of secret information related to a credential: the private keys used to authorize actions (i.e., to sign transactions) and the private information for revealing hidden attributes (i.e. for opening commitments). These two types have different security requirements.

Let us first look at the private credential key for signing transactions. Once the credential is associated with an account this key is used to approve all transactions on that account. This key must therefore be protected very carefully to protect the assets on the account and to ensure that other persons cannot impersonate the account holder.

The other type, the private information for revealing hidden attributes, is not sensitive in relation to protecting such assets but obviously important for privacy reasons.

The Concordium Identity Libraries described in the next section will provide functionality for creating and managing credentials. An important aspect of this is that the libraries only need the secret keys/data that protect hidden attributes. Importantly, the libraries do not need the transaction signing key and therefore it will be possible to make applications for managing and using personal attributes related to existing accounts on the chain without exposing the corresponding transaction signing key to the libraries.

Identity Libraries

Ideally, identities are managed by the preferred wallet of the user. However, in light of the bespoke work to be done in order to support the Concordium Identity Layer in existing wallets, Concordium plans to support the development of an Identity Wallet that can help a user to create and manage identities and credentials initially. The source code for Identity Wallet will be open to ease subsequent integration in existing wallets.

In order to use identities and exploit the flexibility of credentials, Concordium will also release the Concordium Identity Library that allows easy integration of the identity solution in applications.

As mentioned above three types of secrets are involved in the identity layer:

• The user identity certificate which is needed to create new credentials
• The keys used to sign transactions
• Secret information for revealing and proving properties of hidden attributes in a credential

The Concordium Identity Library will only use the first and last of these and provide functionality covering the following areas.

Create Credential

Using the user identity certificate to create a new credential. Attributes from the user identity certificate may either be revealed or hidden in the credential, but just as when creating accounts on the blockchain, everyone knowing the public key of the Identity Provider can verify that attributes have been approved by the Identity Provider. The credential will contain a signature key that can be used in applications not involving the blockchain.

Verify Credential

Using the public key of the Identity Provider to verify that a credential is correctly constructed from an identity user certificate issued by that Identity Provider. As a consequence, this also provides assurance that the Identity Provider has approved all attributes. The public key can be retrieved from the blockchain using a reference in the credential.

Open Attribute

The value of a hidden attribute is disclosed using the corresponding private information.

Verify Attribute

Verifying that a hidden attribute in a credential has been correctly opened. This functionality will be available both for use in smart contracts and in applications off-chain.

Prove Attribute

When opening an attribute anyone can get and validate its value. Thus it is “disclosed to the whole world”. Using the “prove attribute”-functionality, the owner can prove in zero-knowledge to another party that the attribute has a particular value. This will convince the other party about its value, but this other party cannot use the proof at a later point in time to convince third parties. In order to achieve this some interaction with the verifier will be part of the proof.

Verify Proof of Attribute

Functionality allowing relying parties to participate in and verify proof of an attribute.

Prove Attribute Property

Initially, this functionality will provide “range proofs” for attributes with a well-defined ordering. The best example is to prove that “age > 21”. If needed more complex properties may be added later.

Verify Attribute Property

This is for verifying proofs of attribute properties. This functionality will be available both for use in smart contracts and in applications off-chain.

Conclusion

We have described how a user can manage personal data by creating different accounts and how the user can get a flexible control over the personal data contained in account credentials.

Let us return to the two examples from the beginning and see how they are enabled by Concordium Identity Libraries.

The first example, where Alice wants to be assured of the identity of Bob before transferring 5 GTU to Bob can be handled as follows. Using the “Open Attribute” functionality Bob can disclose his name attribute to Alice. Using the “Verify Attribute” functionality Alice can verify that the hidden name attribute in the credential of the account that she received from Bob is opened correctly. Now, this allows Alice to reveal Bob’s name to everyone. This may be ok if Bob trusts that Alice will not do so. Otherwise, Bob should use the “Prove Attribute” functionality to prove his name to Alice.

In the marketplace example, the buyer of an NFT or movie can be asked to prove that his age is above 21. This proof can be generated using the “Prove Attribute Property” and sent with the transaction to the smart contract managing the marketplace. The smart contract will then only transfer ownership if the proof succeeds. Alternatively, Bob can add this proof to his account credential, so that every time he uses the account, it can be verified that it belongs to a person above 21.

While these examples only scratch the surface of the possibilities, we believe that the Concordium Identity Layer will be attractive in many applications, as it enables the user to reveal only the necessary personal data needed for a particular application while still giving the relying party high confidence in the correctness of the information about the user.

Get started with Concordium: https://developer.concordium.software/

Github: https://github.com/Concordium/

Discord: https://discord.gg/MZyHgfw

Twitter: https://twitter.com/ConcordiumNet

Telegram: https://t.me/concordium_official

Reddit: https://www.reddit.com/r/Concordium_Official

Facebook: https://www.facebook.com/ConcordiumNet/

Learn more: https://concordium.com

Concordium Blockchain Research Center Aarhus (COBRA):https://cs.au.dk/research/centers/concordium/