Cookies managing
We use cookies to provide the best site experience.
Cookies managing
Cookie Settings
Cookies necessary for the correct operation of the site are always enabled.
Other cookies are configurable.
Essential cookies
Always On. These cookies are essential so that you can use the website and use its functions. They cannot be turned off. They're set in response to requests made by you, such as setting your privacy preferences, logging in or filling in forms.
Analytics cookies
These cookies collect information to help us understand how our Websites are being used or how effective our marketing campaigns are, or to help us customise our Websites for you. See a list of the analytics cookies we use here.
Advertising cookies
These cookies provide advertising companies with information about your online activity to help them deliver more relevant online advertising to you or to limit how many times you see an ad. This information may be shared with other advertising companies. See a list of the advertising cookies we use here.
P2P Privacy Communication
ID Data Marketplace

Hypersign did:hid Method Specification Approval in W3C DID Spec Registry

Hypersign's did:hid method has been officially accepted by W3C in DID method specification registry. This underlines our commitment and continuous efforts to extend the applicability of the W3C DID core specification to encompass web3 identity use-cases.
The official recognition of our DID specification by the World Wide Web Consortium (W3C) underscores a momentous achievement for Hypersign. This validation confers credibility to our diligent work and amplifies the technical strength of our endeavors.
Before we jump into details of did:hid method specification, let us understand basics of DID method and registry:

What is Decentralized Identifier (DID) Method Sepcification?

W3C proposed DID v1.0 Specification - The bare bone specification for Decentralized Identifiers (DIDs). This DID core specification also left room for others to further extend it to use case or domain specific specifications. These use-case specific extended specifications are called DID Method Specifications. Infrastructure providers extended DID core specification. to use-case, platform or eco system specific specifications. Currently there are more than 100 DID Method Specification registered in the DID spec registry which we will talk next.

The DID Method provides definition of specific DID scheme - basically syntax of a decentralized identifier. It specifies operations by which a DID and DID document are created, resolved, updated and deactivated.

What is Decentralized Identifier (DID) Method Specification Registry?

As you might have understood a DID Method specification is format and standard for a specific DID, which means this standard could be used by others business or services for interoperability purpose. Which is why a central repository is created and maintained by W3C so that infrastructure providers can register their DID Method Specifications. Checkout the DID spec registry here:

Hypersign did:hid Method Specification

The did:hid specification is intended to be a Standard for Decentralized Identifiers (DIDs) on the Hypersign Identity Network. The DID Syntax is as follows:
did:                           "did:hid" ":" [chain-namespace] ":" method-specific-id
chain-namespace:               [-a-zA-Z0-9]{1,10}
method-specific-id:            caip-10-blockchain-account-id / alphanumeric-rule
caip-10-blockchain-account-id: chain_id + ":" + account_address
chain_id:                      [-a-z0-9]{3,8}:[-_a-zA-Z0-9]{1,32}
account_address:               [-.%a-zA-Z0-9]{1,128}
alphanumeric-rule:             ALPHA / DIGIT / . / -

Example DIDs

As Hypersign did:hid method spec support CAIP-10 Blockchain Account ID as well as Alphanumeric IDs, its very flexible in terms of adoption across various ecosystems and use-cases.

  • did:hid:z9ztgXU5YupF5ME1HV3AKBW94CfGc7qMjrhUoLbFnaLat
  • did:hid:testnet:z9ztgXU5YupF5ME1HV3AKBW94CfGc7qMjrhUoLbFnaLat
  • did:hid:testnet:cosmos:jagrat:hid1f6r0x3pljpl7pe76zzv36l0ksztqmdlth7zdk5
  • did:hid:eip155:1:0xF4eE129BEDE6ac5E870bCf972e74A117b4809df9
  • did:hid:1b55c1ec-39e3-4e49-9fa9-7dc6ce27a112

DID Document

The DID Document, along with its metadata, is stored on the blockchain in the following manner:
    "didDocument": {
        "id": "did:hid:zF4yj4PgS33z8Z2FdrPgnhZWgmi249tmx8LcxA13UopPv",
        "controller": [ "did:hid:zF4yj4PgS33z8Z2FdrPgnhZWgmi249tmx8LcxA13UopPv" ],
        "verificationMethod": [
                "id": "did:hid:zF4yj4PgS33z8Z2FdrPgnhZWgmi249tmx8LcxA13UopPv#k1",
                "type": "Ed25519VerificationKey2020",
                "controller": "did:hid:zF4yj4PgS33z8Z2FdrPgnhZWgmi249tmx8LcxA13UopPv",
                "publicKeyMultibase": "zF4yj4PgS33z8Z2FdrPgnhZWgmi249tmx8LcxA13UopPv",
        "authentication": [ "did:hid:zF4yj4PgS33z8Z2FdrPgnhZWgmi249tmx8LcxA13UopPv#k1" ]
    "didDocumentMetadata": {
        "created": "2023-04-19T02:16:00Z",
        "updated": "2023-04-19T02:16:00Z",
        "deactivated": false,
        "versionId": "5B8D61A575C81565E8D23A9A85FEED160FB004C6B3CEA815080AAEDA9D553C97"

Supported Decentralized Identities (DID) Operations

  • Create
  • Query/Resolve
  • Update
  • Deactivate

Supported Key Algorithms

  1. Ed25519VerificationKey2020
  2. EcdsaSecp256k1VerificationKey2019
  3. EcdsaSecp256k1RecoveryMethod2020

Supported Wallets

A simple signature verification algorithm involves three components: a message, public key, and signature. When verifying a signed DID Document, it's important to ensure that the document was signed as-is. However, there may be situations where a DID Document is signed by a blockchain wallet. These wallets often don't sign the DID Document as-is, but instead encapsulate it with a standard format/structure before signing it. To verify the DID Document, we need to first encapsulate the provided DID Document within the same structure that the wallet had encapsulated before signing it, and then proceed with the verification.

Since different wallets have different approaches to signing a message, it's necessary to have a ClientSpec to label the origin of a signature. Currently, two supported ClientSpec methods are available: Cosmos-ADR036 for Keplr Wallet and eth-personalSign for Metamask Wallet hence extending support for both Cosmos as well as Ethereum ecosystems.
More about ClientSpec can be read in our developer documentation:

Use Cases

As this spec supports various different algorithms and wallets, it opens up plethora of use cases related to SSI technologies. Some of them are as follows:

  • Web3 Reputation
  • On-chain KYC
  • Private access control for DAO and Metaverse
  • Portable social reputation
  • Organisational Identity Access & Management
Dig deeper into the specification here:
See you there, where the future of identity meets the present!
Stay tuned for updates :)