Open Vishwas1 opened 2 years ago
If each authentication scheme is implemented in a different way, then IBC applications that need to process an "authorizing party" before sending the IBC packet will have to explicitly enable each authentication scheme.
Instead a uniform authentication layer that sits between specific authentication schemes and their end applications will provide a uniform interface across which entities can authenticate interactions with IBC applications
Instead a uniform authentication layer that sits between specific authentication schemes and their end applications will provide a uniform interface across which entities can authenticate interactions with IBC applications
The DID document for an internet user might include their public keys and which public key should be used for which interaction. Perhaps the DID document specifies an ED25519 PublicKey for authenticating web log-ins, and a JsonWebKey2020 for negotiating secret keys for communication. The (DID, DID Document) pair is maintained on a public ledger and allows the DID document to be updated, allowing other parties to authenticate interactions from the DID subject even as public keys are rotated.
https://github.com/cosmos/ibc/tree/master/spec/ics-001-ics-standard
Example:
Please see the the following threads
@AbhijitSinha1 shared by Charley
This documents aims to document the structure, plan and implementation of the Interchain Queries Module allowing for cross-chain querying of state from IBC enabled chains.
Pre-requisite
Basic of IBC #11
Objective: Write ICS spec for DID transfer over IBC
Example Specs: