This is a project designed to demonstrate the use of IBC between different zones in the Cosmos ecosystem for privacy preserving credential management. This is a project incubated for the submission of HackATOM HCMC 2021
As we all become increasingly aware of the risk of having our privacy taken away whilst demanding interoperability between systems, a single entity or even blockchain providing the single source of truth is no longer satisfactory.
This is where IBC becomes a critical component on which the future is built on.
Since the relayer services and zones can be external or public, it makes sense to design for cases where the packets sent can be plain text or encrypted.
The use cases we designed for are communications between:
- Private to Public zones where information is public: Use Case 1
- Private to Public zones where information is authorised by the sender only Use Case 2
- Private to Private zones (key-exchanged) Use Case 3 (Not implemented in the Hackathon)
With all the cases listed, this project uses the concepts of verifiable credential to showcase IBC usage. We use [decentralised identifiers] for entities to ensure no social mapping, behaviour patterns can be derived.
It is important to conform to standards and practices that already works well and only make adjustments where needed. No point re-inventing the wheel!
We follow W3C recommendations of Verifiable Credential. A summary of the roles defined are as such:
- Issuer: A role an entity performs by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder.
- Holder: A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them e.g., students, employees, and customers.
- Verifier: A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing e.g., employers, security personnel, and websites.
- Verifiable data registry: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as revocation registries or public keys from an issuer which require verifiable credentials e.g., trusted databases, decentralized databases, government ID databases.
We restrict ourselves to provide, to all the users (Issuer, Holder, Verifier), the same interface as this model, i.e., only communicating with a Verifiable data registry.
However, their may or may not be communication to the same verifiable data registry. This is where IBC connects the different services provided by the registry. This is demonstrated in Figure A.
Figure A
- Each holder will have as many DID as needed, these may be used once or reused as they see fit
- The Issuer - Holder identifiers may or may not be the same as Holder - Verifiable identifiers
In all use cases, CertX acts as a proofs provider. The proofs may be plain text or encrypted. CertX itself does not provide any recognition or list of authorities to trust etc. It is the verifier's choice as to if a proof is valid / useful or not.
Critically: Either the holder or the verifier needs to register on CertX as this will be unnecessary friction. This usage of this service is strictly with IBC.
- Alice wants to demonstrate to a restaurant that she has been fully vaccinated.
- The restaurant does not need to know who Alice is other than the fact she has been vaccinated.
- Alice does not want to reuse the identity for the restaurant for other services as she does not want to be tracked.
This represents the authorities for muggles (non-magical humans). For example, it might be a blockchain that stores and provides verifiable credential for registered citizens, such as driver license, health record, and in this case, a vaccination record.
With potentially sensitive data, this blockchain is considered private.
Please refer muggleAuth README for details.
This is a publicly accessible Blockchain to store proofs.
Please refer certX README for details.
- Alice wants to retrieve her employment record from the Ministry of Magic for all potential employers.
- A Quiddtich team is a potential employer who wants to verify Alice's claim.
- Alice does not want her record available in public or have Ministry of Magic know where she has applied to.
This represents the Ministry of Magic. They keep many types of record, Alice is interested in her employment record.
With potentially sensitive data, this blockchain is considered private.
Please refer MoM README for details.
This is a publicly accessible Blockchain to store proofs.
Please refer certX README for details.
TODO
As this project develops a few ideas have come up for improvements or unimplemented
- Communications between client and node should be encrypted
- DID creation did not have attached documents / metadata, what was created is for demonstration only
- Alice should give permission for authorities to contact her / not
- Restaurant should not need to know if Alice is a muggle / witch / giant etc, zk-proof for whom the issuer can protect her