Cross Chain Presentation Verification using IBC

[Vishwas1]

Introduction & Problem Statement

Any self sovereign identity (SSI) infra works on something called the "Trust Triangle" architecture (see the image below). Where a user requests certain credential from issuer, the issuer issues the credential to the user by verifying certain attribute provided by the user, the user holds the credential in the wallet or device he owns and whenever he/she needs some service from any service provider (called verifier), the service provider verifies the credential presented by the user as long as it trusts on that issuer.

This works pretty well in web2 world which is built on the anatomy of "Trust". But web3 is trust less. In web3 world, the degree of trust need to be reduced as much as possible.

For example, if the verifier itself is an smart contract on another appchain then how can it verify the credential presented by the user because for that it needs to call the identity infrastructure to be able to verify that credential which may be a different system or chain. Smart contracts may probably call an oracle service to do this job but then it has to trust on the oracle service leading to the problem of storing untrusted data on a trusted system.

Let me explain the problem statement with an example an within the context of Cosmos ecosystem. Imagine a DEX chain/zone only allows users to trade if they show their KYC credential. The KYC credential may be issued on other chain by some trusted KYC issuer. How can the DEX chain verify this credential and let the user trade?

KYC is just an example and probably one use case of this problem statement where any credential issued on one chain needed to be verified on the other chain for some service. We will stick to the KYC use case for future discussion in this document because of two reasons

1. I really do not know any other use case as of now but I believe there can be many use case for cross chain credential verification.
2. We may agree that govt. do want to stop fraudulent activities or money laundering on blockchain but at the same time people in blockchain are privacy focused and they might not willing to reveal their personal data with everyone. We need an identity infra that can serve for both.

About Hypersign

Hypersign is a decentralized identity infrastructure that helps users gain control of their identity and personal data on the internet. Technically speaking, its an application specific blockchain network built using Cosmos SDK for managing decentralized identity. Apart from general PoS network related features like token transfer, staking, governance etc, it mainly provides three main features:

• Decentralized identifier (DID) registry
• Revocation registry (also known as credential status registry)
• Schema registry

DID registry can be used by any entity (called subject) who wants to creates a DID for themselves. The revocation registry is used by issuers who wants to issue credentials to an entity. The revocation registy can also be used by (queried) the verifier who wants to verify any credential presented by an entity. Schema registry is used by credential issuer for giving a standard format to the credential.

Note: Though I am talking about 3 stakeholders here, but Hypersign never discriminate between these stakeholders. Any one can become an issuer or verifier.

At present, the Hypersign infra works well for web2 usecase but it needs features where another appchain or smart contract should be able to verify the issued credential presented by the users without having any trusted third party. And thats why we started thinking about "Cross Chain Credential Verification" feature.

Probable solution

I really do not know the exact solution but at high level it looks like we can make use of IBC to achieve this purpose. Let me explain:

Note: Assuming that KYC credential is already been issued by some trusted issuer to the user on Hypersign chain.

1. At first user will form zero knowledge proof of his credential document because blockchain is public system and credential document may contains private data. So the zero knowledge proof need to be created at the wallet level before requesting any service from the service provider appChain. The present-proof-tx is initiated at the service provider appChain.
2. The relayer conneted with the service provide appchain and Hyersign chain, listens to event for the present-proof-tx.
3. The relayer then initiates the verify-proof-tx on the Hypersign chain.
4. The verify-proof-tx goes through the consensus process where validators nodes verifies the proof and concludes the result as true/false.
5. The relayer again keep listening to events for verify-proof-tx and finally initiates an acknowledge transaction present-proof-ack-tx on the service provider chain. This ack tx may contains the proof result (true or false)

[nghuyenthevinh2000]

My understanding is like so:

1. First case:
   present-proof-tx will include public key (not address) and send it to Hypersign.

Hypersign will then check whether that public key is associated with a verified identity. The result will be sent back to initial chain.

2. Second case:
   In terms of Zero Knowledge Proof, user will scan their face, type their name (all of this be done in a Hypersign embedded web component for original chain website). All of this will become a hash. Such hash will be sent to Hypersign through IBC present-proof-tx.

Hypersign will then check if such hash is in Revocation Registry to see if that person is verified. Hypersign will return result.

We would be thinking about several ibc tx here. Let's say a launchpad needs to see if a person is in China or not. Then, we would need country-proof-tx.

I hope I understand this correctly. Please correct if I am missing anything.

[Vishwas1]

My understanding is like so:

1. First case:
   present-proof-tx will include public key (not address) and send it to Hypersign.

Hypersign will then check whether that public key is associated with a verified identity. The result will be sent back to initial chain.

2. Second case:
   In terms of Zero Knowledge Proof, user will scan their face, type their name (all of this be done in a Hypersign embedded web component for original chain website). All of this will become a hash. Such hash will be sent to Hypersign through IBC present-proof-tx.

Hypersign will then check if such hash is in Revocation Registry to see if that person is verified. Hypersign will return result.

We would be thinking about several ibc tx here. Let's say a launchpad needs to see if a person is in China or not. Then, we would need country-proof-tx.

I hope I understand this correctly. Please correct if I am missing anything.

First of all apologies for late reply. Yeah you got it right. But any verifiable credential state facts about anything. The guy is in China or not, The guy is over 18 or not, The guy has done KYC or not and so on. And zero knowledge proofs of these fact "may" be generated. So present-proof-tx tx will be generalize RPC for any of these use cases. present-proof-tx simply means - users present zero knowledge proof of "facts" which they want to proof.

[Vishwas1]

https://drive.google.com/file/d/1Ifrob-2Wsn18-R6MMb96JvUqj8DJ9gTO/view