Method name

The name string used to identify this DID method is wba. DIDs using this method must start with the following prefix: did:wba. According to the DID specification, this string must be lowercase. The remainder of the DID (after the prefix) is specified below.

Method-specific identifiers

The method-specific identifier is a fully qualified domain name (FQDN) protected by TLS and optionally contains the path to the DID document. The formal rules describing the syntax of valid domain names are described in RFC1035, RFC1123, and RFC2181.

The method-specific identifier must match the server certificate according to modern TLS service authentication rules. Domain name matching MUST be based on the DNS identifier (dNSName) in the certificate's subjectAltName extension; implementations MUST NOT rely on Common Name (CN) as the basis for service identity matching. Method-specific identifiers must not contain IP addresses. Port numbers can be included, but the colon between the host and port must be percent-encoded to prevent conflicts with paths. Directories and subdirectories can be optionally included, using colons instead of slashes as separators.

did:wba supports two forms:

1. Naked domain name DID: used to identify the entire domain name subject, and can also be used for domain-level service identity, such as cross-domain service-to-service HTTP identity authentication;
2. Path-type DID: used to identify specific users, agents or sub-identities under a domain name.

For newly created path-type did:wba, this specification defines "the last segment of the path carries the binding public key fingerprint" as the default scheme. The path segments before the fingerprint segment are defined by the implementer, such as user:alice, agents:billing, etc.

ABNF is defined as follows:

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

Description:

1. The main specification default path profile only defines e1_.

Default path scheme: e1_ binds public key fingerprint

For newly created path type did:wba, the last path segment MUST be the e1_ binding public key fingerprint segment. e1_ indicates that the binding key is the Ed25519 public key, and the DID adopts the main specification default profile.

The recommended structure is as follows:

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

Example:

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

To be compatible with existing deployments, the parser MAY support the parsing of historical path-type DIDs without fingerprint segments; however, newly created path-type DIDs SHOULD adopt the default scheme defined in this specification.

e1_ fingerprint generation method (recommended)

The e1_ fingerprint is used to associate a path-type DID with the Ed25519 binding public key. The generation method is as follows:

1. Select a DID binding key. The binding key MUST meet the following conditions:
   • is an Ed25519 public key;
   • Represented by Multikey / publicKeyMultibase in DID documents;
   • Authorized by the authentication relationship of the DID document.
2. Convert the Ed25519 publicKeyMultibase to the equivalent public key JWK. The equivalent JWK retains only the necessary fields required by RFC 7638:

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

Specifically:

• publicKeyMultibase must be Multibase base58-btc encoded Ed25519 Multikey;
• After decoding, the original 32 bytes of the Ed25519 public key are obtained;
• x is the base64url (without padding) representation of this 32-byte public key.

3. Generate JWK Thumbprint input according to the rules of RFC 7638:
   • Only keep necessary fields;
   • Field names are sorted lexicographically;
   • Use JSON strings without extra whitespace;
   • Use UTF-8 encoding.
4. Perform a SHA-256 hash on the UTF-8 byte sequence obtained in step 3 to obtain a 32-byte digest value.
5. Base64url encode the 32-byte digest value and remove the trailing = padding. The encoding result length is fixed at 43 characters.
6. Add the e1_ prefix in front of the encoding result to get the final path segment.

Notes:

1. The e1_ prefix is not part of the hash output, but the profile prefix;
2. It is recommended to use the thumbprint value without the e1_ prefix as the kid or fragment of the verification method to facilitate the intuitive correspondence between the DID path and the verification method identification;
3. New deployments SHOULD preferentially use the e1_ profile.

Key material and document processing

Due to the way most web servers render content, it is likely that a particular did:wba document will be served with the media type application/json. If a document named did.json is retrieved, the following processing rules should be followed:

