Create adr-043-interchain-identifiers.md

[ig-shaun]

First draft ADR for feedback.
Is 043 the next in this sequence?

Description

New ADR proposal

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[aaronc]

So I think this is maybe where there are some misunderstandings arising. I have been advocating for namespaced denoms within bank. But bank would never itself issue any denoms itself but rather manage denoms from a number of sources that are likely namespaced. I would feel more comfortable using the language NAMESPACE instead of MODULE. Module is the software component and there likely won't be a 1:1 correspondence. Instead, a chain would have a mapping for which modules deal with which namespaces of assets IID. I think fundamentally this comes down to the SDK's information model for assets and identities - it's not as if just any module exposes its own asset interface. Currently only two modules fundamentally deal with assets and identities - bank and auth respectively. Maybe there will be a third one for NFTs if that doesn't get dealt with by bank, but either way it's a different level of the stack. The namespace, however, would likely point to a class of assets dealt with by a specific module or rule set proxied through the generic bank, nft and auth module APIs. Hope that makes sense.

[ig-shaun]

I would feel more comfortable using the language NAMESPACE instead of MODULE.

@aaronc this makes complete sense and I will update accordingly.

It's not as if just any module exposes its own asset interface.

Agreed, but we should at least have a core set of standard interfaces for modules which deal with assets.
There's still a question in my mind about whether an asset module should store its own identifiers and metadata, vs relying on a an identifier and metadata module (e.g. x/IID) which could service all modules.
In working through this, Joe and I feel there are advantages to an asset module handling its own identifiers and metadata, within the context of the module and the services it offers.
We would be keen to hear what others think about this.
In the interim, we are continuing to develop the IID interface and a demo module. The next question would be whether we should submit another ADR to propose an IID module for the SDK.

[jandrieu]

@aaronc I agree that renaming the "module" component to namespace is a solid improvement. There need not be the expectation that all namespaces within a chain are 1:1 controlled by modules.

That said, there is a nuance with IIDs that I want to anchor.
@aaronc wrote:

It's not as if just any module exposes its own asset interface.

Correct, if a module isn't managing on-chain state, there's no need to expose an IID interface.

However, any module that manages on-chain state of any kind of asset, whether those assets are NFTs, FTs, accounts, services, transactions, encumbrances, or something else would benefit from IIDs. All a module needs to do is expose an IID interface (and provide the routing at the hub and chain level) and it can plug in to the cosmos IID ecosystem and have a fully conformant DID for whatever assets it manages.

We anticipate, for example, that bespoke licensing modules are going to emerge to handle arbitrarily complex domain-specific encumbrances for NFTs that reside elsewhere (either on another module or another chain). Each of these modules would/could/should expose an IID for controlling their assets, e.g., the licensing contract attached to an NFT but managed by a module that understands that Paris is in France or the royalty agreement attached to a given NFT. These assets may or may not be "tokens" in any sense.

In other words, I see far more modules exposing an IID interface than I think you've been considering. It isn't just the NFTs and accounts that need IIDs; anything the manages an on-chain state and exposes an interface for managing that, can (and IMO should) expose an IID interface.

Of course, this transition will be gradual and it will likely be a while before it is the norm. However, the architecture of IIDs is far more flexible than your comments suggest.

@ig-shaun and I have been working through whether or not there is a place for an IID module that is, itself, managing the state of IID Documents by recording them, explicitly, on chain. My sensibility is that such a module is likely going to replicate state-management logic already encoded in the module that manages the asset. For example, if we had a cryptokitties module (which uses native cosmos modules for some of the underlying work, like bank and auth) that module has all the logic for translating on-chain records (based on signed transactions) to the "cattribute" properties that define a given cryptokitty, such as genes and "siredWith".

I imagine an IID module that provides helper functions to turn a set of properties and behaviors into well-formed IID Documents, but which itself is not managing state of those properties & behaviors. Alternatively, a cryptokitty module could defer (at least some) state management to an IID Module, but my estimate is that will lead to duplicate data stored on chain, which feels like both a systemic waste and an attack vector should the IID Module and the asset module get out of sync for any reason. We're still working through these tradeoffs.

[aaronc]

Thanks for sharing that context @jandrieu. My sense is that generally the IID layer shouldn't manage its own state, but rather act as a translation layer which exposes the IID API for existing modules.

[aaronc]

Suggested change

	# ADR 043: Interchain Identifiers
	# ADR 045: Interchain Identifiers

[jandrieu]

Looks like this will bump to 046 if we get this merged soon.

[jandrieu]

As requested in #9329 (comment)

@aaronc wrote:

Thanks @jandrieu. So I've been meaning to comment in #9589, but as I understand it there is no known technical solution for IID's.

