Authentication Types

1️⃣ Asymmetric Key Authentication (AsymKeyAuth)

Key Properties

Supported Types

2️⃣ Linked Authentication (LinkedAuth)

Key Properties

targetId

allowed

⚙️ SDK Helper (Recommended)

1️⃣ Asymmetric Key Authentication (AsymKeyAuth)

Represents direct ownership of the DID through a cryptographic key.

Used when an address/key pair directly controls the DID.

Key Properties

Field	Description
id	DID URL of the key (<did>#<key-id>)
controller	The DID being controlled
type	Key type (e.g. Ed25519VerificationKey2020)
publicKeyMultibase	Used only for interoperability with general DID / Web3 tooling.
It is automatically derived by the SDK, so developers usually do not need to handle it manually.
publicKeyImFact	Public key used for signature verification in the ImFACT network

Supported Types

Type	Notes
EcdsaSecp256k1VerificationKey2019	Web DID–compatible format
EcdsaSecp256k1VerificationKeyImFact2025	ImFact-native format (This type don’t need publicKeyMultibase field.)
Ed25519VerificationKey2020	Reserved (limited support)

2️⃣ Linked Authentication (LinkedAuth)

Represents delegated authority.

Instead of using a key directly, it links to another verification method and restricts what that method can do.

Key Properties

Field	Meaning
id	DID URL of the key (<did>#<key-id>)
controller	The DID being controlled
type	LinkedVerificationMethod
targetId	References another authentication. (See the details below)
allowed	List of operations this auth is permitted to execute. (See the details below)

targetId

targetId links this authentication to another authentication method that performs the actual cryptographic proof. It must follow this format:<did>#<key-id>

Rules

• It must reference an existing authentication entry

• The referenced authentication:

  • must belong to a DID registered under the same contract model

  • must be an Asymmetric Key Authentication (not another Linked Authentication). Chained linking is not allowed (prevents infinite linked structures)

• The referenced key is the one that actually signs and proves identity → This Linked Authentication only delegates permission

allowed

In a LinkedVerificationMethod, the allowed field defines which operations this delegated authentication is permitted to execute.

Each element in the array is an AllowedOperation object that restricts execution scope.

For a complete list of supported operations and their corresponding builder methods, see the Operation Builder Reference.

Operations that do not require a contract model

These operations only need the operation hint:

// e.g.
{
  "operation": "mitum-currency-transfer-operation-v0.0.1"
}

Operations that require a contract model

Some operations are only valid for a specific contract.

In this case, both the contract address and operation hint must be provided:

{
  "contract": "0xContractAddress",
  "operation": "mitum-did-update-did-document-operation-v0.0.1"
}

This restricts execution to that operation on that contract only.

⚙️ SDK Helper (Recommended)

Operation hints must be exact strings, or the user operation will be failed.

To prevent mistakes, the SDK provides builders:

Mitum.allowedOperation.currency.transfer()

Mitum.allowedOperation.authdid.registerModel(contractAddress)

• Use methods without parameters for non-contract operations

• Use methods with contract address for contract-bound operations

These helpers generate correctly formatted AllowedOperation objects. For builder usage and information, please refer to the Operation Builder Reference.