did:wba DID Method Specification

Abstract

This specification defines the did:wba DID method. The method uses HTTPS-hosted DID Documents and supports both domain-level identifiers and path-type identifiers. The default path profile binds an Ed25519 public key fingerprint into the final DID path segment using the e1_ prefix and requires a corresponding Data Integrity proof in the DID Document.

`did:wba` DID Method Specification

Method Name

The method name is wba. DIDs using this method MUST begin with the lowercase prefix did:wba:.

Method-Specific Identifier

The method-specific identifier begins with a fully qualified domain name protected by TLS and MAY contain a path to the DID Document. Domain names are governed by RFC 1035, RFC 1123, and RFC 2181.

TLS service identity matching MUST use the DNS identifier (dNSName) in the certificate's subjectAltName extension. Implementations MUST NOT rely on Common Name as the service identity.

A did:wba method-specific identifier MUST NOT contain an IP address. A port MAY be included, but the colon between host and port MUST be percent-encoded as %3A. Optional directories and subdirectories are encoded as colon-separated path segments.

The method supports two DID forms:

Naked-domain DID: identifies the domain subject or a domain-level service identity.
Path-type DID: identifies a user, agent, service, or other sub-identity beneath the domain.

For newly created path-type DIDs, this specification defines a default profile in which the final path segment contains the binding public-key fingerprint. Earlier path segments are application-defined namespaces, such as user:alice or agents:billing.

Syntax

base64url-char = ALPHA / DIGIT / "-" / "_"
path-segment   = 1*(ALPHA / DIGIT / "-" / "_" / ".")
e1-fingerprint = "e1_" 43base64url-char

wba-root-did = "did:wba:" domain-name
wba-path-did = "did:wba:" domain-name 1*(":" path-segment) ":" e1-fingerprint
wba-did      = wba-root-did / wba-path-did

This version of the method specification defines only e1_ as the default path-binding profile prefix.

Naked-Domain DID

A naked-domain DID has the form did:wba:{domain} and resolves to https://{domain}/.well-known/did.json.

It primarily represents the entire domain subject or a domain-level service identity rather than a specific user or sub-identity.
It does not carry an e1_ fingerprint. The path-binding validation rules defined for an e1_ path-type DID do not apply.
Authentication uses a verification method in the resolved DID Document according to the applicable upper-layer protocol.

Native did:web interoperability is defined separately in the did:web Binding Profile .

Default Path Profile: `e1_`

For a newly created path-type did:wba, the final path segment MUST be an e1_ binding public-key fingerprint. The e1_ prefix identifies an Ed25519 binding key and the default profile defined by this document.

The recommended structure is:

did:wba:{domain}:{namespace...}:{e1-fingerprint}

Examples:

did:wba:example.com
did:wba:example.com:user:alice:e1_<fingerprint>
did:wba:example.com%3A3000:user:alice:e1_<fingerprint>

For compatibility with existing deployments, an implementation MAY parse a historical path-type DID without a fingerprint segment. Newly created path-type DIDs SHOULD use the default profile defined here.

`e1_` Fingerprint Generation

The e1_ fingerprint binds a path-type DID to an Ed25519 public key. It is generated as follows:

Select a binding key that:
- is an Ed25519 public key;
- is represented as Multikey with publicKeyMultibase;
- is authorized by the DID Document's authentication relationship.
Convert the Ed25519 publicKeyMultibase to the equivalent public JWK containing only the members required by RFC 7638:

{
  "crv": "Ed25519",
  "kty": "OKP",
  "x": "..."
}

The publicKeyMultibase value is a Multibase base58-btc encoded Ed25519 Multikey. After Multikey decoding, x is the unpadded base64url encoding of the raw 32-byte Ed25519 public key.

Construct the JWK Thumbprint input according to RFC 7638: retain only the required members, sort member names lexicographically, serialize without additional whitespace, and encode as UTF-8.
Calculate the SHA-256 digest of the UTF-8 byte sequence.
Base64url-encode the 32-byte digest without padding. The result is 43 characters.
Prefix the result with e1_.

