Upgrade: VC version upgrade, PublicVC involved

[jonathanxuu]

Abstract:

Based on the existing VC, we are happy to prepare an upgrade (from VC version 0 to version 1) that will introduce 'PublicVC', which is simpler and more suitable for public information presentation. PublicVC still retains the most important MerkleTree structure and hash method to ensure the security of attestation and presentation.

This release plans to:

1. Offer PublicVC. For entities to store data which can be made public. This kind of VC is more concise and the data size is much smaller;
2. Improve the data signing system to provide greater security for users;
3. Improve parts of VC structure to expand application scenarios and achieve higher security;

Upgrade1: Public VC

Background

In terms of usage scenarios, there are many occasions that need to disclose VC, we call the VC that can be made public/published in public storage as 'PublicVC'.

As a result, structures such as nonceMap for privacy are redundant in such public scenario. If stored on-chain, nonceMap will also take up additional storage overhead. So we offer PublicVC which discards nonceMap to save such overhead.

Users should give priority to using PublicVC when dealing with publicly available data, which can greatly reduce the storage space and facilitate the transfer of credentials.

Solution

Compared to the VC before, PublicVC doesn't have the nonceMap structure(The only difference).

Entity that use PublicVC doesn't need to use 'zero-knowledge proof' (because all data is publicly available), so there's no need of using nonceMap in such PublicVC.

You can think of nonceMap as a protection for data privacy, once the data can be made public, then there's no need for the structure anymore.

Upgrade2: Data Signing

Background

Currently, there is no review mechanism(censorship) for the message to be signed. If the signed message is a malicious act (such as forging a transaction, etc.), then the users may lose their assets.

Solution(WIP)

In order to standardize the signature system, once users need to sign messages that is received from others, a reliable mechanism should be adopted to ensure the security of the signature. Here, we are planning to use standard like EIP-191 or other.

The final solution is still WIP, need another issue to track the Data Signing Solution.

Upgrade3: DigestHash Calculation

Background

For some issuance-time-sensitive VC(for a permanent VC, what we care is when the VC is issued rather than its expiration time, because some VC never expire), we will include issuanceDate into DigestHash's calculation to prevent faking of issuance time.

Solution

Add issuanceDate into the calculation of DigestHash, so the DigestHash calculation involves:

1. rootHash: the rootHash of the VC
2. holder:the DidUrl of the holder, which usually started with 'zk::did::'
3. issuanceDate: the issuance time of this VC, represented in timestamp
4. expirationDate: the expiration time of this VC, represented in timestamp
5. ctype: the ctype of the VC

export function calcDigest(
  payload: DigestPayload,
  hashType: HashType = DEFAULT_DIGEST_HASH_TYPE
): DigestResult {
  const encoded = u8aConcat(
    payload.rootHash,
    stringToU8a(payload.holder),
    numberToU8a(payload.issuanceDate),
    numberToU8a(payload.expirationDate),
    payload.ctype
  );

Due to the upgrade above, we plan to update VC version 0 to version 1.

Perhaps, there are some important updates not mentioned here. But we'll keep tracking. If you have any comments and suggestions, please feel free to make them.