Interchain Identifiers (IIDs for Cosmos DIDs)

[jandrieu]

Interchain Identifiers

IIDs for Cosmos DIDs

Background Reading

NFT-RFC 009 IID Specification

Abstract

Every digital asset in the Cosmos context deserves a universally addressable identifier. Interchain Identifiers (IIDs) are a standards-conformant mechanism for uniquely identifying and referring to digital assets within chain namespaces. Each IID is associated with an IID Document, which contains all the properties needed to interact with, or on behalf of, the asset.

We propose that Cosmos modules use IIDs to unambiguously and interoperably expose any on-chain assets managed by the module as well as their available services.

Three steps to add IID capability

1. Determine chain- and module-specific unique identifiers for each asset.
2. Construct DID conformant identifier strings using those unique identifiers (IIDs) and use those IIDs to refer to its assets
3. Expose an IID interface for returning an well-formatted JSON-LD DID Document, aka an IID Document.

By taking these three steps, any Cosmos module can create 100% conformant DIDs for its assets with minimal extra effort.

Further, by leveraging IID-specific DID document properties, any module can craft privacy-respecting metadata management for any asset.

In short, adopting IIDs for Cosmos blockchains will establish an approach for an interoperable family of DID methods that address the needs of any on-chain asset, no matter which chain originates the asset's provenance. Chains that support IIDs will be able to securely interact with, and provide services for, tokens of any kind from any IID-supporting blockchain.

Context

There is currently no standard way to address, refer to, and interact with digital assets across decentralized name-spaces and the Web. The information needed to describe and interact with digital assets is not yet standardised and interoperable.

Within the Internet of Blockchains, it is essential to be able to address, authenticate and interact with digital assets across namespaces. For interoperability with the Web, blockchain asset identifiers would benefit from adherence to the Uniform Resource Identifiers (URI) standard, as defined by RFC3986.

The Interchain Identifier (IID) Specification NFT-RFC-009 describes a standardised Decentralized Identifier (DID) approach to a family of DID methods that identify on-chain assets and resolve to those asset's IID Documents, which contain the information needed to securely interact with the asset. IIDs fully conform to the W3C DID Core specification, making IIDs compatible with the family of specifications and extensive tooling -- such as wallets -- already available for DIDs. Interoperable with any conformant DID system.

The IID Specification extends the DID Core specification with additional properties for Linked Resources and Accorded Rights. This provides a highly versatile and extensible framework for all types and classes of digital assets, for any imaginable use-case.

The goal of this discussion is one or more ADRs to bring DIDs to Cosmos in the form of IIDs, usable by any Cosmos SDK module that manages digital assets.

Three concrete proposals

1. Interchain Identifiers (IIDs) for Cosmos
2. IID Module in the Hub / Gaia
3. IID Module in Cosmos SDK

1. Interchain Identifiers for Cosmos

Decentralized Identifiers (DIDs) are the new W3C standard (currently in Candidate Recommendation stage) for identifying any subject in the physical or digital realm. DIDs are fully-conformant Universal Resource Identifiers (URIs), as defined by RFC3986.

Interchain Identifiers (IIDs) are a family of DID Methods specifically designed for referring to on-chain assets – such as NFTs, fungible tokens, namespace records and account wallets. IIDs are a sub-class of Decentralised Identifiers (DIDs). In short, all IIDs are DIDs, but many DIDs will not be IIDs.

IIDs resolve to a DID Document (IID Document), which describes the asset's:
• Verification relationships and methods
• Service endpoints
• Linked resources
• Accorded rights

For example: did:cosmos:ixo:token:abc123 is a valid IID referring to a uniquely-identified digital asset, which could be an NFT type of token, of a specific class, in a Token module on the ixo Cosmos blockchain. Resolving the IID returns the asset's IID Document directly from the Tokens module.

The module's resolver service handles message routing to create or deactivate the Interchain Identifier and for authorized users to create, read or update the IID Document properties.

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. An assertion about the asset issued as a Verifiable Credential, or an Authorization Capability (zCap) which controls services the token owner can invoke, are both examples of off-chain applications of IIDs.

Implementing IIDs in Cosmos SDK modules
To enable IIDs, asset modules at minimum:

1. Declare a module-specific namespace and method, which conforms to the IID specification.
2. Implement a standard IID Interface, which provides services for registering asset IIDs, creating and updating IID Document properties, and for resolving the IID to return an IID Document.
3. Implement application-specific Handlers and methods for each service the module offers for assets.

2. IID Module for the Hub / Gaia