1. If @context exists at the root of the JSON document, the document should be processed according to JSON-LD rules. If it cannot be processed, or the document processing fails, it should be rejected as a did:wba document.
2. If @context exists at the root of the JSON document, the document is successfully processed through JSON-LD, and the context contains https://www.w3.org/ns/did/v1, it can be further processed into a DID Document according to Section 6.3.2 of the DID Core specification.
3. If @context is not present, DID processing shall be performed according to the normal JSON rules specified in DID Core specification section 6.2.2.
4. References to external resources, external DIDs, or serviceEndpoint MUST use absolute URIs.
5. References to internal validation methods of the same DID Document MAY use relative DID URLs (such as #key-1); when the parser processes such references, it must expand based on the document root DID.

NOTE: This includes external URLs embedded in key material and other metadata, which prevents key obfuscation attacks.

DID Document Description

Apart from DID Core, most related specifications are still in the draft stage. This section shows a subset of DID Documents used for authentication. To improve interoperability between systems, all fields marked as required must be supported by all systems, while fields marked as optional may be supported selectively. Fields defined in other standards but not listed here may also be supported selectively.

The following e1 path-type DID document example includes core identity fields and optional illustrative service entries:

{
  "@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..."
  }
}

The ANP-related service entries in this DID Document are illustrative examples only. ANP is an external protocol family and is distinct from this W3C Community Group protocol; their inclusion here does not require implementations of this specification to support ANP services.

Field explanation:

• @context: required field, JSON-LD context defines the semantics and data model used in DID documents to ensure the understandability and interoperability of the document. https://www.w3.org/ns/did/v1 is required. For e1 documents using the standard Ed25519 proof, https://w3id.org/security/data-integrity/v2 and https://w3id.org/security/multikey/v1 are also required. Others are added as needed.
• id: required field, cannot carry IP, but can carry port. When carrying port, the colon needs to be encoded as %3A. Use a colon later to split the path. For newly created path DIDs, the last path segment MUST be e1_<fingerprint>.
• verificationMethod: A required field, containing an array of verification methods, which defines the public key information used to verify the DID subject. For scenarios that need to support end-to-end encryption (E2EE) communication, verificationMethod should contain both the signature key and the key agreement key to achieve key separation. The signing key is used for identity authentication and document assertion; the key agreement key (such as X25519KeyAgreementKey2019) is used for key negotiation of upper-layer protocols or receipt of confidential information. Both types of keys perform their own duties, and the leakage of a single key will not affect identity authentication and communication confidentiality at the same time.

For a path-type DID using the default path scheme, there MUST be at least one Ed25519 Multikey in verificationMethod as a binding key, and the RFC 7638 thumbprint of its equivalent public key JWK is exactly the same as the last e1_ fingerprint segment of the DID path.

Subfield:

• id: The unique identifier of the verification method.
• type: The type of verification method.
• controller: Controls the DID of this verification method.
• publicKeyJwk: Public key information, using JSON Web Key format.
• publicKeyMultibase: Public key information, using Multibase format.

• authentication: required field, lists the verification method used for authentication, can be a string or object. For path-type DIDs using the default path scheme, the binding key MUST be authorized by the authentication relationship. By default, cross-platform authentication should prefer signing with this binding key.
• assertionMethod: Optional field listing the validation method used to express the assertion. For DIDs with the e1 profile and using the standard DID Document proof, the binding key or Ed25519 Multikey used to generate the proof MUST be authorized by assertionMethod.
• keyAgreement: Optional field that defines the public key information used for key agreement and can be used for encrypted communication between two DIDs. The verification method generally uses key agreement algorithms such as X25519KeyAgreementKey2019 that can be used for key exchange. keyAgreement can be a string reference (pointing to an entry in verificationMethod) or an embedded object. For end-to-end encryption (E2EE) scenarios, this field is used to provide key negotiation material to the upper layer protocol. The upper layer protocol can be direct messaging end-to-end encryption Profile, group end-to-end encryption Profile or other security overlays defined in the future; this specification does not hardcode keyAgreement into a specific algorithm process. New deployments should typically contain X25519KeyAgreementKey2019 or the semantically equivalent X25519 entry. If there is no keyAgreement in the DID document or no negotiation entry available for the upper layer protocol, it means that the agent does not support the relevant E2EE capabilities.

