Based on the different transmission channels and encrypted methods, there are several usage scenarios as follows:
End-to-end encryption code dependency: tweet-nacl
Implementation: To accomplish the end-to-end encryption, A needs the following keys :
The above 2 keys play key roles for Public-key authenticated encryption. After encryption and transmission, B will receive the ciphertext and can decrypt it through
Application Scenarios: For scenarios with high privacy protection requirements.
<aside> 💡 VP is encrypted during transmission. Only the receiver can decrypt the ciphertext. Even if the message is intercepted or eavesdropped, the eavesdropper cannot decrypt the ciphertext.
</aside>
The VP is transmitted without encryption, but still via Credential Platform
Implementation: Transmit the VP directly through plaintext without encrypting it. Applicable scenarios: The VP of Public VC.
<aside> 💡 Normally, if the transmission process is not encrypted, there will be a risk of eavesdropping and interception. However, for the VP of Public VC, even if it got intercepted, there will be no risk for the Holder, for the reason that the data itself is publicly available.
</aside>
When users use 'Login with credential digest' or 'Login with selective credential content' on the website, the zkID wallet will be invoked. Once users approve the operation, VPs will be generated automatically.
Implementation: The website calls the did_requestCredentialContent(...) and did_requestCredentialDigest(..) functions within zkID Wallet to request the user's VP.
Applicable scenarios: zkID Login, where the website invokes the zkID wallet to help users to present the specified VP for their identification verification.
<aside> 💡 e.g., When a website needs a user to prove that he/she has a certain type of VC or selectively disclose some VC fields, it will request the above interface of the zkID wallet, through which the user's VP can be obtained.
</aside>