The e1_ prefix is a profile identifier and is not part of the hash output. Implementations may use the 43-character thumbprint as a verification-method fragment or key identifier to make the relationship visible to operators.

Key Material and DID Document Processing

A did:wba DID Document will commonly be served as application/json. A resolver MUST apply the following rules:

If @context is present, process the document according to JSON-LD. Reject the document if JSON-LD processing fails.
When the context contains https://www.w3.org/ns/did/v1, process the result as a DID Document according to DID Core.
If @context is absent, process the document using the JSON representation rules defined by DID Core.
References to external resources, external DIDs, and serviceEndpoint values MUST use absolute URIs.
References to verification methods in the same DID Document MAY use relative DID URLs such as #key-1 and MUST be expanded against the document's root DID before use.

DID Document

The following example shows the subset of a DID Document used by the default e1_ profile. Application-specific service entries are illustrative and non-normative.

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/data-integrity/v2",
    "https://w3id.org/security/multikey/v1",
    "https://w3id.org/security/suites/x25519-2019/v1"
  ],
  "id": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>",
  "verificationMethod": [
    {
      "id": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#key-1",
      "type": "Multikey",
      "controller": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>",
      "publicKeyMultibase": "z6Mk..."
    },
    {
      "id": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#key-x25519-1",
      "type": "X25519KeyAgreementKey2019",
      "controller": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>",
      "publicKeyMultibase": "z9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE"
    }
  ],
  "authentication": [
    "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#key-1"
  ],
  "assertionMethod": [
    "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#key-1"
  ],
  "keyAgreement": [
    "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#key-x25519-1"
  ],
  "service": [
    {
      "id": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#ad",
      "type": "AgentDescription",
      "serviceEndpoint": "https://example.com/agents/alice/ad.json"
    },
    {
      "id": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#handle",
      "type": "ANPHandleService",
      "serviceEndpoint": "https://example.com/.well-known/handle/alice"
    },
    {
      "id": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#anp",
      "type": "ANPMessageService",
      "serviceEndpoint": "https://example.com/anp",
      "serviceDid": "did:wba:example.com%3A8800"
    }
  ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2025-01-01T00:00:00Z",
    "verificationMethod": "did:wba:example.com%3A8800:user:alice:e1_<fingerprint>#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

ANPHandleService and ANPMessageService are examples defined by an external protocol ecosystem. This DID method specification does not define their endpoint formats or processing requirements.

Field Requirements

@context: REQUIRED for the JSON-LD representation. It MUST include https://www.w3.org/ns/did/v1. The default e1_ proof profile also requires the Data Integrity and Multikey contexts used by the proof and binding key.
id: REQUIRED and MUST exactly match the resolved did:wba DID. The host MUST NOT be an IP address.
verificationMethod: REQUIRED. A path-type DID using the default profile MUST contain at least one Ed25519 Multikey whose RFC 7638 thumbprint equals the final e1_ fingerprint segment.
authentication: REQUIRED. The default profile's binding key MUST be authorized by this relationship.
assertionMethod: REQUIRED when the verification method is used for the default DID Document proof. The proof verification method MUST be authorized by this relationship.
keyAgreement: OPTIONAL. It may contain X25519 or other key-agreement material used by an upper-layer secure messaging protocol. This DID method does not define the E2EE procedure.
service: OPTIONAL. Service semantics are defined by the specification that defines each service type.
proof: REQUIRED for the default e1_ profile. Its requirements are defined in DID Document Proof.

Key Separation

Implementations supporting encrypted communication SHOULD manage signature/assertion keys and key-agreement keys separately. A signing key SHOULD NOT be used for key agreement, and a key-agreement key SHOULD NOT be used for signatures. The upper-layer protocol defines how keyAgreement material is used.

DID Method Operations

Create

This method does not define a registration HTTP API. Programmatic registration and management are deployment-specific.

Creating a DID requires the controller to:

control the domain name used by the DID;
configure DNS and an HTTPS hosting service for that domain;
for a path-type DID, generate the Ed25519 binding key and calculate the e1_ fingerprint;
create a conforming DID Document and publish it at the URL derived from the DID.

Naked-domain example:

did:wba:example.com
 -> https://example.com/.well-known/did.json

Path-type example:

did:wba:example.com:user:alice:e1_<fingerprint>
 -> https://example.com/user/alice/e1_<fingerprint>/did.json

Path-type example with a port:

did:wba:example.com%3A3000:user:alice:e1_<fingerprint>
 -> https://example.com:3000/user/alice/e1_<fingerprint>/did.json

Read and Resolve

A resolver MUST:

remove the did:wba: prefix;
transform colon-separated path segments into slash-separated URL path segments;
percent-decode an encoded port separator in the authority;
prepend https://;
append /.well-known when the DID contains no path;
append /did.json;
retrieve the resource over a secure HTTPS connection;
verify that the DID Document id matches the requested DID;
apply the profile-specific validation rules below.

For an e1_ path-type DID, the resolver MUST:

require a top-level DID Document proof;
verify the DataIntegrityProof with eddsa-jcs-2022;
verify that proof.verificationMethod identifies an Ed25519 Multikey, or a semantically equivalent Ed25519 verification method representation permitted by the profile;
recalculate the RFC 7638 thumbprint of that public key and verify that it exactly matches the final e1_ fingerprint segment.

The e1_ proof and path-binding checks are mandatory and are not controlled by a relaxed local policy switch.

For a naked-domain DID, the resolver retrieves /.well-known/did.json, verifies identifier consistency, and processes the DID Document according to DID Core. The e1_ path-binding rule does not apply.

Resolvers SHOULD use privacy-preserving DNS resolution where appropriate and MUST apply secure TLS service identity validation.

Update

A controller updates a DID by updating the did.json resource corresponding to that DID.

For a path-type DID using the default profile, the DID remains unchanged while the binding-key fingerprint remains unchanged. Other DID Document content may be updated, including additional verification methods, removal of old non-binding keys, and service endpoints.

If the binding key changes, the path-type DID MUST change to contain the new fingerprint. The controller SHOULD create a new DID Document and MAY use an upper-layer naming or migration mechanism to maintain a stable external reference.

Version control and continuous integration may provide operational audit history, but such history is not part of the cryptographic method state unless defined by a separate profile.

Deactivate

A controller deactivates a DID by removing the corresponding did.json resource or otherwise making it permanently unavailable as an active DID Document.

When a default-profile binding key is permanently discarded, the old path-type DID may be deactivated and replaced by a new DID containing a new fingerprint. Stable naming and migration are handled by an upper-layer mechanism.

DID Document Proof

For the default e1_ profile, the top-level proof is REQUIRED. For another profile, the presence and processing of a top-level proof are governed by that profile.

The default proof MUST conform to Verifiable Credential Data Integrity 1.0 and Data Integrity EdDSA Cryptosuites v1.0 .

Property	Requirement
`type`	REQUIRED; `DataIntegrityProof`.
`cryptosuite`	REQUIRED; `eddsa-jcs-2022`.
`created`	REQUIRED; XML Schema date-time.
`verificationMethod`	REQUIRED; a complete DID URL identifying the Ed25519 method used to generate the proof.
`proofPurpose`	REQUIRED; `assertionMethod`.
`proofValue`	REQUIRED; base58-btc Multibase value beginning with `z`.
`domain`	OPTIONAL.
`challenge`	OPTIONAL.

The following additional constraints apply:

proof.verificationMethod MUST identify the key whose thumbprint is carried in the final e1_ path segment.
The resolver MUST recalculate the RFC 7638 thumbprint from that Ed25519 public key and verify exact equality with the DID path value.
Proof generation and verification MUST follow the eddsa-jcs-2022 cryptosuite and Data Integrity processing rules. This document does not redefine the cryptographic algorithm.

Missing proof, proof-verification failure, or a mismatch between proof.verificationMethod and the e1_ fingerprint MUST cause resolution to fail. There is no relaxed no-proof mode for an e1_ DID.

A non-e1_ profile MAY define either a relaxed mode in which an absent proof is accepted or a strict mode in which an absent proof is a validation failure.

Abstract

Introduction

Conformance