I'm fascinated by this. Could you explain in more detail? IIDs are DIDs and DIDs are under wide development and use, including deployments that are expected to reach tens of millions of people this year alone. So, it isn't the DID part of IIDs that are the problem. The extensions to DID properties added by IIDs are neither controversial nor complicated. They are a straight-forward engineering task. To say there is "no known technical solution" means either you are seeing something I'm not aware of or I have failed to communicate IIDs effectively.

It would be great if @colin-axner could comment, but based on my read of the situation, once IBC is involved we can't disambiguate essentially identical denoms/classes because of how a token was routed from one chain to another. IID's are an idea that I really like in theory, but without a technical solution it is a bit hard to use them in this case.

I would love to understand how this is a failure. The DID universe not only allows, it requires each namespace to define its own method-specific identifiers. The rest of the ecosystem treats those as opaque. A wallet need not understand anything about particular DID methods, it just needs a resolver that does. Best practice is to use your own resolver (or buy a resolver service from a trusted party), but the wallet just knows the ID and the method, and doesn't need anything else until it parses the DID Document returned from the resolution process. That's where the verification relationships describe how to interact securely with the asset and service definitions present where to interact with the asset.

So how does an opaque identifier--whose purpose is literally to delineate potentially similar assets--how does that become ambiguous just because IBC? A DID is a DID is a DID, regardless of the chain its on.

My expectation is that there are assumptions here, such as constructing identifiers as hashes of denoms and classes, which I believe are the disconnect. This is the disconnect I'd like to figure out.

From your comment, I believe you are actually making my point, namely these two factors are in conflict:

1. We need unique, unambiguous identifiers (which IIDs are)
2. The current class/id schemes are NOT unambiguous

Your conclusion is that IIDs don't work because #1 and #2 are incompatible.

My conclusion is that #2 is the problem and that #1 is a requirement regardless of whether or not IIDs are adopted as a solution. If you're building your identifiers such that they are NOT globally unambiguous, I say you're doing it wrong.

I'm not sure if we're talking past each other, but I think we're getting closer to why I believe IIDs are a critical feature for NFTs: if you can't remove the ambiguity (and IIDs do that) then you can't even know which NFT is involved in a given transaction. Settle on an approach that is compatible with IIDs and then you'll have globally unique identifiers that work. Use a different approach and you still need to figure out global uniqueness or you can't tell NFTs apart. There are other ways to solve that, but you need one as part of the solution.

Since that was the second time I responded to a direct request for comment and was asked to move the topic off the NFT issue, I'm moving it here.

If, in fact, the current approach for IBC is incompatible with DIDs, then this proposal would need to be completely rethought.

I made the case in the NFT conversation because I had thought IBC was fundamentally a dumb pipe, but folks kept asserting that IBC somehow requires a compositional identifier architecture that, apparently, won't work if IIDs or DIDs are used to identify NFTs. If the current proposal for NFTs doesn't work for DIDs, then I think we should keep working on that to ensure that Cosmos NFTs are compatible with DIDs.

Can anyone clarify how DIDs break IBC?

[aaronc]

I would really love it if someone from IBC could comment here (@colin-axner or @AdityaSripal?), but I'll try.

So the thing that won't work with the current setup is using an IID as an on-chain identifier to uniquely identify an asset that came from another chain. Currently, even if somehow we know that two tokens came from the same IBC chain, we can't make them fungible because they're actually vouchers for escrow tokens on the channel/port combos they came from. So, we can't just say in the bank or NFT module that all bar:baz tokens from foochain are did:cosmos:foochain:bar:baz because there could be two or more IBC routes by which tokens from foochain arrive on our chain. Now, maybe at the user interface level there could be some way to turn IBC identifiers into IIDs, but we still would have the fungibility problem that we couldn't just combine balances for two bar:baz tokens that came over different IBC routes.

Maybe there is a way that on-chain governance could limit the routes that IBC tokens take to get on a chain so that there is a consensus 1:1 mapping between any unique chain and a channel/port. This would mean having some way to reject tokens that don't come over an expected channel/port combo so that we don't run into this problem. I don't know if this is a feasible idea or if anyone has talked about it, but it might be a way to make this all work nicely using IIDs both on-chain and in user interfaces. Again, it would be great if anyone with more context than myself were able to comment on this topic.

[colin-axner]

@AdityaSripal can provide the most insight here, but I'll do my best to offer some perspective in the meantime. IID's need to make use of channel/port id's. Channel/port id's are what offer an understanding of where the token originated from. Chain identifiers are like consensus parameters and should not be used as a single source of truth in IBC. They are like a chain's unbonding period, you cannot possibly know what chain you are referring to by just referencing the unbonding period. Validators sign over these consensus parameters. What does identify a chain is its root hash and the next validator set hash for some height. IBC maps the channel/port to the consensus states (root hash/next validator set for a sparse set of block heights) and a set of consensus parameters in the form of a client state for which the consensus states are valid for

I forget the exact format of IID's but simplicity sake in the IBC case lets say it looks something like this: did:cosmos:origin-chain:dest-chain-after-1-transfer. The destination chain after 1 transfer would not be the chain id, it would be something like nft-transfer/channel-12984. This would unique identify a chain connected to the origin chain via channel-12984. It is up to the client side to abstract away the nitty gritty details of consensus states and consensus parameters and determine that in fact channel-12984 is on a connection with the cosmos hub

If the question is about trying bring this UX abstraction on-chain, then that seems me more of a question of how to bring social consensus on chain. At some point we all need to agree that what is referred to as "Cosmos Hub" comes from specific genesis file

I may not have a complete picture of how IID's work with IBC, but a few months ago @AdityaSripal did this investigation and it seemed entirely possible to me

[robert-zaremba]

Left few comments. I propose to merge this PR and iterate towards a proposal.

[robert-zaremba]

If we have only one method name (cosmos), then who will be in charge of creating and assigning chain name?

[jandrieu]

My expectation is that this would be an on-chain registry on the Hub with some sort of governance mechanism for managing name claims.

As for who would build or control that, I'm not sure who the best party would be, but I understand there are a few options available.

[robert-zaremba]

Good, let's add it in the doc.

[robert-zaremba]

Please provide a link to the RFC-09

[robert-zaremba]

PING - shall we we update the ADR and move forward?

[aaronc]

@robert-zaremba this ADR can't move forward because there is no technical solution yet. Putting a block here to make this clear.

This ADR specifies an IID format with a CHAIN identifier. @colin-axner described a way to make IID's work using the IBC channel/port's, but that is not what this ADR tries to do and would not result in unique interchain identifiers for assets. That piece requires bringing social consensus on-chain about which as @colin-axner has pointed out. We don't yet have a solution for that. Nevertheless, I do think it's a great idea.

[aaronc]

What's needed to move this forward IMHO is a conversation between someone from the IBC team (maybe @AdityaSripal or @colin-axner) and the gov working group (maybe @hxrts or myself) to talk through what's needed to bring social consensus about chain identifiers on-chain and coordinate that with IBC.

[PaddyMc]

There is an implementation of a DID module in the cosmos-cash project that is compliant with the W3C DID spec. There will be some small updates in the next few weeks, the most notable will be the upgrade to 0.43.0 and some updates to the structure to match best practices in the SDK, e.g removal of handler.go and removal of the types folder.

• https://github.com/allinbits/cosmos-cash/tree/main/x/did
• https://github.com/allinbits/cosmos-cash/blob/main/proto/did/did.proto

Also, feel free to check out the Universal Resolver Frontend that points at the cosmos cash testnet node:

• https://uniresolver.cosmos-cash.app.beta.starport.cloud/

There are also some demo scripts that you can view as a reference if you want to interact with the chain e.g create a DID and then use the universal resolver front end to query the did you created

• https://github.com/allinbits/cosmos-cash-misc/blob/main/demos

Also, any feedback on the module is welcome! 😄

All things considered, I propose a two-step approach to adding the IID module to the SDK:

1. Add DID module to the SDK; we could work with the core SDK team to update the DID module in cosmos cash to a standard that the core team is happy with then integrate into the SDK

2. Update DID module to IID spec; this could be taken on at a later date and would be much easier to achieve than attempting to add everything at once, it's my understanding that an IID is a DID with two extra data structures Linked Resources && Accorded Rights. This can be undertaken by another team.

If this is the route we want to take I'm happy to put some engineering effort into making this happen!

[robert-zaremba]

this ADR can't move forward because there is no technical solution yet

@aaronc the ADR is in Draft. If we agree that IIC is something we want to do, then I think we should merge a a clean version of it as a Draft and specify the technical solution later. This way we will "book" the ADR number and have a common reference for the future. Now we need to push back the ADR number.

[jandrieu]

Suggested change

	- `DID:COSMOS:` for the Cosmos Method (IID)
	- `DID:COSMOS:` for the Cosmos Method (IID)

We should discuss the use of 'cosmos' for this IID methods. I think there is an important opportunity to maintain the IID convention, where the DID only ever identifies on-chain assets and do so in a way that any Cosmos blockchain can easily adopt. This convention ensures some modest privacy benefits but is, by necessity, a different way to do things that "normal" DIDs. It is just a convention, but if we start promoting using IIDs to represent people, then we can't tell, for example, if a given VC with the subject as a cosmos DID/IID is about the person the DID is used to refer to, or to an on-chain asset that record data for the DID.

At the same time, there is also high demand for more traditional DIDs on Cosmos (as odd as that sounds for a tech that hasn't even been published as a formal standard). DIDs that are used to represent people or companies, are not IIDs, by definition. It may well be far more appropriate to use did:cosmos for generic identifiers and find another monicker for cosmos-based IIDs.

Once we have the software for one (either a Cosmos DID Method or a Cosmos IID Method), the software should be readily usable for the other. The main advantage of supporting a Cosmos DID Method (on which is not an IID) is that existing and emerging DID expectations are that DIDs for people use the primary authentication for the DID as a means of authenticating people. IIDs provide a way to authenticate as either the NFT or as an subset identifier defined within the IID's namespace. Those subset IDs can refer to people in IIDs and IIDs allow that in a way that removes the HTTPRange14 problem, but most authentication approaches I know do not actively support the notion of authenticating as a subidentifier.

ALTHOUGH, I just thought of a way that we might be able to get support for authenticating subidentifiers without too much of a lift. At least there might be a way to have the only real difference between IIDs and DIDs be how they are used (convention) rather than DID-level functionality like authentication and authorizations.

So, if the DIDs for people use case is important, and I think it is, we should probably use did:cosmos for that use and explore another monicker for cosmos IIDs.

[jandrieu]

@ig-shaun @AdityaSripal @Sam-Interchain

Can we find the right party to make a decision on this? I agree that if we can't have a name service, we can't have a universal did:cosmos that works for all cosmos chains.

However, it seems there would be significant value for a did:cosmos that allowed any Cosmos chain to stand up a DID issuing capability without formally developing their own DID method.

If that value doesn't make sense for Cosmos, then I'd recommend establishing a common interface without solving for a universal did:cosmos, so that application chains could at least develop interoperable DID methods, such as did:ixo and did:regen.

[AdityaSripal]

This ADR specifies an IID format with a CHAIN identifier. @colin-axner described a way to make IID's work using the IBC channel/port's, but that is not what this ADR tries to do and would not result in unique interchain identifiers for assets. That piece requires bringing social consensus on-chain about which as @colin-axner has pointed out. We don't yet have a solution for that. Nevertheless, I do think it's a great idea.

IBC doesn't natively support absolute identifiers for interchain assets, because IBC does not have absolute identifiers of the chains it connects to.

It only has relative names like clientID, channelID, etc.

An asset can have a unique name on a single chain A, and then all connected chains could have a relative path to that chainA and then reference the unique name on chainA.

But all connected chains do not have the same unique identifier for chainA.

If that is an absolute requirement, it would require some additional piece of infrastructure to provide that absolute, global chain naming. Perhaps through a Chain Name Service

[jandrieu]

This ADR specifies an IID format with a CHAIN identifier. @colin-axner described a way to make IID's work using the IBC channel/port's, but that is not what this ADR tries to do and would not result in unique interchain identifiers for assets. That piece requires bringing social consensus on-chain about which as @colin-axner has pointed out. We don't yet have a solution for that. Nevertheless, I do think it's a great idea.

IBC doesn't natively support absolute identifiers for interchain assets, because IBC does not have absolute identifiers of the chains it connects to.

I am confused by this. If IBC can't support unique identifiers, then IBC can't support IIDs as their own internal representation of NFTs.

But IIDs don't depend on IBC.

But if I read it correctly, what I think you are actually saying is that IBC can't support a unified cosmos IID without a name resolver.

That's correct. DIDs and IIDs must be globally unique. That's the whole point. If we want IBC to support DIDs for on chain assets, you're going to need to come up with a solution for uniqueness.

The known solution is to provide a name resolver as part of the Cosmos DID infrastructure, so that the first step in resolving a Cosmos IID is to resolve the cosmos name to the chain. Then you contact that chain to resolve the chain-specific name space.

IMO, the only other alternative is to NOT provide a unified Cosmos IID (or DID), but instead establish the pattern that any application chain may register its own DID method, with its own specification, eg., did:ixo or did:regen. That approach gives us an interoperable approach to IIDs and DIDs, but without the ease of which a unified name resolver enables.

If a name resolver is a non-starter, @AdityaSripal is right, we should get rid of the chain component and, instead, find ways to make it easy for application chains to establish their own independent method (which, naturally will still be able to leverage a shared codebase, but will need a separate method specification).

-j

[aaronc]

Maybe what is proposed in #9948 is a reasonable way to achieve the goals of IID's? Basically that each chain has a gov controlled chain name <-> IBC mapper.

[robert-zaremba]

Suggested change

	Example: `did:cosmos:ixo:earth_nft:submodule_address`

[robert-zaremba]

let's make the explanation a bit easier, eg: In other words, Cosmos IID is DID with an on chain record.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.