{"id":13567275,"url":"https://github.com/cosmos/did-cosmos","last_synced_at":"2026-02-27T00:02:54.960Z","repository":{"id":42368383,"uuid":"479002283","full_name":"cosmos/did-cosmos","owner":"cosmos","description":null,"archived":false,"fork":false,"pushed_at":"2022-07-19T09:24:31.000Z","size":17,"stargazers_count":3,"open_issues_count":0,"forks_count":2,"subscribers_count":7,"default_branch":"main","last_synced_at":"2025-04-12T06:48:16.946Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cosmos.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2022-04-07T13:41:03.000Z","updated_at":"2022-10-28T14:35:53.000Z","dependencies_parsed_at":"2022-08-12T09:51:40.551Z","dependency_job_id":null,"html_url":"https://github.com/cosmos/did-cosmos","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cosmos%2Fdid-cosmos","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cosmos%2Fdid-cosmos/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cosmos%2Fdid-cosmos/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cosmos%2Fdid-cosmos/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cosmos","download_url":"https://codeload.github.com/cosmos/did-cosmos/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248530606,"owners_count":21119595,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T13:02:27.360Z","updated_at":"2026-02-27T00:02:49.941Z","avatar_url":"https://github.com/cosmos.png","language":null,"funding_links":[],"categories":["Misc"],"sub_categories":[],"readme":"# did:cosmos Method Specification\n\nThis document defines the syntax, data model, and operations for the **did:cosmos** DID method.\n\n**Authors** :\n\n* **Joe Andrieu** \u0026lt;\u003ca href=\"mailto:joe@legreq.com\"\u003ejoe@legreq.com\u003c/a\u003e\u0026gt;\n* **Lohan Spies** \u0026lt;\u003ca href=\"mailto:lohan.spies@ixo.world\"\u003elohan.spies@ixo.world\u003c/a\u003e\u0026gt;\n* **Shaun Conway** \u0026lt;\u003ca href=\"mailto:shaun.conway@ixo.world\"\u003eshaun.conway@ixo.world\u003c/a\u003e\u0026gt;\n\nThis specification is under active development at [https://github.com/interchainio/did-cosmos](https://github.com/interchainio/did-cosmos).\n\n## Abstract\n\n**did:cosmos** is an IID method designed to refer to Cosmos-compatible on-chain assets.\n\nInterchain Identifiers (IIDs) [[1]](#ref1) are a family of Decentralized Identifier methods which are purpose-designed to identify, refer to, and interact with digital assets within blockchain namespaces.\n\nThe IID specification builds on the Decentralized Identifier (DID) Core specification from the World Wide Web Consortium (W3C) [[2]](#ref2). IIDs are fully conformant DIDs and therefore are DIDs. IID Documents are DID documents. Unlike DIDs, IIDs only reference on-chain assets—which we will refer to as tokens—but should be taken as any type of tokens, such as NFTs, fungible tokens, tokenized namespace records, or other on-chain assets.\n\nRestricted to on-chain assets, IIDs are a new class of identifier uniquely suited to the requirements of fungible tokens, non-fungible tokens, and other chain-native components. IID methods can be developed for any compatible blockchain, making them suitable for interoperable representations of assets (and the cryptography that secures those tokens) regardless of the underlying chain.\n\nThis particular specification, **did:cosmos** applies the IID approach to assets on blockchains made with the Cosmos SDK.\n\nIIDs also introduce a few new features—conformant extensions to the DID Core specification—that provide for privacy-respecting options for the full range of expected token functionality, including Linked Resources, On-chain Service Endpoints, and Accorded Rights. We describe those here, capturing their definition at the time this specification was developed. See the IID specification for current normative definitions.\n\nDID Methods which conform to the IID specification resolve to a DID document representing how to securely interact with a uniquely identified digital asset, within a unique blockchain namespace. Because IIDs are DIDs, software applications that are conformant with the W3C specification will be able to inter-operate with IIDs and IID documents, although some IID-specific features may require additional tooling.\n\n**did:cosmos** DIDs are IIDs intended identify assets on Cosmos application chains.\n\n## Architecture Overview\n\nIn the Cosmos ecosystem, **application chains** are sovereign blockchains built using the Cosmos SDK. These application chains are comprised of various modules, which perform different functions. We refer to modules that manage the state of on-chain assets as **asset modules**.\n\nTo support **did:cosmos**, three modules must be operational: a **chain registry**, a **namespace registry**, and an **asset module**.\n\n```mermaid\nclassDiagram\n    class ChainRegistry\n    ChainRegistry : -chainDescriptors\n    ChainRegistry : +getChainDescriptor(chainspace)\n    ChainRegistry : +setChainDescriptor(chainDescriptor)\n\n    class NamespaceRegistry\n    NamespaceRegistry : -namespaceDescriptors\n    NamespaceRegistry : +getNamespaceDescriptor(namespace)\n    NamespaceRegistry :+setNamespaceDescriptor(namespaceDescriptor)\n\n    class AssetModule\n    AssetModule : -assets\n    AssetModule : +getDidDocument(DID)\n    AssetModule : +createAsset(assetDescriptor)\n    AssetModule : updateAsset(assetDescriptor)\n    AssetModule : deactiveAsset(DID)\n```\n\n**Chain Registry** Maintains a set of chain descriptors which describe how to access particular application chains, indexed by chainspace.\n\n**Namespace Registry** Maintains a set of namespace descriptors which describe how to access particular asset modules, indexed by namespace.\n\n**Asset Module** Maintains on-chain assets, with its own module-specific functions for creating, updating, and deactivating assets. Each Asset Module MUST also support a method for retrieving the DID Document for a given asset, given a DID managed by that module.\n\nThe role of each of these modules is further described below.\n\n## did:cosmos Syntax\n\nAn example `did:cosmos` method identifier is `did:cosmos:version:chainspace:namespace:unique-id`.\n\nThere are four forms of did:cosmos DIDs:\n\n```abnf\ndid:cosmos:version:chainspace:namespace:unique-id\ndid:cosmos:chainspace:namespace:unique-id\ndid:cosmos:version:chainspace\ndid:cosmos:chainspace\n```\n\nIn short, you must have a chainspace, but the version and asset-id are optional.\n\n### did:cosmos ABNF\n\n```abnf\ndid-cosmos          = \"did:cosmos:\" method-specific-id\nmethod-specific-id = [version \":\"] chainspace [\":\" asset-id]\nversion            = 1*DIGIT\nchainspace         = ALPHA *id-char\nasset-id           = namespace \":\" unique-id\nnamespace          = *id-char\nunique-id          = *( *idchar \":\" ) 1*id-char\nid-char             = ALPHA / DIGIT / \".\" / \"-\" / \"_\" / pct-encoded\npct-encoded        = \"%\" HEXDIG HEXDIG\n```\n\n### Method Name\n\nA DID that uses this method MUST begin with the prefix `did:cosmos`. The prefix string MUST be in lowercase.\n\n### Method Specific Identifier\n\nThe `did:cosmos` method-specific identifier (`method-specific-id`) is made up of a `version`, `chainspace` and a `asset-id` component.\n\nThe `version`, if present, MUST be an integer that identifies a specific version of `did:cosmos` method operations such as\ncreate, read, update, and deactivate. The version number increases by one for each breaking change in the specification, enabling future enhancements to the specification while retaining backwards compatibility for long-lived identifiers.\n\nIf `version` is not present, it MUST be assumed to be version 1, the set of operations defined in this initial version of the specification. Later versions will refer to operations defined in a future version of this specification. Note that the version refers to the set of operations, not the version of the specification.\n\nImplementers SHOULD maintain compatibility with all existing versions likely to be in use. For application chains that identify assets using did:cosmos, this means supporting the version that was current when the chain first adopted did:cosmos functionality, as well as all subsequent versions if possible. DID resolvers--which may be off-chain--will likely need to maintain support for all versions until convinced there are no outstanding DIDs using that version. Software which is asked to handled a version # that it does not support MUST return an error.\n\nThe `chainspace` is defined as a string that identifies a specific Cosmos blockchain (e.g. \"ixo\", \"regen\", \"cosmos\") where the DID reference is stored. It must begin with an alphabetic character so parsers can distinguish between the `version` component and the `chainspace` component. Thereafter, it may contain any alpha numeric character.\n\nThe `asset-id`, if present, MUST be a unique identifier for the particular on-chain asset hosted on the blockchain defined by `chainspace`. It is comprised of a `namespace` and a `unique-id`.\n\nThe `namespace` is an alphanumeric string that identifies a distinct namespace managed by the application chain's name server module. These namespaces, e.g., \"nft\", \"bank\", \"staking\", identify where the on-chain asset is maintained on that particular chain. It is used to route incoming resolution requests to the correct asset module.\n\nThe `unique-id` is mixed character string that uniquely identifies an asset managed by the application chain under the namespace defined by the `namespace` component. The asset module that handles each namespace MUST enforce uniqueness so that one and only one asset under that module's control is associated with each `unique-id`. To facilitate off-chain creation of did:cosmos DIDs, prior to creating an on-chain asset, the `unique-id` MUST be a representation of a Secp256k1 public key as encoded for did:key \u003chttps://w3c-ccg.github.io/did-method-key/#secp256k1\u003e based on the multibase and multicodec methods: ```multibase(multicodec(public_key))\n\nIf `asset-id` is missing, then the DID refers to the chainDescriptor maintained by the chain registry rather than an asset maintained by an asset module.\n\nFor example, `did:cosmos:ixo` refers to the chain descriptor associated with the \"ixo\" chain space in the chain registry.\n\n### did:cosmos DID-URL syntax\n\n**did:cosmos** DIDs may also be used in DID-URLs, based on [RFC5234](https://www.w3.org/TR/did-core/#bib-rfc3986)\n\n```abnf\ncosmos-did-url      = cosmos-did [path-abempty] [ \"#\" fragment ]\npath-abempty  = *( \"/\" segment )\nsegment       = *pchar\nsegment-nz    = 1*pchar\nsegment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / \"@\" )\npchar         = unreserved / pct-encoded / sub-delims / \":\" / \"@\"\nfragment    = *( pchar / \"/\" / \"?\" )\n```\n\nNOTE: **did:cosmos** does not support `query` parts. The path and fragment parts are defined below.\n\n## Adding support for did:cosmos\n\nTo support `did:cosmos`, any Cosmos application chain MUST add an entry in the Cosmos Chain Registry [[3]](#ref3). Each network, such as \"mainnet\" or \"testnet\" are independent entries in the registry with unique chain names and separate chain definition files, called`chain.json`. Each `chain.json` MUST provide all of the information required for connecting to that network. The `chain_name` MUST be used to as the `chainspace` string in the `did:cosmos` method. The `chain-id` contained in the `chain.json` will be used to identify the correct Cosmos blockchain network to connect to.\n\nThe Cosmos Chain Registry is the source of valid `chainspace` values and can be programmatically queried via an API [[4]](#ref4).\n\nFor each Cosmos blockchain there MUST be an entry in the [Cosmos Chain Registry](https://github.com/cosmos/chain-registry) that includes a file called `chain.json`. The chain registry's chain descriptors will point to the appropriate source for its chain.json file.\n\nThe `did:cosmos` method supports offline creation of DIDs. Any valid Secp256k1 public key may be used to identify a did:cosmos asset. To support this, each asset module must allow the assignment of an assetID at creation. It SHOULD use a message format that includes a signature using the associated private key to establish the initial control over that key. If an asset module is called to create an asset with an asset-id already associated with an asset under its control, it MUST be rejected.\n\nDuring resolution, resolvers MUST first check on-chain to see if a given identifier is registered with the asset module. If that returns an \"identifier not found\" error, it must generate a minimalist deterministic DID document using the algorithm defined for did:key, but retaining the full did:cosmos DID as its identifier.\n\nNote that to support this functionality, the chain registry--which is itself an asset module managing the chainspace descriptors--exposes two functions which refer to the same asset:\n\n* getDidDocument(`did:cosmos:hub:chainregistry:abc123`) -- returns the DID document for controlling that chain descriptor.\n* getChainDescriptor(`did:cosmos:ixo`) -- returns the chain descriptor file associated with the \"ixo\" chainspace.\n\n### Examples of `did:cosmos` identifiers\n\nA DID written to the ixo Impact Hub Cosmos Blockchain network \"NFT\" `namespace`:\n\n```abnf\ndid:cosmos:1:ixo:nft:7Tqg6BwSSWapxgUDm9KKgg\n```\n\nA DID written to the Regen Cosmos Blockchain network \"NFT\" `namespace`:\n\n```abnf\ndid:cosmos:1:regen:ecocredit:1Kpg3KJPOIarthPWf8HHyy\n```\n\nA DID written to the Regen `Testnet` Cosmos Blockchain network \"NFT\" `namespace`:\n\n```abnf\ndid:cosmos:1:regentest:ecocredit:1Kpg3KJPOIarthPWf8HHyy\n```\n\nA DID URL on the ixo Impact Hub Cosmos Blockchain network \"NFT\" `namespace` for retrieving a specific IID Linked Resource using a `path`:\n\n```abnf\ndid:cosmos:1:ixo:nft:7Tqg6BwSSWapxgUDm9KKgg/myresource\n```\n\nA DID written to the ixo Cosmos Blockchain network \"NFT\" `namespace` referencing a specific IID Linked Resource `fragment`:\n\n```abnf\ndid:cosmos:1:ixo:nft:7Tqg6BwSSWapxgUDm9KKgg#myresource\n```\n\n## DID documents\n\nA DID document associated with a **did:cosmos** DID is a set of data describing an on-chain asset. The representation of a **did:cosmos** DID document MUST meet the DID Core specifications [[5]](#ref5).\n\n### Properties defined for all W3C specification compliant DID documents\n\n1. **`@context`** (mandatory): The serialized value of @context MUST be the JSON String `https://www.w3.org/ns/did/v1`, or a JSON Array where the first item is the JSON String `https://www.w3.org/ns/did/v1` and the subsequent items are serialized according to the JSON representation production rules. (This also requires the IID context, described in the following section.)\n2. **`id`**: A **did:cosmos** DID as defined in this document.\n3. **`controller`** (optional): A list of fully qualified DID strings or one string. Contains one or more DIDs whose verification relationships MUST be considered valid for this DID.\n4. **`verificationMethod`** (optional): A list of Verification Methods\n5. **`authentication`** (optional): A list of strings with key aliases or IDs\n6. **`assertionMethod`** (optional): A list of strings with key aliases or IDs\n7. **`capabilityInvocation`** (optional): A list of strings with key aliases or IDs\n8. **`capabilityDelegation`** (optional): A list of strings with key aliases or IDs\n9. **`keyAgreement`** (optional): A list of strings with key aliases or IDs\n10. **`service`** (optional): A set of Service Endpoint maps\n11. **`alsoKnownAs`** (optional): A list of strings. A DID subject can have multiple identifiers for different purposes, or at different times. The assertion that two or more DIDs refer to the same DID subject can be made using the `alsoKnownAs` property.\n\n### Verification method\n\nVerification methods are used to define how to authenticate / authorise interactions with a DID subject or delegates. Verification method is an OPTIONAL property.\n\n1. **`id`** (string): A string with format `did:cosmos:impacthub:\u003cchainspace\u003e:\u003cnamespace\u003e#\u003ckey-alias\u003e`\n2. **`controller`**: A string with fully qualified DID. DID must exist.\n3. **`type`** (string)\n4. **`publicKeyJwk`** (`map[string,string]`, optional): A map representing a JSON Web Key that conforms to RFC7517 [[7]](#ref7). See definition of `publicKeyJwk` for additional constraints.\n5. **`publicKeyMultibase`** (optional): A base58-encoded string that conforms to a MULTIBASE [[8]](#ref8)\nencoded public key.\n\n**Note**: Verification method cannot contain both `publicKeyJwk` and `publicKeyMultibase` but must contain at least one of them.\n\n#### Example of Verification method in a DID document\n\n```jsonc\n{\n  \"id\": \"did:cosmos:1:impacthub:nft:abc123#key-0\",\n  \"type\": \"JsonWebKey2020\",\n  \"controller\": \"did:cosmos:1:impacthub:nft:abc123\",\n  \"publicKeyJwk\": {\n    \"kty\": \"OKP\",\n    // external (property name)\n    \"crv\": \"Ed25519\",\n    // external (property name)\n    \"x\": \"VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ\"\n    // external (property name)\n  }\n}\n```\n\n### Service\n\nServices can be defined in a DID document to express means of communicating with the DID subject or associated entities.\n\n1. **`id`** (string): The value of the `id` property for a Service MUST be a URI conforming to RFC3986 [[9]](#ref9). A conforming producer MUST NOT produce multiple service entries with the same ID. A conforming consumer MUST produce an error if it detects multiple service entries with the same ID. It has a follow formats: `\u003cdid-document-id\u003e#\u003cservice-alias\u003e` or `#\u003cservice-alias\u003e`.\n2. **`type`** (string): The service type and its associated properties SHOULD be registered in the DID Specification Registries [[10]](#ref10)\n3. **`serviceEndpoint`** (strings): A string that conforms to the rules of RFC3986 [[9]](#ref9) for URIs, a map, or a set composed of a one or more strings that conform to the rules of\nRFC3986 for URIs and/or maps.\n\n### Additional Properties\n\nIn addition to the properties defined in DID Core, the following properties are defined for **did:cosmos**.\n\n#### Context\n\nAs an IID, **did:cosmos** DID documents MUST include `https://w3id.org/earth/NS/iid/v1` as a context value, following the default DID context:\n\n```json\n\"@context\" : [\n   \"https://www.w3.org/ns/did/v1\",\n   \"https://w3id.org/earth/NS/iid/v1\"\n]\n```\n\n#### Linked Resources\n\n`linkedResource` (optional) : property provides a privacy-enabled way to attach digital resources to an on-chain asset. This is an optional property which may contain one or more resource descriptors in an array. This property provides the metadata required for accessing and using the specified resource, such as the type of resource, a proof to verify the resource, and a service endpoint for requesting and retrieving the resource.\n\nResources may be provided in-line or by secure reference. Inline resources are appropriate only for use cases that need to directly include the resource in the IID Document. In many cases, this is a privacy problem. However, for some use cases, resources must be specified for on-chain execution, which justifies the added bytes and potential disclosure risk. The resource descriptor provides for a flexible representation of various mime types, compression, and encoding, as required for the use.\n\nResources may be secured by specifying a `proofType` of hash or hashgraph. A hashgraph uses a merkle tree of hashes for external content associated with this asset. A resource descriptor of this type obscures both the type and the number of such resources, while allowing each such resource to be verifiably linked to the asset. It also provides for privacy-respecting verification of complete disclosure. Anyone who needs to prove they have all of the linked resources can compare their own hash graph of resources with the value stored in the IID Document. Note this anti-censorship technique requires a verifier to discover the type and nature of those resources on their own.\n\nProposed properties for resource descriptors in the `LinkedResource` property:\n\n```javascript\n{\n \"linkedResource\": [{\n\n  \"path\"(optional): // IID Resource path for this resource in the asset namespace, e.g., /myResource.png\n\n   \"id\"(optional): // IID Reference ID for this resource, e.g., #myResource.png\n\n   \"rel\"(optional): // the relationship of this resource to the IID Asset\n\n   \"type\": \"nft:ResourceDescriptor\", // The JSON-LD type of this resource\n\n  \"proof\": [ // an array of proofs, any of which may be used\n   {\n    \"type\"(optional): \"hash\" | \"hashgraph\" | \"hashset\" // the form of proof used to verify the resource as authentic\n    \"stage\"(optional): \"raw\" | \"compressed\" | \"encrypted\" | \"encoded\" // the \n    \"value\"(optional): hash | hashgraph | hashset, // the actual proof for this particular resource\n   }\n  ],\n  \"resourceFormat\": media type, // the IANA media-type of the linked resource\n\n  \"compression\"(optional): \"gzip\" | \"none\", // the compression (performed on the raw resource) of an inline resource\n\n  \"encryption\": [open ended\n   for arbitrary extensibility\n  ], // the encryption technique applied after compression and before encoding\n\n  \"encoding\"(optional): \"native\" | \"multibase\" | \"string\", // the encoding (after compression and encryption) of an inline resource; \"native\" means the inline resource is native JSON-LD with neither compression nor encryption\n\n  \"endpoint\"(optional): url, // a URL at which this resource can be retrieved before decrypting and decrompressing\n\n  \"resource\"(optional): \"...\"\n  a representation of the resource\n  for inline\n  distribution,\n  encoded as per \"encoding\"\n    }]\n}\n```\n\n#### Transcludes\n\n**`transclude`** (optional): is a new IID document property for specifying where in an IID document to transclude a linked resource. If present, the value of this property MUST be one (or an array of more than one) Linked Resources that eventually dereferences to a raw JSON-LD object. The properties of that JSON-LD object will be injected into the current IID document, replacing the transclude property entirely. The properties of the transcluded JSON-LD MUST be transformed to their absolute representation using the object's `@context` value prior to transclusion. The associated linked resources MUST have a `rel` value of \"extension\" and a `mediaType` value of \"application/ld-json\"\n\n#### Extension\n\n**`extension`** (optional): a type of Linked Resource. A JSON-LD extension of the current document. The RDF statements in the extension are to be included in the current IID document, where specified by a \"transclude\" property. For example, additional service endpoint definitions may be added in a linked resource. These endpoints can be verified as being associated with the IID. But only by those parties who secure the definitions through other privacy respecting mechanisms. This property standardizes how to verifiably move arbitrary RDF statements outside of the IID document context, to provide additional security and privacy.\n\n#### Executable Rights\n\n**`executableRight`** (optional): a type of Linked Resource. This resource is a machine-executable capability that can be invoked by the IID owner or its delegate, using cryptographic materials defined elsewhere in the IID document Verification Methods property.\n\n#### Assertion\n\n**`assertion`** (optional): a rel value for a Linked Resource. Verifiable credentials, verified claims, claim tokens as described in NFT-RFC-008 [[6]](#ref6). This allows arbitrary, yet verifiable attestations to be made either about the asset or about the resources defined by IID references. The attributes represented in these claims can be retrieved through the token interface using a Query by Example. (graph query) mechanism.\n\n#### Rel\n\n**`rel`** (optional): a property of Linked Resource. Defines the relationship of this resource to the IID asset. Known values include:\n     1. \"evidence\" -- The resource is evidence for the creation of the asset.\n     2. \"encodedRepresentation\" -- The resource is a binary representation of the asset, interpretable by compatible software to display or interact with.\n     3. \"visualRepresentation\" -- The resource is a visual representation of the asset\n\n#### Accorded Rights\n\n**`accordedRight`** (optional): a type of relationship to a Linked Resource. Specifies the rights accorded to the IID owner, or its deligate, which may be executed by physical-world institutions or processes. Such as a digital driver's license according certain rights to drive, or a theater ticket according access to a show. The representation framework for such rights must be non-prescriptive, including both plain text statements of rights, e.g., \"The controller of this IID is entitled to ...\", or more rigorous and computationally evaluatable RDF statements, which might describe in great detail a range of benefits that accompany the basic rights of the token.\n\n#### Display Name\n\n**`displayName`** (optional): a property of Linked Resources that provide a brief textual label for display.\n\n#### Display Description\n\n**`displayDescription`** (optional): a property of Linked Resources that provide a longer text phrase for displaying additional detail about the asset.\n\n#### Display Icon\n\n**`displayIcon`** (optional): a property of Linked Resources that provide a URL for an image asset to use when displaying the asset.\n\n#### State format for DID documents on ledger\n\nConsider the following example minimum DID document from DID Core:\n\n#### EXAMPLE 1: A minimal DID document (JSON-LD)\n\n(not a did:cosmos did document, shown for comparison)\n\n```json\n{\n\n\"@context\": \"https://www.w3.org/ns/did/v1\",\n\n\"id\": \"did:example:abc123\",\n\n\"authentication\": [{\n\n  \"id\": \"did:example:abc123#keys-1\",\n\n  \"type\": \"Ed25519VerificationKey2020\",\n\n  \"controller\": \"did:example:abc123\",\n\n  \"publicKeyMultibase\": \"zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"\n\n  }]\n\n}\n```\n\nThis minimal DID document is fully conformant with the specification and includes a single verification relationship and method: how to authenticate on behalf of the DID Subject.\n\nIt is useful to note that Verification Methods can be anything\\*, e.g., ed25519, secp256k, etc.\n\nAn equivalent example of minimal IID document would be:\n\n#### EXAMPLE 2: A minimal IID document (JSON-LD)\n\n```json\n{\n\"@context\" : [\n   \"https://www.w3.org/ns/did/v1\",\n   \"https://w3id.org/earth/NS/iid/v1\"\n],\n\n\"id\": \"did::cosmos:1:impacthub:nft:abc123\",\n\n\"authentication\": [{\n\n  \"id\": \"did:cosmos:1:impacthub:nft:abc123i#keys-1\",\n\n  \"type\": \"Ed25519VerificationKey2020\",\n\n  \"controller\": \"did:cosmos:1:impacthub:nft:abc123\",\n\n  \"publicKeyMultibase\": \"zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"\n\n  }]\n\n}\n```\n\nFinally, an example using LinkedResources for privacy-respecting linking of external resources.\n\n#### EXAMPLE 3: A minimal, privacy-preserving IID document (JSON-LD)\n\n```json\n{\n\n  \"@context\" : [\n   \"https://www.w3.org/ns/did/v1\",\n   \"https://w3id.org/earth/NS/iid/v1\"\n  ],\n\n  \"id\": \"did:cosmos:1:impacthub:nft:abc123\",\n\n  \"authentication\": [{\n\n    \"id\": \"did::cosmos:1:impacthub:nft:abc123i#keys-1\",\n\n    \"type\": \"Ed25519VerificationKey2020\",\n\n    \"controller\": \"did:cosmos:1:impacthub:nft:abc123\",\n\n    \"publicKeyMultibase\": \"zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"\n\n  }],\n\n  \"service\": [{\n\n    \"id\":\"did:cosmos:1:impacthub:nft:abc123#mediator\",\n\n    \"type\": \"polymorphicMediator2021\",\n\n    \"serviceEndpoint\": \"http://8zd335ae47dp89pd.onion/iid/mediator/ did:example:abc123\"\n\n  }],\n\n\"linkedResource\" : [{\n\n    \"id\": \"did:cosmos:1:impacthub:abc123#resourceHashgraph\",\n\n    \"path\": \"did:cosmos:1:impacthub:nft:abc123/resourceHashgraph\",\n\n    \"type\": \"hashgraph\",\n  \n    \"proof\": \"afybeiemxf5abjwjbikoz4mcb3a3dla6ual3jsgpdr4cjr3oz\",\n\n    \"endpoint\" : \"did:cosmos:1:impacthub:nft:abc123?service=mediator\"\n\n  }]\n\n}\n```\n\n#### EXAMPLE 4: A privacy-preserving IID document with zCap support (JSON-LD)\n\n```json\n{\n\n  \"@context\": [\n    \"https://www.w3.org/ns/did/v1\",\n    \"https://www.w3id.org/earth/NS/iid/v1\"\n  ],\n  \"id\": \"did:cosmos:1:impacthub:nft:abc123\",\n\n  \"verificationMethod\": [{\n    \"id\": \"did:cosmos:1:impacthub:nft:abc123#keys-1\",\n    \"type\": \"Ed25519VerificationKey2020\",\n    \"controller\": \"did:cosmos:1:impacthub:nft:abc123\",\n    \"publicKeyMultibase\": \"zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV\"\n  }],\n\n  \"authentication\": \"did:cosmos:1:impacthub:nft:abc123#keys-1\",\n  \"capabilityDelegation\" : \"did:cosmos:1:impacthub:nft:abc123#keys-1\",\n  \"capabilityInvocation\" : \"did:cosmos:1:impacthub:nft:abc123#keys-1\",\n\n  \"service\": [{\n    \"id\":\"did:cosmos:1:impacthub:nft:abc123#mediator\",\n    \"type\": \"polymorphicMediator2021\",\n    \"serviceEndpoint\": \"http://8zd335ae47dp89pd.onion/iid/mediator/did:cosmos:1:impacthub:nft:abc123\"\n  }],\n\n\"linkedResource\" : [{\n    \"id\": \"did:cosmos:1:impacthub:nft:abc123#resourceHashgraph\",\n    \"path\": \"did:cosmos:1:impacthub:nft:abc123/resourceHashgraph\",\n    \"type\": \"hashgraph\",\n    \"rel\":\"attachments\",\n    \"proof\": \"afybeiemxf5abjwjbikoz4mcb3a3dla6ual3jsgpdr4cjr3oz\",\n    \"endpoint\" : \"did:cosmos:1:impacthub:nft:abc123?service=mediator\"\n  }]\n\n}\n```\n\n### JSON-LD\n\nAll did:cosmos serializations MUST use json-ld.\n\u003chttps://w3c.github.io/did-core/#json-ld\u003e\n\nThe DID document, DID document data structures, and representation-specific entries map MUST be serialized to the JSON-LD representation according to the JSON representation production rules as defined in § 6.2 JSON.\n\nIn addition to using the JSON representation production rules, JSON-LD production MUST include the representation-specific @context entry. The serialized value of @context MUST be a JSON Array where the first item is the JSON String `https://www.w3.org/ns/did/v1`, and the second item is the JSON string `https://www.w3id.org/earth/NS/iid/v1`.\n\n#### Example of Service in a DID document\n\n```jsonc\n{\n  \"id\":\"did:cosmos:1:impacthub:nft:abc123#linked-domain\",\n  \"type\": \"LinkedDomains\",\n  \"serviceEndpoint\": \"https://bar.example.com\"\n}\n```\n\n## DID operations\n\n**did:cosmos** DID and DID  documents are managed by a Cosmos-SDK module that uses the gRPC communication protocol. See the draft method specification [[11]](#ref11) for details on how create, read, update and delete (CRUD) operations are handled.\n\n### Create DID (Register)\n\n```mermaid\nsequenceDiagram\nDID Creator-\u003e\u003eAsset Module: Create asset\nAsset Module-\u003e\u003eApplication Chain: Create asset transaction with optional linked data\nApplication Chain-\u003eAsset Module: Asset registered with unique-asset-id and tx ID\nAsset Module-\u003e\u003eDID Registry: MsgCreateIdentifier(unique-assset-id string, internal-namespace-identifier string)\nDID Registry-\u003e\u003eApplication Chain: Lookup namespace from internal-namespace-identifier\nApplication Chain-\u003e\u003eDID Registry: Return namespace\nDID Registry-\u003e\u003eDID Registry: Generate did:cosmos method compliant DID\nDID Registry-\u003e\u003eAsset Module: Return fully-qualified did:cosmos method compliant DID. (did:cosmos:ixo:nft:1234567)\nAsset Module-\u003e\u003eAsset Module: Store DID? Assume it will need to be stored as part of the asset state to recreate DID document?\nAsset Module-\u003e\u003eDID Creator: Return DID to User for storage?\n\nNote over DID Creator, Asset Module: Or will the DID be regenerated together with the DID as and when required?\n```\n\nThe objective of the IID method is to allow any application developer to include the `did:cosmos` method in Cosmos modules. Most modules (e.g. NFT, bank, tx) already keep state and events related to assets created and managed by the module. IIDs can be created by any module as an additional capability to enrich assets and related information that exist on-chain and off-chain.\n\nAny developer is free to implement the 'did:cosmos' method as a DID and on-chain asset enrichment capability inside any Cosmos module.\nDID records created by various Cosmos module developers will be stored in an internal DID registry of the module as part of the module state. DID records can change state from trigger events by the linked asset.\n\nBelow is an example of create operation with the IID interface used by did:cosmos.\n\nThis operation creates a new DID using the did:cosmos method along with associated DID document representation.\n\nTo create and publish a local `chainspace` DID document use the message:\n\n```golang\nMsgCreateIdentifier(unique-id string, namespace string)\n```\n\nTo create and publish a remote `chainspace` DID document use the message:\n\n```golang\nMsgCreateIdentifier(unique-id string, namespace string, chainspace string)\n```\n\nIf the input DID is not a valid DID for the **did:cosmos** method, or if the DID already exists on-chain, the message returns an error.\n\n* **`unique-id`**: `MsgCreateIdentifier` unique asset ID inside a Cosmos module.\n* **`namespace`**: the relevant module that control the associated DID on-chain asset.\n* **`chainspace`**: the relevant Cosmos blockchain that the DID should be registered on.\n* **`controller, verificationMethod, authentication, assertionMethod, capabilityInvocation, capabilityDelegation, keyAgreement, service, alsoKnownAs, context`**: Optional parameters in accordance with DID Core specification properties.\n\n#### Client request format for create DID\n\n```jsonc\nWriteRequest (MsgCreateIdentifier(unique-id string, namespace string)\n```\n\n#### Example of a create DID client request\n\n```jsonc\nWriteRequest{\n        \"data\": MsgCreateIdentifier {\n                \"id\": \"1234567\",\n                \"namespace\": \"nft\"\n            }\n}\n```\n\n### Read DID (Resolve and Verify)\n\nExample flow for `did:cosmos:ixo:nft:12345`, an asset hosted by the NFT module on the ixo application chain.\n\n```mermaid\nsequenceDiagram\nautonumber\nUser-\u003e\u003eCosmos DID Registry: Resolve `did:cosmos:ixo:nft:12345`\nCosmos DID Registry-\u003e\u003eChain Registry: Lookup correct 'chainspace' value for `did:cosmos:ixo:nft:12345`\nChain Registry-\u003e\u003eCosmos DID Registry: Return route to ixo DID Registry \nCosmos DID Registry-\u003e\u003eUser: Route to ixo DID Registry\nUser-\u003e\u003eIxo DID Registry:  Resolve DID for `did:cosmos:ixo:nft:12345`\nIxo DID Registry-\u003e\u003eUser : Return route to ixo NFT module\nUser-\u003e\u003eixo NFT Module: Resolve DID for `did:cosmos:ixo:nft:12345`\nixo NFT Module-\u003e\u003eixo NFT Module: Construct DID document based on current chain state\nixo NFT Module-\u003e\u003eUser: Return DID document for DID `did:cosmos:ixo:nft:12345`\n```\n\nTo resolve did:cosmos method DID documents, the `QueryIdentifierDocument` operation fetches a response from the ledger. The integrity of the DID documents stored on the ledger is guaranteed by the underlying Cosmos blockchain protocol. DID resolution requests can be sent to the gRPC IID resolver interface for a node by passing the fully-qualified DID.\n\nA DID can be resolved using the gRPC message:\n\n```golang\nQueryIdentifierDocument(id string)\n```\n\nThe operation CAN be executed by anyone and is publicly available.\n\n* **`id`**: `QueryIdentifierDocument` should be a fully qualified DID of type `did:cosmos:\u003cchainspace\u003e:\u003cnamespace\u003e`. It MUST be the DID that is to be resolved. Allowed `chainspace` and `namespace` values are available in the Cosmos Chain Registry [[3]](#ref3)\n* **`metadata`**: Contains DID document metadata? `created`, `updated`, `valid`, `versionId`\n\nThe IID resolver is a public facing interface and will be exposed by installing the IID module in the Cosmos blockchain. The IID resolver will resolve down to the `namespace` to query for the DID document. This assume that Cosmos module developers using the `did:cosmos` method will need to implement a DID resolver internal to the module to fetch stored DID documents.\n\nThe operation MUST return the DID document and metadata if it exist in the Cosmos blockchain module.\n\n#### Client request format to resolve a DID to its DID document\n\n```jsonc\nWriteRequest QueryIdentifierDocument(id string)\n```\n\n#### Example of DID resolution to DID document client request\n\n```jsonc\nWriteRequest{\n        \"data\": QueryIdentifierDocument {\n                \"id\": \"did:cosmos:impacthub:nft:1234567\"\n        }\n}\n```\n\n### Update DID\n\nThis operation allow updates to DID documents by the controller(s).\n\nPlease note that the DID will remain the same, but the contents of the DID document could change, e.g., by including a new verification key or adding service endpoints.\n\nA DID can be updated using the gRPC message:\n\n```golang\nMsgUpdateIidDocument(id string, controller string, identifiers list, verificationMethods list, verificationRelationships list, service service, linkedResources list, accordedRights list)\n```\n\nThe operation MUST be executed by an authorized controller of the DID.\n\n* **`id`**: `MsgUpdateIidDocument` should be a fully qualified DID of type `did:cosmos:\u003cchainspace\u003e:\u003cnamespace\u003e`. It MUST be the DID that is to be deleted. Allowed `chainspace` and `namespace` values are available in the Cosmos Chain Registry][[3]](#ref3))\n* **`controller`**: should be a fully qualified DID of type `did:cosmos:\u003cchainspace\u003e:\u003cnamespace\u003e`.\n* **`identifiers, verificationMethods, verificationRelationships, service, linkedResources, accordedRights`**: Optional parameters in accordance with DID Core and IID specification properties.\n\nThe operation MUST update the DID document and metadata. The operation is not reversible.\n\n#### Client request format to update a DID document\n\n```jsonc\n\nWriteRequest MsgUpdateIidDocument(id string, controller string, identifiers list, verificationMethods list, verificationRelationships list, service service, linkedResources list, accordedRights list)\n```\n\n#### Example of update DID document client request\n\n```jsonc\nWriteRequest{\n        \"data\": MsgUpdateIidDocument {\n                \"id\": \"did:cosmos:impacthub:1234567\",\n        \"controller\": \"did:cosmos:impacthub:1234567\"\n        \"identifiers\": [],\n        \"verificationMethods\": [],\n        \"verificationRelationships\": [],\n        \"service\": service,\n        \"linkedResources\": [],\n        \"accordedRights\": []\n        }\n}\n```\n\n### Transfer DID\n\n```mermaid\nsequenceDiagram\nautonumber \nparticipant User\nparticipant Web Browser\nparticipant NFT DAPP\nparticipant Wallet\nparticipant Cosmos DID Registry (running on Cosmos Hub)\nparticipant Chain Registry API\nparticipant ixo DID Registry\nparticipant ixo NFT Module\n\nUser-\u003e\u003eWeb Browser: Go get an NFT\nWeb Browser-\u003e\u003eNFT DAPP: Browse NFTs\nNFT DAPP--\u003e\u003eWeb Browser: Show NFTs\nWeb Browser--\u003e\u003eUser: Display NFTs\nUser-\u003e\u003eWeb Browser: Buy NFT\nWeb Browser-\u003e\u003eNFT DAPP: Buy NFT\nNFT DAPP-\u003e\u003eCosmos DID Registry (running on Cosmos Hub): Resolve NFT IID\nCosmos DID Registry (running on Cosmos Hub)--\u003e\u003eNFT DAPP: Linked Resource Reference\nNFT DAPP-\u003e\u003eChain Registry API: Get chain definition\nChain Registry API--\u003e\u003eNFT DAPP: Return chain.json\nNFT DAPP-\u003e\u003eixo DID Registry: Resolve NFT IID\nixo DID Registry--\u003e\u003eNFT DAPP: Asset Module Reference\nNFT DAPP-\u003e\u003eixo NFT Module: Resolve NFT IID\nixo NFT Module--\u003e\u003eNFT DAPP: Return DID document\nNFT DAPP-\u003e\u003eNFT DAPP: Generate transfer transaction\nNFT DAPP-\u003e\u003eWeb Browser: Request tx signature\nWeb Browser-\u003e\u003eWallet: Request tx signature\nWallet-\u003e\u003eUser: Display Transaction Request\nUser--\u003e\u003eWallet: Approve Transaction\nWallet-\u003e\u003eWallet: Sign Transaction\nWallet--\u003e\u003eWeb Browser: Signed Transaction\nWeb Browser--\u003e\u003eNFT DAPP: Transfer signed transaction\nNFT DAPP-\u003e\u003eixo NFT Module: Transfer Ownership\nixo NFT Module-\u003e\u003eixo NFT Module: Update NFT owner on chain\nixo NFT Module--\u003e\u003eNFT DAPP: Transaction result\nNFT DAPP--\u003e\u003eWeb Browser: Transaction success\nWeb Browser--\u003e\u003eUser: Display NFT transfer success\n```\n\n### Revoke DID\n\nThis operation deactivates DID records using the did:cosmos method.\n\n### Deactivate DID\n\n```mermaid\nsequenceDiagram\nDID Controller-\u003e\u003eDID Registry: Deactivate DID\nDID Registry-\u003e\u003eDID Registry: set metadata attribute 'active = False'\nDID Registry-\u003e\u003eChain Registry: Lookup correct 'chainspace'\nChain Registry-\u003e\u003eDID Registry: Return 'chainspace' value\nDID Registry-\u003e\u003eApplication Chain: Write transaction to update DID status for 'chainspace'\nDID Registry-\u003e\u003eDID Controller: Confirmation of DID deactivation\n```\n\nA DID can be deactivated using the gRPC message:\nThe operation MUST be executed by an authorized controller of the DID.\n\n```golang\nMsgDeactivateIdentifier(id string, Controller string)\n```\n\n* **`id`**: `MsgDeactivateIdentifier` should be a fully qualified DID of type `did:cosmos:\u003cchainspace\u003e:\u003cnamespace\u003e`. It MUST be the DID that is to be deactivated. Allowed `chainspace` and `namespace` values are available in the Cosmos Chain Registry [[3]](#ref3)\n* **`controller`**: should be a fully qualified DID of type `did:cosmos:\u003cchainspace\u003e:\u003cnamespace\u003e`.\n\nThe operation MUST update the DID document metadata and set the Active value to False. The operation is not reversible.\n\n#### Client request format to deactivate a DID\n\n```jsonc\nWriteRequest MsgDeactivateIdentifier(id string, Controller string)\n```\n\nA DID can be deactivated using the gRPC message:\nThe operation MUST be executed by an authorized controller of the DID.\n\n```golang\nMsgDeactivateIdentifier(id string, Controller string)\n```\n\n#### Example of deactivate DID client request\n\n```jsonc\nWriteRequest{\n        \"data\": MsgDeactivateIdentifier {\n                \"id\": \"did:cosmos:impacthub:1234567\",\n        \"controller\": \"did:cosmos:impacthub:1234567\"\n        }\n}\n```\n\n## Security Considerations\n\n**did:cosmos** is designed for Cosmos compatible blockchains, which secure chain state using a proof-of-stake algorithm. Actively maintained and supporting hundreds of independent blockchains, Cosmos has a well-developed security process defined at [https://github.com/cosmos/cosmos-sdk/blob/master/SECURITY.md](https://github.com/cosmos/cosmos-sdk/blob/master/SECURITY.md).\n\nAll **did:cosmos** DIDs use Secp256k1 keys for initial asset creation and updates. This is the same cryptographic curve used by Bitcoin and Ethereum; it is largely considered secure.\n\nThe asset module on application chains is responsible for securing CRUD operations on the assets in manages. A thorough security review is recommended for any asset module.\n\n## Privacy Considerations\n\n### IIDs are designed to represent on-chain Assets, not people\n\nIIDs, e.g., did:cosmos:ixo:nft:1:abc are designed to represent on-chain assets, as such the identifier itself is never used to refer to real-world objects like people, with associated privacy requirements.\n\n### IID references may refer to people or orgainsations\n\nIID references, e.g., did:cosmos:ixo:nft:1:abc#creator may in fact be used to refer to real people and organizations. As such, care must be taken to ensure that any associated personal data be managed off chain with appropriate privacy mechanisms such as the ability to remove the data from public disclosure.\n\n### Linked Resources are designed to be privacy-agile\n\nIID references specified as Linked Resources offer several privacy-agile ways to associate the on-chain asset with arbitrary resources, providing a way for did:cosmos:ixo:nft:1:abc#creator to refer to an off-chain data store with the sensitive data. For example, an NFT's creator could be specified by a link and a hash to a Verifiable Credential (or a simple JSON file) that states the creator's name. Storing that name on-chain would create a regulatory problem. Linked Resources allow the information to be shared while ensuring the ability to honor requests for deletion.\n\n#### Example of a linked resource that references its creator\n\n```javascript\n\"linkedResource\" : {\n  \"id\" : \"#creator\",\n  \"path\": \"/creator\",\n  \"rel\":\"dc:creator\",\n  \"type\" : \"iid:ResourceDescriptor\",\n  \"proof\" : [{\n     \"type\": \"hash\",\n     \"stage\": \"encoded\",\n     \"value\" : \"bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi\"}],\n   \"resourceFormat\" : \"application/did+ld+json\",\n   \"compression\" : \"none\",\n   \"endpoint\": \"https://earthprogram.directory?listing=did:cosmos:ixo:nft:1:abc123#owner\"\n}\n```\n\nThe `linkedResource` property provides a privacy-enabled way to attach\ndigital resources to an on-chain asset. This is an optional property which\nmay contain one or more resource descriptors in array. This property provides the metadata required for accessing and using the specified resource, such as the type of resource, a proof to verify the resource, and a service endpoint for requesting and retrieving the resource.\n\nResources may be provided in-line or by secure reference. Inline resources are appropriate only for use cases that need to directly include the resource in the IID Document. In many cases, this is a privacy problem. However, for some use cases, resources must be specified for on-chain execution, which justifies the added bytes and potential disclosure risk. The resource descriptor provides for a flexible representation of various mime types, compression, and encoding, as required for the use.\n\nThis approach allows token owners to manage privacy in three key ways:\n\n1. Avoids posting potentially sensitive information on-chain in an unavoidably public and irrevocable manner.\n2. Provides a service endpoint that can apply appropriate privacy and security checks before revealing information.\n3. The hashgraph resource descriptor type obscures not only the content of the linked resource, but also the quantity of resource objects.\n\nResources may be secured by specifying a `proofType` of hash or hashgraph. A hashgraph uses a merkle tree of hashes for external content associated with this asset. A resource descriptor of this type obscures both the type and the number of such resources, while allowing each such resource to be verifiably linked to the asset. It also provides for privacy-respecting verification of complete disclosure. Anyone who needs to prove they have all of the linked resources can compare their own hash graph of resources with the value stored in the IID Document. Note this anti-censorship technique requires a verifier to discover the type and nature of those resources on their own.\n\n## References\n\n\u003ca name=\"ref1\"\u003e[1]\u003c/a\u003e Interchain Identifiers (draft specification).\nOnline at\n[[https://github.com/interNFT/nft-rfc/blob/main/nft-rfc-009.md]](https://github.com/interNFT/nft-rfc/blob/main/nft-rfc-009.md).\nAccessed March 31, 2022.\n\n\u003ca name=\"ref2\"\u003e[2]\u003c/a\u003e Decentralized Identifiers (DIDs) v1.0. World Wide Web Consortium.\nOnline at\n[[https://www.w3.org/TR/did-core/]](https://www.w3.org/TR/did-core/).\nAccessed February 15, 2021.\n\n\u003ca name=\"ref3\"\u003e[3]\u003c/a\u003e Cosmos Chain Registry.\nOnline at\n[[https://github.com/cosmos/chain-registry]](https://github.com/cosmos/chain-registry).\nAccessed February 05, 2022.\n\n\u003ca name=\"ref4\"\u003e[4]\u003c/a\u003e Cosmos Chain Registry API.\nOnline at\n[[https://registry.cosmos.directory/]](https://registry.cosmos.directory/).\nAccessed February 05, 2022.\n\n\u003ca name=\"ref5\"\u003e[5]\u003c/a\u003e DID Core DID document Representation Specification.\nOnline at\n[[https://www.w3.org/TR/did-core/#representations]](https://www.w3.org/TR/did-core/#representations).\n\n\u003ca name=\"ref6\"\u003e[6]\u003c/a\u003e NFT-RFC-008: NFT Resource Verification.\nOnline at\n[[https://github.com/interNFT/nft-rfc/blob/main/nft-rfc-008.md]](https://github.com/interNFT/nft-rfc/blob/main/nft-rfc-008.md).\n\n\u003ca name=\"ref7\"\u003e[7]\u003c/a\u003e RFC7517: JSON Web Key. IETF.\nOnline at\n[[https://tools.ietf.org/html/rfc7517]](https://tools.ietf.org/html/rfc7517).\n\n\u003ca name=\"ref8\"\u003e[8]\u003c/a\u003e The Multibase Data Format. IETF.\nOnline at\n[[https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03]](https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03).\n\n\u003ca name=\"ref9\"\u003e[9]\u003c/a\u003e RFC3986 Uniform Resource Identifier (URI): Generic Syntax. IETF.\nOnline at\n[[https://www.rfc-editor.org/rfc/rfc3986]](https://www.rfc-editor.org/rfc/rfc3986).\n\n\u003ca name=\"ref10\"\u003e[10]\u003c/a\u003e DID Specification Registries. W3C.\nOnline at\n[[https://www.w3.org/TR/did-spec-registries/]](https://www.w3.org/TR/did-spec-registries/).\n\n\u003ca name=\"ref11\"\u003e[11]\u003c/a\u003e Cosmos IID Module Specification.\nOnline at\n[[https://hackmd.io/1Nh-r80_SiyKvWzotvkTSQ]](https://hackmd.io/1Nh-r80_SiyKvWzotvkTSQ).\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcosmos%2Fdid-cosmos","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcosmos%2Fdid-cosmos","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcosmos%2Fdid-cosmos/lists"}