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.

Sign up for GitHub

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

Jump to bottom

Create adr-043-interchain-identifiers.md #9589

Closed
wants to merge 12 commits into from
Closed

Create adr-043-interchain-identifiers.md #9589

Changes from 1 commit
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
7d98d7a
Create adr-043-interchain-identifiers.md
ig-shaun Jun 27, 2021
63a57a0
Update adr-043-interchain-identifiers.md
ig-shaun Jun 29, 2021
d438398
Merge branch 'master' into patch-1
Aug 26, 2021
65e5886
Merge branch 'master' into patch-1
Sep 10, 2021
874817c
Update docs/architecture/adr-043-interchain-identifiers.md
ig-shaun Sep 24, 2021
1859f7d
Update docs/architecture/adr-043-interchain-identifiers.md
ig-shaun Sep 24, 2021
ebfbf9d
Update docs/architecture/adr-043-interchain-identifiers.md
ig-shaun Sep 24, 2021
b0c5ce9
Update docs/architecture/adr-043-interchain-identifiers.md
ig-shaun Sep 24, 2021
37781df
Update docs/architecture/adr-043-interchain-identifiers.md
ig-shaun Sep 24, 2021
a4db606
Update docs/architecture/adr-043-interchain-identifiers.md
ig-shaun Sep 24, 2021
faaa576
Merge branch 'master' into patch-1
Nov 1, 2021
6f77c8d
Update docs/architecture/adr-043-interchain-identifiers.md
robert-zaremba Nov 7, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
108 changes: 108 additions & 0 deletions docs/architecture/adr-043-interchain-identifiers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
# ADR 043: Interchain Identifiers
ig-shaun marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# ADR 043: Interchain Identifiers
# ADR 045: Interchain Identifiers

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


ig-shaun marked this conversation as resolved.
Show resolved Hide resolved
## Context

