Verifiable credential system on Cosmos with IBC for Distributed Identities

Overview

CertX

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

Motivation

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:

  1. Private to Public zones where information is public: Use Case 1
  2. Private to Public zones where information is authorised by the sender only Use Case 2
  3. 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.

Design Overview

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:

w3c_defined_vc

  • 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 decentralised_vdr

  • 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

Role of CertX

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.


Use case 1 Muggles Vaccination records

  • 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.

MuggleAuth (Issuer Zone)

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.

CertX (Proofs Provider)

This is a publicly accessible Blockchain to store proofs.

Please refer certX README for details.

Use case 2 Ministry of Magic Employment records

  • 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.

MoM (Issuer Zone)

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.

CertX (Proofs Provider)

This is a publicly accessible Blockchain to store proofs.

Please refer certX README for details.

Use case 3 Medical records

TODO

Improvements

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
You might also like...
A distributed key-value storage system developed by Alibaba Group

Product Overview Tair is fast-access memory (MDB)/persistent (LDB) storage service. Using a high-performance and high-availability distributed cluster

Dkron - Distributed, fault tolerant job scheduling system https://dkron.io
Dkron - Distributed, fault tolerant job scheduling system https://dkron.io

Dkron - Distributed, fault tolerant job scheduling system for cloud native environments Website: http://dkron.io/ Dkron is a distributed cron service,

SeaweedFS is a distributed storage system for blobs, objects, files, and data lake, to store and serve billions of files fast! Blob store has O(1) disk seek, local tiering, cloud tiering. Filer supports cross-cluster active-active replication, Kubernetes, POSIX, S3 API, encryption, Erasure Coding for warm storage, FUSE mount, Hadoop, WebDAV. JuiceFS is a distributed POSIX file system built on top of Redis and S3.
JuiceFS is a distributed POSIX file system built on top of Redis and S3.

JuiceFS is a high-performance POSIX file system released under GNU Affero General Public License v3.0. It is specially optimized for the cloud-native

implementation of some distributed system techniques

Distributed Systems These applications were built with the objective of studding a distributed systems using the most recent technics. The main ideia

An distributed system developed by gin
An distributed system developed by gin

An distributed system developed by gin

The repository aims to share some useful about distributed system

The repository aims to share some useful about distributed system

Distributed-system - Practicing and learning the foundations of DS with Go

Distributed-System For practicing and learning the foundations of distributed sy

BlobStore is a highly reliable,highly available and ultra-large scale distributed storage system

BlobStore Overview Documents Build BlobStore Deploy BlobStore Manage BlobStore License Overview BlobStore is a highly reliable,highly available and ul

Comments
  • I think, we probably shouldn't implement `RemoveCredential()`

    I think, we probably shouldn't implement `RemoveCredential()`

    Regarding this section https://www.w3.org/TR/did-core/#persistence.

    DIDs are designed to be persistent such that a controller need not rely upon a single trusted third party or administrator to maintain their identifiers. In an ideal case, no administrator can take control away from the controller, nor can an administrator prevent their identifiers' use for any particular purpose such as authentication, authorization, and attestation. No third party can act on behalf of a controller to remove or render inoperable an entity's identifier without the controller's consent.

    So, I think the revoke process should be tracked.

    https://github.com/whalelephant/CertX/blob/main/certX/x/credentials/keeper/credential.go#L88

    // RemoveCredential removes a credential from the store
    func (k Keeper) RemoveCredential(ctx sdk.Context, id uint64) {
    	store := prefix.NewStore(ctx.KVStore(k.storeKey), types.KeyPrefix(types.CredentialKey))
    	store.Delete(GetCredentialIDBytes(id))
    }
    
    opened by chiro-hiro 0
Owner
bwty
bwty
Distributed reliable key-value store for the most critical data of a distributed system

etcd Note: The main branch may be in an unstable or even broken state during development. For stable versions, see releases. etcd is a distributed rel

etcd-io 41.9k Nov 27, 2022
A Golang implementation of the Umee network, a decentralized universal capital facility in the Cosmos ecosystem.

Umee A Golang implementation of the Umee network, a decentralized universal capital facility in the Cosmos ecosystem. Umee is a Universal Capital Faci

null 161 Nov 17, 2022
Distributed lock manager. Warning: very hard to use it properly. Not because it's broken, but because distributed systems are hard. If in doubt, do not use this.

What Dlock is a distributed lock manager [1]. It is designed after flock utility but for multiple machines. When client disconnects, all his locks are

Sergey Shepelev 25 Dec 24, 2019
Fast, efficient, and scalable distributed map/reduce system, DAG execution, in memory or on disk, written in pure Go, runs standalone or distributedly.

Gleam Gleam is a high performance and efficient distributed execution system, and also simple, generic, flexible and easy to customize. Gleam is built

Chris Lu 3.1k Nov 16, 2022
A distributed system for embedding-based retrieval

Overview Vearch is a scalable distributed system for efficient similarity search of deep learning vectors. Architecture Data Model space, documents, v

vector search infrastructure for AI applications 1.5k Nov 18, 2022
💡 A Distributed and High-Performance Monitoring System. The next generation of Open-Falcon

夜莺简介 夜莺是一套分布式高可用的运维监控系统,最大的特点是混合云支持,既可以支持传统物理机虚拟机的场景,也可以支持K8S容器的场景。同时,夜莺也不只是监控,还有一部分CMDB的能力、自动化运维的能力,很多公司都基于夜莺开发自己公司的运维平台。开源的这部分功能模块也是商业版本的一部分,所以可靠性有保

DiDi 5.6k Nov 24, 2022
a dynamic configuration framework used in distributed system

go-archaius This is a light weight configuration management framework which helps to manage configurations in distributed system The main objective of

null 203 Nov 1, 2022
A distributed and coördination-free log management system

OK Log is archived I hoped to find the opportunity to continue developing OK Log after the spike of its creation. Unfortunately, despite effort, no su

OK Log 3k Nov 18, 2022
A distributed MySQL binlog storage system built on Raft

What is kingbus? 中文 Kingbus is a distributed MySQL binlog store based on raft. Kingbus can act as a slave to the real master and as a master to the sl

Fei Chen 854 Oct 30, 2022