After our big event hosted with Polkadot Decoded 2023 in Copenhagen, Litentry mingled around with participants at the booth and some interesting questions came about. We have taken the opportunity to collect questions, answer and give some insight on these topics.
This article unveils some valid information and provides you with a better explanation of some of these questions and topics, along with some terminology used within Litentry and the IDHub explained. Sit back and relax while enjoying some fun facts! Let’s get educated. 😉
Good questions asked by participants:
Where is the data stored?
Most data are stored locally in the user’s device. The accounts relationship (IDGraph) is stored in the Trusted Execution Environment, which is only accessible when the private key of the identity owner is included in the request to open it. Currently, all the SGX nodes are under the control of Litentry, which minimizes the risk of attacks by malicious nodes.
Where is VC stored?
They are stored in the VC registry, an on-chain and public storage on the Verifiable Credential Management Pallet (VCMP) that maintains the VC Index <> VC Hash so that credentials can be verified. It contains only a map from the VC index and VC hash which is used to check the validity of the VC content. When a VC is generated, the Parachain VCMP extrinsic vc_issued is called (one of the parameters is the generated VC, encrypted by the user’s shielding key; and the other parameters are vc_index, vc_hash, etc), and VCMP outputs an VC_issued event. At the same time, the VCMP inserts a new record into the VC Registry, the key isvc_index, and the value is vc_context (this includes subject, vc_hashand vc_status). The default vc_status is active.
The registry does not store all the content of a VC. Rather, it stores only the VC index and context to ensure that the privacy of users is protected. It is responsible for maintaining a list or directory of issued credentials. The registry typically includes the VC subject (the individual to whom the credential was issued), the VC status (active, revoked, expired, etc.), and the VC hash. This information can be accessed by verifiers to verify the authenticity and validity of a credential presented by a holder.
What data is stored locally?
If “locally” refers to the user’s browser, in this instance, it is mainly cached data like received VC, identities and shielding key.
If “locally” refers to local Litentry, then the user shielding key and IDGraph is stored inside the TEE that only the pre-programmed logic (enclave) can have access to. VC is currently part of the parachain history as events, with encryption.
What is stored in IDHub?
IDHub stores the challenge codes that users request from the Litentry Parachain to initiate an identity verification process.”
What are the worst-case scenarios? Data being breached? User losing access?
One worst-case scenario is that there are loopholes in the design of TEE and data got leaked. User’s account relationships are exposed. We have implemented a few measures to avoid this happening, for example, regular and timely updates of the TEE version, running the SGX by ourselves, and actively looking for other privacy solutions that are secure and scalable.
What if I want to log in to the same account from another computer? I use the same wallet address and same password but would it hold the same VCs generated?
At present, we do not have any centralized syncing services in place. However, this limitation will be addressed in the upcoming major project update. In the next update, you will have the ability to:
- Query the old shielding key as long as you own the wallet's private key.
- Download the previous verifiable credentials (VCs) using the old shielding key, with the assistance of an indexer.
Can I create my own assertions? (from the user's perspective)
Not yet, but we are actively working on it. Our team is currently in the process of developing a language/schema specifically designed for describing assertions, as opposed to the current schema used for credentials. This forthcoming language/schema will enable the conversion of self-defined assertions into formats readable by the Trusted Execution Environment (TEE).
Additionally, we are establishing a comprehensive workflow to support the inclusion of new assertions. This workflow encompasses the integration of new data metrics and the utilization of available data providers, ensuring a seamless process for incorporating new assertions into our system.
Where will these VCs be useful? Do you have any partners right now?
There are a few use cases of the VC for our partners:
- Audience selection & segmentation based on crypto experience and project contribution
- Create custom ‘Profiles’ & ‘Scores’ to segment audiences and community participants
- Credit scores & eligibility for under-collateralized lending and other reputation-based benefits.
- Private & Secure identity data injections into NFTs, dApps & other apps.
- On-chain resumes and credentials that unlock NFTs, access, or other identity benefits
Is it the same VC as other Identity providers are creating? Are those VCs interoperable? Can you read kilts VC’s can Kilt read yours?
At present, verification of the VC can only be done manually. However, we are actively working on developing a comprehensive solution that will allow anyone to independently verify VCs. This upcoming solution aims to streamline the verification process and ensure the interoperability of VCs. Until this solution is available, the VCs may not be fully interoperable.
The VC that I’m creating ( participating in polkadot decoded) feels like a poap. What is the difference?
One difference is flexibility in implementation. Compared to a POAP NFT, VC and its W3C data model are very generic. It can be considered as a container for different types of data including on-chain data, off-chain data and others. The implementation of VC is very flexible: you don’t have to follow any interfaces or preset APIs, and can simply write your own.
Besides, VC allows more fine-grained control of privacy because the holder of VCs can easily choose which VC to present or present only a part of a VC. For example, a holder of a VC, which proves his or her bachelor’s degree from a university, can extract partial information from a VC and prove that s/he graduated without disclosing which university s/he went to. POAP doesn’t have this feature by default, but it can potentially utilize zero-knowledge proof to achieve a similar privacy-enhancing effect.
Where is TEE? Physical? VM?
The TEE device is bare metal, and the TEE is located in a secure area of the SGX nodes. We are using Intel SGX (Software Guard Extension), a new instruction set in Skylake Intel CPUs since autumn 2015. Every node in the side chain must support SGX.
What are you relying on in terms of trusting in TEE? What are dependecies?
When discussing the protection mechanisms offered by SGX, it is crucial to acknowledge the assumption that Intel serves as a trusted third party. Presently, we operate under the assumption that the hardware is free from any potential backdoors and that Intel acts as an honest and uncompromised participant during remote attestation processes.
How secure is the passing of VC from IDHub to the third-party partner (dApp?)
To share a verifiable credential (VC) generated from IDHub with a third party, the user currently needs to download the VC from IDHub and subsequently upload it to their preferred third-party service providers. Presently, there is no direct method for transferring VCs between parties.
Can I customize the page to my branding? — I don’t want to send my users to external platforms. (Business)
Not yet, but our team is working toward this direction to allow more customization.
What's your relation with 0Auth?
OAuth serves as a centralized method for verifying ownership of identity, such as social media login credentials and granting access to other services based on that verification.
In the future, we may explore utilizing OAuth to verify your Twitter identity without the need for public posting on your Twitter account. However, it is important to note that the decentralized protocol we are developing only shares conceptual similarities with OAuth. From a technical standpoint, they differ significantly. These similarities primarily involve proving statements through verifiable credentials (VCs) which can be used to grant access to various resources. It’s worth highlighting that the use cases of our decentralized protocol extend beyond this particular scenario.”
Why haven’t you done anything with Nova Wallet?
Integrating VC into Nova wallet is definitely a possibility. In fact, we have a dedicated group that is well-versed in this area and could be a valuable resource for any future collaboration efforts.
How are you different from KILT?
KILT is a protocol for issuing and verifying decentralized credentials, while Litentry is a decentralized identity aggregator that enables users to link and manage their identities across multiple networks.
We both provide identity solutions including credential issuance and verification, but Litentry focuses on leveraging credentials as a base for score computing that helps service providers to find target audiences in a privacy-preserving manner. In Litentry, the storage of ID graphs and the entire identity data aggregation process will be implemented by the TEE Sidechain of the Litentry network to enhance user privacy.
Does Litentry Parachain have smart contract Pallet running?
Not yet but we are doing research towards this.
Thank you to all the individuals at Decoded for their thought-provoking questions! It was an excellent opportunity to gather valuable insights and address various topics related to Litentry.
As we continue to evolve and explore new avenues, Litentry remains committed to its vision of empowering individuals with self-sovereign and privacy-preserving identity solutions. Stay tuned for future updates and exciting advancements in the Litentry ecosystem!
About Litentry
Litentry is a privacy-preserving Identity Aggregation protocol that enables granular access to and control of data. Featuring a DID indexing protocol and a Substrate-built distributed DID validation blockchain, Litentry provides a decentralized, interoperable identity aggregation service that mitigates the difficulty of resolving agnostic DID mechanisms. Litentry provides a secure vehicle through which users manage their identities and dApps obtain real-time DID data of an identity owner across different blockchains.
Stay in touch with us!
Discord | Telegram | Twitter | Github | Website | Newsletter