In the Internet of Blockchains We need a way to identify and locate assets within their chain namespace, using web-standard ([RFC39](https://datatracker.ietf.org/doc/html/rfc3986)) Universal Resource Indentifiers (URIs).
ig-shaun marked this conversation as resolved.
Show resolved Hide resolved

When we refer to on-chain assets, this includes tokens, wallets, name records, or any other uniquely identifiable entity within a chain namespace.

**Interchain Identifiers** (IIDs) are a standards-compliant method (based on [W3C DID-Core](https://w3c.github.io/did-core/)) for uniquely identifying, locating, referring to and verifying digital assets which are accessed within, or through, chain namespaces.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


IIDs also enable (off-chain) assertions to be made about (on-chain) digital assets – for instance, in the form of Verifiable Credentials.

An IID Method DID is **self-referential**, which means the asset describes and locates itself in its chain namespace.

Compare this with a generic, all-purpose DID which can be used to identify and refer to _any_ entity. For instance, the canonical application of DIDs is Self-Sovereign Identity, which provides people and other entities with identifiers together with cryptographic methods to authenticate as the subject and to exercise control over the state of the DID Document.

---
We define **Interchain Identifiers** as being explicitly purposed to identify and locate assets within a chain namespace.
ig-shaun marked this conversation as resolved.
Show resolved Hide resolved

---

- An asset on a Cosmos chain <-------- Cosmos IID identifies and locates
- Cosmos DID --------> Identifies and locates an external thing

All DIDs have an associated **DID Document**, which should subscribe to the W3C DID-Core standard.
This defines the cryptographic control structure for a DID, and may also specify the Service types and endpoints which are related to the DID subject.

The properties of a DID-Core standard DID Document include:
- **Identifier** (the DID) of the subject with the Identifier of the Controller who is authorized to update the DID Document.
- **Verificaton Method/s** (The cryptographic key material).
robert-zaremba marked this conversation as resolved.
Show resolved Hide resolved
- **Verification Relationship/s** (Describing and restricting the purposes for which the verification Methods can be used, such as Authentication).
robert-zaremba marked this conversation as resolved.
Show resolved Hide resolved
- **Services** related to the DID subject, with endpoints for reaching these services, such as data stores or blockchain services.

For the IID Method, two additional DID Document properties have been specified, which are required for many types of on-chain assets:
ig-shaun marked this conversation as resolved.
Show resolved Hide resolved
- **Linked Resources** for describing the resources which are associated with an on-chain asset, such as a media file together with its resource identifier, type, format, location and cryptographic proof (such as a hash).
- **Accorded Rights** for recording machine-executable capabilities, legal rights, or any other entitlements, which are accorded to the owner/controller of an asset.

Linked Resources can demonstrate the distinctions between an IID and DID:
```
Asset IID // self-referrant <--
├── Linked Resources // examples
│ ├── Resource DID // externally referrant -->
│ ├── Other Resource URL
│ ├── Another Resource CID (Content ID)
```

The **DID Syntax** for an IID conforms to the [DID-Core Syntax](), which would be expressed as follows for an asset minted from the NFT Module on a Cosmos chain:
ig-shaun marked this conversation as resolved.
Show resolved Hide resolved

`DID:COSMOS:CHAIN:MODULE:abc123`

Where:
- `COSMOS` is the method _(it is not the Cosmos Zone namespace)_.
- `CHAIN` is the namespace, such as `IXO` or `REGEN` _(it is not the chain-id)_.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good, let's add it in the doc.

- `MODULE` is the module namespace, such as `NFT` or `BANK` _(as named within the context of each application chain)_.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- `{unique identifier string} abc123` is defined by applications developers _(NFTs in two different networkscould even have the identical Inique Identifier String value and will still have completely unique IIDs)_

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Unique Identifier strings need only be unique within the context of their own namespace. These may be Serial Numbers, Content Identifiers, or any another identifier method which is either based on a published standard, or is proprietary.

[DID Resolvers](https://www.w3.org/TR/did-core/#:~:text=7.1%20DID%20Resolution.-,DID,-resolver) are required for each DID Method, so that users are able to successfully retrieve the DID Document for a given DID (in the W3C DID-Core standard format).

It is not necessary for application chains to have a separate IID Module (or DID Module), if a specific asset module, such as `NFT`, provides the service of creating and updating IIDs and IID Document state.

An example of the extensibility of the DID syntax: a derivative demom of fungible tokens could be minted to represent the shares IIDs could

## Decision

1. Cosmos IID Method DIDs SHOULD follow the standard format:
- `DID:COSMOS:` for the Cosmos Method (IID)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- `DID:COSMOS:CHAIN:` for a Cosmos chain namespace
- `DID:COSMOS:CHAIN:MODULE:` for a Cosmos SDK module in a Cosmos application chain namespace
- `DID:COSMOS:CHAIN:MODULE:{unique identifier string}` for the application's chosen method for deriving a unique identifier string
2. IID implementations in the Cosmos SDK MUST conform to the Interchain Identifier (IID) specification RFC-09.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please provide a link to the RFC-09

ig-shaun marked this conversation as resolved.
Show resolved Hide resolved
3. All Cosmos chains SHOULD provide a standard IID Interface for registering asset IIDs, creating and updating IID Document properties, and for resolving the IID to return an IID Document.
4. Cosmos assets MAY be identified using IIDs and if implementers choose this format, they SHOULD conform to the IID Method.
5. Application developers SHOULD define their own application-specific Unique Identifier String formats for the modules in their chain namespace.
6. Any chain registry service on the Cosmos Hub MUST support the Cosmos IID Method (did:cosmos).


## Status

Draft

## Consequences

### Positive

- Adoption of an interoperable Interchain standard for identifying and locating assets across all chain namespaces.
- IIDs may be used both within the context of a chain namespace, as well as off-chain, to reference and interact with an on-chain asset.
- Supports application developers to build more features and service capabilities into Cosmos modules, with advantages such as run-time composibility, fully decentralized authorization, more sophisticated account wallets, and service extensions.
- Conformance with W3C standards.
- Can immediately be extended by a family of DID-related specifications, such as Verifiable Credentials and Authorization Capabilities.
- Immediately compatible with the extensive tooling (such as wallets) which has already been built for the DID ecosystem.
- Cosmos application chains have the option to either adopt the IID specification to create their own IID DID Method, or or use did:cosmos to add DIDs to their application chain, without needing to formally specify a new DID Method.
ig-shaun marked this conversation as resolved.
Show resolved Hide resolved

### Neutral

- Minimal changes to existing Cosmos SDK modules (none of which are state-breaking).
- No changes to IBC.
- Any existing DID implementations within Cosmos which have used the DID:COSMOS syntax may not be backward-compatible with the IID Method (we don't know of any).
- Cosmos is already used by a number of application chains to provide DID Registry sevices for externally-referenced DIDs. The syntax of these DIDs do not have to change, but there would be advantages to having a standard way to resolve any DID which uses the IID Method.

### Negative
- Legacy assets which have already been identified by some other method, will not be interoperable with new assets which use IIDs.

## References
- [#9337](https://github.com/cosmos/cosmos-sdk/discussions/9337)
- [Comment 885051](https://github.com/cosmos/cosmos-sdk/discussions/9065?sort=new#discussioncomment-885051)
- [RFC-09](https://github.com/interNFT/nft-rfc/blob/main/nft_rfc_009.md) Interchain Identifier Specification (Draft)