We propose a standard DID method for the Cosmos ecosystem (did:cosmos), specifying how to reach any asset, managed by any Cosmos module, in any chain namespace. This DID Method will support the IID extensions defined in NFT-RFC-009, making it the world's first IID Method. Cosmos chains can adopt the IID specification and create their own IID compatible DID Method or leverage did:cosmos to add DIDs to their application chain without needing to formally specify a new DID Method.

The proposed did:cosmos method would uses a single Gaia module to serve as the namespace controller so that any Cosmos blockchain can register its namespace for resolution. Any namespace module that adopts the IID specification and works for any Cosmos chain could perform this role.

For example, the ixo chain would register "ixo" so that did:cosmos:ixo:tokens:abc123 resolves to the DID Document returned by the IID resolve interface on ixo's tokens module (which is running on the ixo application chain). Ixo's module controls the namespace in which abc123 is defined and renders a DID Document to communicate how to interact securely with that token.

In the same way—after the Hub's IID module is deployed— any Cosmos module will be able to register its namespace (and provide an IID interface) and immediately have its own DID namespace under the Cosmos method.

IBC and IIDs
For routing to IIDs and resolving IID Documents across IBC, some form of chain registry module (as currently being discussed by the UX Working Group) will need to be implemented to manage chain-module namespaces.

A Hub IID Module could potentially be a candidate to provide this chain nameservice functionality.

3. IID Module in Cosmos SDK

An IID Module for the Cosmos SDK will provide a reference implementation of the IID Interface, which can be used by any application chain module to access standard IID helper functions and services. Such as an IID generator which returns did:cosmos conformant IIDs and an IID Resolver which returns an IID Document in the DID-standard JSON-LD format.

This module will streamline the process of enabling IID support in any module that manages on-chain assets.

Discussion welcome.

[MikeSofaer]

Is there a communal parallel lookup table to figure out how to route cosmos:ixo or is each chain responsible for knowing?

[jandrieu]

Our proposal is for a module on the hub that maintains the routing information so that did:cosmos:ixo gets to the ixo chain and did:cosmos:regen gets to the Regen network, etc.

Note that any chain can already define their own DID Method and publish it; this option remains, so did:ixo or did:regen remain options for those who want to go to the trouble.

The idea of the hub namespace module is to enable a did:cosmos method that can be defined & published once and usable for any Cosmos chain, letting anyone using the SDK to bootstrap an IID method with minimal fuss.

[MikeSofaer]

Next question: This reminds me a lot of https://www.w3.org/TR/wsdl/ have you read through that for possible insights from earlier travelers?

[jandrieu]

Yes. The ws* stack is a storied part of the user-centric identity movement. Many of the concepts developed for JSON and JSON-LD identity and credential interchanges were a direct result of a desire to move beyond the XML-based approaches of SOAP and WSDL.

Both Verifiable Credentials and Decentralized Identifiers were/are being standardized at the World Wide Web Consortium, the same organization that standardized WSDL. I think its fair to say that the DID service specification is building on the decade+ worth of lessons learned.

[aaronc]

Are IID's intended to represent both tokens and accounts, or just tokens?

[ig-shaun]

Using IIDs for Accounts is a powerful construct.

As Joe has already commented, this allows for versatile account control mechanisms that could be useful for a large range of use-cases. For instance, IIDs include formal control mechanisms for performing CRU(D) operations on account configurations and metadata. These can be used for anything from setting 'also known as' human readable account identifiers, to rotating key material.

The utility of an account can be extended to allow a range of different verification relationships and methods, for functions such as encryption, authentication, authorisation, capability delegation and capability invocation. These methods could include both the internally processed cryptographic functions built into Tendermint/Cosmos, and functions which can be processed through external services. Which could make IID-enabled Cosmos accounts really useful for an extended range of applications.

For instance, Group Accounts can be defined with an array of Controller properties, or allow the use of alternative cryptographic schemes, such as Schnorr Signatures which can privately encode conditional logic for aggregated keys, such as 'x of y' multi-sig, or logical operations using MuSig which can attach encumbrances to aggregated keys, off-chain.
It would be interesting to further explore how this approach could be used for Interchain Accounts.

Associating any number any types of services with an IID-enabled account, provides a configurable way of defining the purpose and applications for an account type. For instance, affording an account access to a lending service, when required credentials are presented. These services can extend to off-chain services, such as accessing confidential data.

The real power of this approach is that we could build a comprehensive object capabilities model into accounts, for instance using zCaps (authorisation capabilities) which can be issued and delegated off-chain and include caveats to configure contextual conditional logic into account functions. Though this would require further exploration of the feasibility of zCaps as an (optional) Auth model for Cosmos.

[aaronc]

