search

DID Document Structure

ImFact DID Documents are designed to follow the W3C DID Core model as closely as possible, while extending it for specific authorization and operation control.

A DID Document represents the identity, authentication methods, and service endpoints associated with a DID.

hashtag
Example

{
  "_hint": "mitum-did-document-v0.0.1",
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://imfact.im/did/contexts/v1.jsonld"
  ],
  "id": "did:mitum:0xA44f6bC39A52f320F6505e247df5329b4804cC4cfca",
  "authentication": [ ... ],
  "verificationMethod": [],
  "service": []
}

hashtag
Fields

_hint: ImFact-internal type identifier used by the blockchain to decode and validate the object.

This must be:

@context : Standard W3C DID contexts plus ImFact-specific context. Defines how fields in the document should be interpreted.

id: The DID controlled by this document.

authentication: An array of authentication methods allowed to act on behalf of the DID. Each entry defines who can sign and what operations they are allowed to perform.

ImFact supports two authentication types:

Type
Class
Purpose

Asymmetric Key

AsymKeyAuth

Direct key-based control of the DID

Linked Auth

LinkedAuth

Delegated control via another verification method

For a detailed look at the differences between each type, see the following pages.

verificationMethod: Additional verification methods that may be referenced by authentication entries.

service: Optional array of service object related to the DID (dApps, APIs, etc.). The service object must contain an id in DID URL format (did + "#" + string), a type, and a service_end_point URL.

PreviousDID Registry Model (Authdid)NextAuthentication Types

Last updated