Subfield:

• id: Unique identifier of the key agreement method.
• type: The type of key agreement method.
• controller: The DID that controls the key negotiation method.
• publicKeyMultibase: Public key information in Multibase format.

• service: Optional field that defines the list of services associated with the DID subject.
  • id: The unique identifier of the service.
  • type: Service type. Examples of service types that may appear in DID Documents include:
    • AgentDescription: an agent description service. serviceEndpoint points to an agent description document, such as a document described by the Agent Description section of this specification.
    • ANPHandleService and ANPMessageService: examples of service types used by the external ANP ecosystem. They are shown here only to illustrate that a DID Document can reference services defined by other protocols. This specification does not define these ANP service types, their endpoint formats, or their processing requirements. Implementations that do not support ANP may ignore these service entries according to local policy.
  • serviceEndpoint: The endpoint URL of the service.
  • serviceDid: Optional field used by some service protocols to indicate which DID is used for service-level authentication. If a service protocol uses this field, its detailed semantics are defined by that service protocol, not by this specification.
• proof: For the default e1_ profile, proof is a required field; for other profiles, whether this field appears is determined by the corresponding profile rules. proof is used to express the integrity proof of the DID Document, proving that the DID Document has not been tampered with after generating the proof, and indicating that the signer controlled the corresponding private key when the proof was created. Proof itself does not replace the DID method parsing process alone, nor does it alone replace the id consistency check.
• For the default e1 profile, this version defines DataIntegrityProof + eddsa-jcs-2022 proof profiles based on W3C standards.

Note:

1. Public key information currently supports two formats, publicKeyJwk and publicKeyMultibase. See verification method properties for details.
2. For verification method type definition, see verification method types. For e1 binding keys, Multikey is recommended.
3. For scenarios that need to support end-to-end encryption communication, it is recommended to adopt a key separation design: the signature/assertion key and the key agreement key are managed separately. Signing/assertion keys do not participate in key agreement, and key agreement keys do not participate in signing. The specific use of these materials is defined by the upper layer direct messaging E2EE, group E2EE and other Profiles.
4. For newly created path-type DIDs using the default path scheme, the binding key MUST satisfy:
   • represented using Multikey / publicKeyMultibase;
   • authorized by the authentication relationship;
   • The RFC 7638 thumbprint of its equivalent public key JWK is exactly the same as the last e1_ fingerprint segment of the DID path.

DID Method Operations

Example: Creating a DID
did:wba:example.com
 -> https://example.com/.well-known/did.json

Example: Creating a path-based DID with the default path scheme
did:wba:example.com:user:alice:e1_<fingerprint>
 -> https://example.com/user/alice/e1_<fingerprint>/did.json

Example: Creating a DID with an optional path and port
did:wba:example.com%3A3000:user:alice:e1_<fingerprint>
 -> https://example.com:3000/user/alice/e1_<fingerprint>/did.json

Security and Privacy Considerations

For security and privacy considerations, please refer to did:web method specification section 2.6. Implementers should also pay additional attention to DID rotation caused by binding key changes under the default path scheme, and Agent Name Service synchronization issues.

did:webvh Validation

For a did:webvh Agent Identity, an implementation MUST process the DID log according to the declared, supported version of the did:webvh method specification and derive the current DID Document only from a valid history. At a minimum, the resolver MUST validate the SCID, the ordered and hash-linked update chain, the authorization proofs for each applicable update, deactivation state, and any other method-version requirements before returning the current DID Document.

A verifier MUST fail resolution when the history is incomplete, inconsistent, uses an unsupported method version, or fails a required proof or hash-chain check. It MUST NOT authenticate an agent from an unvalidated current-state document obtained by bypassing the DID history.

DID Resolution

Agents MUST resolve DID Documents according to the method-specific resolution rules identified by the DID in keyid. Resolver selection MUST be based on the method name encoded in the DID, not on separate descriptive metadata.

• did:wba: Resolve the HTTPS did.json resource and apply the did:wba document, path-binding, and proof rules defined by this specification. A naked-domain DID uses https://<domain>/.well-known/did.json; a path-type DID uses the path transformation defined in the did:wba method section.
• did:web: Resolve the HTTPS did.json resource according to the native did:web transformation rules. A naked-domain DID uses /.well-known/did.json, while a path DID resolves to /<path>/did.json.
• did:webvh: Retrieve and process the method's did.jsonl log, validate the SCID and authorized update history, and derive the applicable DID Document according to the supported did:webvh method version.

After method-specific resolution succeeds, the verifier MUST complete the method's identifier-consistency checks, confirm that the method has not reported the DID as deactivated, and verify that the verification method named by keyid exists and is authorized by the authentication relationship. Only then may the verifier use that verification method to authenticate the HTTP Message Signature.

Resolution or validation failure MUST fail authentication. Implementations MUST NOT fall back to another DID method or use an unvalidated document merely because it contains a matching public key.

Initial request

When the current client initiates an HTTP request to the server for the first time, it needs to perform identity authentication according to the following method.

POST /orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Digest: sha-256=:BASE64_SHA256_DIGEST:
Signature-Input: sig1=("@method" "@target-uri" "@authority" "content-digest");created=1733402096;expires=1733402156;nonce="abc123";keyid="did:wba:example.com:user:alice:e1_<fingerprint>#key-1"
Signature: sig1=:BASE64_SIGNATURE:

Server-side verification

{
  "sub": "did:wba:example.com:user:alice:e1_<fingerprint>",
  "iat": "2024-12-05T12:34:56Z",
  "exp": "2024-12-06T12:34:56Z",
  "scope": "orders.read orders.write"
}

Authentication-Info: access_token="eyJhbGciOi...", token_type="Bearer", expires_in=3600, scope="orders.read orders.write"

Authorization: Bearer <access_token>

WWW-Authenticate: AgentDID realm="api.example.com", error="invalid_signature", error_description="Signature verification failed.", nonce="xyz987"
Accept-Signature: sig1=("@method" "@target-uri" "@authority" "content-digest");created;expires;nonce;keyid
Cache-Control: no-store

Native did:web: Objectives and Scope

This section defines the Agent Protocol processing profile for native did:web.

The goal of this profile is to enable native did:web identities to access the capabilities defined in this specification without migration to did:wba, including but not limited to:

• Cross-platform identity authentication (the cross-platform authentication sections)
• Handle-based name binding
• end-to-end encryption Communication (E2EE)
• Service discovery through DID service entries, such as AgentDescription or externally defined service types

did:web continues to be created, resolved, updated, and deactivated according to the did:web method specification. This section only defines how the common Agent Identity layer accepts and verifies native did:web.

Parsing and Verification Rules

When an implementation receives a native did:web, it MUST perform parsing according to the did:web method specification and complete at least the following checks:

1. Parse DID Document according to did:web rules;
2. Check whether the id of the DID Document is completely consistent with the requested did:web;
3. Check according to DID Core rules whether the relevant verification method exists and is in the correct verification relationship.

In compatibility mode, implementations MUST NOT enforce the following did:wba-specific checks on native did:web:

• did:wba-specific path binding public key fingerprint check;
• Path binding profile semantic check in did:wba main specification;
• did:wba's unique path-type DID rotation semantic check;
• Use did:wba-specific proof rules as a prerequisite for successful did:web parsing.

If the native did:web DID Document itself carries a standard proof (such as Data Integrity proof), the implementation MAY perform verification according to the proof's declaration profile and local policy; however, the success of did:web parsing itself is not predicated on the proof rules of did:wba.

Cross-Platform Authentication Compatibility

Native did:web is compatible with the cross-platform identity authentication process defined in the cross-platform authentication sections of this specification.

When the client uses did:web to participate in cross-platform authentication:

1. keyid still MUST be a complete DID URL;
2. The server must still parse the DID Document;
3. The server must still verify that the verification method pointed to by keyid exists;
4. The server MUST verify that the verification method is located in the authentication relationship of the DID Document;
5. The subsequent HTTP Message Signatures and Content-Digest verification use the common authentication process defined by this specification.

In compatibility mode, the identity binding semantics of did:web comes from the parsing result of did:web itself, rather than the path binding public key fingerprint of did:wba.

Service Entry Compatibility

Native did:web DID Documents MAY include service entries for agent description, name binding, messaging, or other application-level functions. This specification only defines how the DID and its verification methods are parsed and verified; it does not require support for every service type that may appear in the service array.

For example, an implementation might encounter the following service types:

• AgentDescription: a service entry that points to an agent description document.
• ANPHandleService or ANPMessageService: examples of service types used by the external ANP ecosystem.

The ANP service types above are illustrative examples only. ANP and this W3C Community Group protocol are distinct. This document does not define ANP endpoint formats, message flows, role models, capability negotiation, or the detailed semantics of fields such as serviceDid. Implementations MAY ignore unsupported service types, preserve them as metadata, or process them only when they explicitly implement the corresponding external protocol.

End-to-End Encryption Compatibility

Native did:web is compatible with end-to-end encryption when its DID Document contains suitable keyAgreement entries and the application-layer protocol defines how to use them.

For example:

• X25519KeyAgreementKey2019
• or other key agreement types explicitly supported by the upper-layer protocol

In compatibility mode, the prerequisites for E2EE capabilities are:

1. DID Document can be parsed successfully;
2. The required keyAgreement verification method exists;
3. The upper layer protocol supports corresponding algorithms, public key representation methods, and message protection procedures.

did:webvh Compatibility Profile

A did:webvh identity participates in the same cross-platform authentication, service discovery, Handle-based name binding, and end-to-end encryption capabilities as another supported Agent Identity, subject to the capabilities declared in its resolved DID Document.

Before using a did:webvh verification method, the implementation MUST complete the did:webvh history validation required by this specification. The verification method named by keyid MUST exist in the document derived for the applicable version and MUST be authorized by its authentication relationship.

did:wba-specific e1_ path-binding and DID Document proof rules MUST NOT be applied to did:webvh. The did:webvh SCID, update authorization, version, witness, portability, and deactivation semantics are instead governed by the supported version of the did:webvh method specification.

Implementation Recommendations

Implementers MUST distinguish between the following resolution and verification modes:

1. did:wba mode
   • Enforce full path binding, public key fingerprinting, and proof rules as per this specification.
2. did:web compatibility mode
   • Parse according to the did:web specification;
   • Do not enforce did:wba-specific path binding, public key fingerprint, or proof rules on native did:web identifiers;
   • When service entries exist, select only service types supported by the implementation or required by the application protocol;
   • Unsupported external service types, including ANP-specific service examples, MAY be ignored or preserved as metadata according to local policy.
3. did:webvh mode
   • Resolve and validate the DID log according to a supported did:webvh method version;
   • Reject an invalid history rather than using an unvalidated current-state DID Document;
   • Do not enforce did:wba-specific path-binding or proof rules.

Application implementations MUST NOT deny participation in cross-domain authentication or end-to-end encryption solely because a valid did:web or did:webvh identity does not contain did:wba-specific path bindings or proofs.

Deployments should select a DID method based on the required trust and lifecycle properties. The did:wba e1_ profile provides path-to-key binding, native did:web provides simple Web-hosted resolution, and did:webvh provides a self-certifying identifier and verifiable update history.