Thanks @jandrieu and @ig-shaun. So I get the idea of using DID for accounts. Extending DIDs to describe tokens/digital assets seems like a stretch. They are not "agents" which are able to perform actions on their own like accounts/identities. Can you explain the rationale for describing tokens with DIDs?

[jandrieu]

Sure.

DIDs are designed to refer to anything, not just active entities. https://w3c.github.io/did-core/#abstract

A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID.

There is active debate over how broadly that makes sense. There are those who use DIDs to refer to static content, in the manner of a CID, such as did:schema https://github.com/51nodes/schema-registry-did-method/blob/master/README.md

Or, did:key which simply refers to a key pair that could be used for any number of purposes. https://w3c-ccg.github.io/did-method-key/

Conceptually, did:key is used to refer to a Subject, often meaning the party who controls the private key, but the actual real-world physical entity may never be formally identified. Such a binding should only be believed in limited contexts where one can believe the assumptions about who controls the private key are still valid. This means that while we often think of a did:key as referring to a Subject other than the keypair itself, the functional reality is that did:key only every refers to a control structure, which in the right context, can be used as a referent to the Subject.

One way to think about this is inverse of the slippery merge that happens when our own self-awareness expands to take the shape of the tools we use. We say "I got hit by a car the other day" when a more rigorous statement might be "My car got hit by another car the other day while I was driving it". We refer to the car as if it is "me", yet, in most contexts its understood that the car got hit. With DIDs, that is the equivalent of bootstrapping a DID that we prove control over, then using that DID to gather assertions and authorizations issued to that DID on our behalf. Then that DID ends up understood to refer to the physical person, but the underlying guarantees only prove the control structure is satisfied. That's a particularly slippery notion when you need to be rigorous, but treating a particular did:key as if it refers to a specific person is often sufficient for many applications.

Personally, I'm not a fan of DID methods that can't be used to prove control over the identifier (did:schema and other CIDs are like that), but there is a growing awareness that the binding of a DID to a real-world entity is a problem that is only ever solved in context for a reasonable timeframe--whereas the control structure is context-free: if you can satisfy the verification methods, you can act on behalf of that DID.

The important shift, from a privacy perspective, is that people aren't uniquely identified by DIDs. Rather, people use the control structure of DIDs to demonstrate they have access to a secret that only the controller should have access to. Any given entity will use a myriad of DIDs to bootstrap secure interactions, using different DIDs in different contexts for different purposes. Any one of those DIDs could be viewed as "the" DID of the entity (in that context at least), but none of them are definitive across all contexts: any DID could be used by any entity that controls its cryptographic secrets. Which is to say, best practice use of DIDs moves beyond the initial blush idea that DIDs refer to people.

It is this separation of the control structure from the subject that enables GDPR compliant ledger-based DIDs. And, sadly, some DID initiatives completely misunderstand this and imagine establishing a global directory of DIDs that permanently, irrevocably refer to one and only one person uniquely, somehow manufacturing a sybil-resistant personnel directory. This notion of DIDs == a person is an anti-pattern that would prevent such identifiers from being stored on an immutable ledger (because you need to be able to delete such identifiers for GDPR compliance).

When we started looking at how DIDs might help with NFTs, it immediately jumped out that tokens themselves are conceptual entities with built-in control structures that could be exposed via DID Documents. The verification methods of the "owner" address become the verification methods used in the token DID Document (the IID Document in our proposal). This allows the token owner to interact as the token owner with various digital systems without revealing any additional identity information: the details are fully expressed in the IID Document.

Hopefully that helps fill in some blanks.

[MikeSofaer]

This is super helpful, thank you!

[ig-shaun]

@aaronc the IID Spec RFC-009 provides the rationale for identifying tokens with IIDs. In summary, this achieves three main objectives:

1. IIDs provide token assets with a URI which locates a token asset class or instance within the chain namespace. This resolves the non-conformity of CAIP-19 format identifiers which are not fully-formed URLs. We are starting to see adoption of using DIDs to identify tokenised assets - such as the did:nft method spec from Ceramic Network for ERC721 tokens.
2. IIDs provide a standard for associating metadata with a token class or instance, with all the necessary control functions. The principle of describing a token with metadata, rather than a Denom (which has limitations such as not being localised), is already gaining traction in Ethereum with EIP-1155. This Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.
3. Enables configurability, such as defining the token services which apply to specific class of tokens, in the absence of smart contract configurability in Go modules.

[aaronc]

This proposal is somewhat related to IID's although it doesn't attempt to leverage DIDs: #9156 (comment). DIDs to me make sense when there is some authentication involved. The URIs I'm proposing above simply relate to identifying any on-chain entity.