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:
- 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;
- Improve the data signing system to provide greater security for users;
- 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:
rootHash
: the rootHash of the VC
holder
:the DidUrl of the holder, which usually started with 'zk::did::'
issuanceDate
: the issuance time of this VC, represented in timestamp
expirationDate
: the expiration time of this VC, represented in timestamp
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.