Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External asset management #339

Open
jandrieu opened this issue Mar 1, 2022 · 1 comment
Open

External asset management #339

jandrieu opened this issue Mar 1, 2022 · 1 comment

Comments

@jandrieu
Copy link

jandrieu commented Mar 1, 2022

In the IID work, we have the requirement that the actual content of a DID Document is determined by the asset module that manages the specified on-chain asset.

Is there a way to do that with this module? I've seen reference elsewhere to handler mechanisms. Is this a part of the design?

Or does this module require that the DID Document be stored directly by the cosmos cash module? That, in essence, the cosmos-cash module is the authoritative getter and setter of all DID Document properties under this approach?

This is important because for many of the NFT use cases we are focused on, it is not a generic DID Module that maintains chain state, it is the NFT module, which enforces its own business rules, as appropriate. Those business rules determine the ultimate content of the DID Document, and in our architecture, that means the asset module is the party that is authoritative for DID Document content. The role of what I call the DID registries is to forward the resolution request to the right party.

Consider did:cosmos:ixo:nft:abc123, did:cosmos tells us to go to a DID registry module on Gaia (or in a likely version 0, to the chain registry repo). That first DID registry confirms that it handles did:cosmos and returns the routing information for the DID registry on the ixo application chain (did:cosmos:ixo). Then that application-chain DID registry returns the routing information for did:cosmos:ixo:nft, which allows the caller to query the ixo NFT module for the DID Document. Since the NFT module is the authoritative source for the chain-state of the asset in question, it then constructs the DID Document, serializes it, and returns it to the user.

sequenceDiagram
User->>Cosmos DID Registry: Resolve `did:cosmos:ixo:nft:12345`
Cosmos DID Registry->>Chain Registry: Lookup correct 'chainspace' value for `did:cosmos:ixo:nft:12345`
Chain Registry->>Cosmos DID Registry: Return route to ixo DID Registry 
Cosmos DID Registry->>User: Route to ixo DID Registry
User->>ixo DID Registry:  Resolve DID for `did:cosmos:ixo:nft:12345`
ixo DID Registry->>User : Return route to ixo NFT module
User->>ixo NFT Module: Resolve DID for `did:cosmos:ixo:nft:12345`
ixo NFT Module->>ixo NFT Module: Construct DID Document based on current chain state
ixo NFT Module->>User: Return DID Document for DID `did:cosmos:ixo:nft:12345`
Loading

Is there a way with the Cosmos cash module to defer state management to an external asset module?

jandrieu added a commit to LegReq/did-earth that referenced this issue Mar 1, 2022
Added autonumbering and used language referenced in the cosmos-cash discussion at allinbits/cosmos-cash#339
@PaddyMc
Copy link
Contributor

PaddyMc commented Mar 2, 2022

Interesting use-case, and thanks for elaborating.

Yes, if I understand the use case correctly, you can dependency inject the "DID data getter/setter" (keeper in cosmos land) into the external asset module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants