Abstract

This specification defines how did:wba, native did:web, and did:webvh identities participate in the DID-method-agnostic authentication protocol defined by Agent Identity and HTTP Authentication. Each Binding Profile defines method-specific resolution and validation rules without redefining the underlying DID method.

Introduction

DID methods differ in identifier syntax, resolution, update, deactivation, and trust properties. The Agent Identity protocol therefore separates its common HTTP authentication algorithm from the method-specific processing needed to obtain a validated DID Document.

This document does not redefine did:web or did:webvh. It defines only the requirements that connect those methods, and the separately specified did:wba method, to the common Agent Identity protocol.

Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.

An implementation claiming conformance to the AI Agent Protocol Web DID profile MUST support the following Binding Profiles:

An implementation MAY support additional DID methods, but it MUST apply the specification of the method encoded in each DID and MUST define or identify a Binding Profile for any additional method.

Binding Profile Selection

The DID method name encoded in the DID is authoritative. A verifier MUST select the resolver and Binding Profile from that method name. It MUST NOT select a method from separate descriptive metadata and MUST NOT fall back to another method after a resolution or validation failure.

The following examples identify the three required method profiles: 

did:wba:example.com:user:alice:e1_<fingerprint>
did:web:example.com:agents:alice
did:webvh:<SCID>:example.com:agents:alice

In the did:webvh example, <SCID> is the self-certifying identifier defined by the did:webvh method.

Common Requirements

After method-specific resolution succeeds, every Binding Profile MUST produce a DID Document and method metadata sufficient for the verifier to:

  1. confirm that the resolved DID Document id matches the requested DID;
  2. determine whether the DID is deactivated;
  3. dereference the complete DID URL carried in keyid;
  4. locate the corresponding verification method;
  5. verify that the method is authorized by the authentication relationship;
  6. apply any method-specific validation postconditions;
  7. return failure when any required check fails.

A verifier MUST NOT authenticate an agent from an unvalidated document or from key material that merely happens to match the request signature.

did:wba Binding Profile

A did:wba identity MUST be created, resolved, updated, and deactivated according to the did:wba DID Method Specification.

Resolution

e1_ Path Profile

For a path-type did:wba using the default e1_ profile, the resolver MUST validate the path-to-key binding and DID Document proof defined by the did:wba method specification.

At a minimum, the resolver MUST:

  1. require the top-level DID Document proof;
  2. verify the DataIntegrityProof using eddsa-jcs-2022;
  3. obtain the Ed25519 verification method identified by proof.verificationMethod;
  4. recalculate the RFC 7638 thumbprint of the equivalent public JWK;
  5. verify that the thumbprint equals the final e1_ fingerprint segment.

A client using this profile SHOULD sign the initial HTTP authentication request with the binding key. The signing key MUST be authorized by the DID Document's authentication relationship.

Naked-Domain Profile

A naked-domain did:wba does not contain an e1_ fingerprint. The resolver MUST NOT apply the path-binding rule to this DID form. Authentication uses a verification method authorized by the resolved DID Document's authentication relationship.

Native did:web Binding Profile

Objectives and Scope

Native did:web identities participate in Agent Identity without migration to did:wba. Creation, resolution, update, and deactivation remain governed by the did:web Method Specification .

Resolution and Validation

A verifier MUST:

  1. parse and resolve the DID according to the native did:web rules;
  2. retrieve the DID Document over HTTPS from the location produced by the method transformation;
  3. verify that the DID Document id exactly matches the requested DID;
  4. locate the verification method identified by keyid;
  5. verify that the verification method is authorized by authentication;
  6. apply the common Agent Identity authentication process.

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

Excluded did:wba Requirements

A verifier MUST NOT require a native did:web identity to satisfy:

If the DID Document contains a standard proof, an implementation MAY verify that proof according to its declared cryptographic suite and local policy. Such a proof is not a prerequisite for native did:web resolution unless required by a separately selected profile.

HTTP Authentication

The identity-binding semantics of did:web are supplied by successful native did:web resolution and DID Document verification, not by a did:wba path fingerprint.

did:webvh Binding Profile

Resolution and History Validation

A did:webvh implementation MUST process the DID log according to the supported version of the did:webvh v1.0 Specification and MUST derive the applicable DID Document only from a valid history.

At a minimum, the resolver MUST validate:

The 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 using an unvalidated current-state document that bypasses the DID history.

HTTP Authentication

The verification method identified by keyid MUST exist in the DID Document derived for the applicable version and MUST be authorized by its authentication relationship.

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

Use by Other Agent Capabilities

After successful method-specific resolution, a supported DID method may be used by other Agent Protocol capabilities according to the contents of the validated DID Document and the requirements of the applicable upper-layer specification.

DID Service Entries

A DID Document MAY contain service entries for agent description, naming, messaging, or other application functions. This specification does not require support for every service type. An implementation MAY ignore an unsupported service type, preserve it as metadata, or process it only when it implements the specification that defines that service type.

AgentDescription, ANPHandleService, and ANPMessageService are examples. Their endpoint formats and processing semantics are not defined by this document.

Key Agreement and E2EE

A supported DID may participate in an upper-layer end-to-end encryption protocol when its validated DID Document contains a suitable verification method in the keyAgreement relationship and the upper-layer protocol supports the method's algorithm and key representation.

This document does not define the encryption, key schedule, message protection, or group-state procedures of an E2EE protocol.

Implementation Requirements Summary

DID method Required method-specific behavior Requirements that MUST NOT be inherited
did:wba Apply the did:wba method rules; for e1_, validate the path-to-key binding and proof. None from another method.
did:web Apply native Web resolution and DID Document verification. No did:wba fingerprint, proof, or rotation requirement; no did:webvh history requirement.
did:webvh Validate the SCID and the applicable authorized, hash-linked DID history. No did:wba path-binding or document-proof requirement.

An application MUST NOT reject a valid did:web or did:webvh identity solely because it lacks did:wba-specific path bindings or proofs.

Security Considerations

Privacy Considerations

Web-based DID resolution can reveal the identifiers a verifier is resolving and can enable correlation across interactions. Implementations SHOULD use caching, privacy-preserving DNS resolution, scoped identifiers, and data minimization as appropriate to their deployment.

A method's persistence and update model can affect linkability. Applications MUST NOT assume that all supported DID methods have equivalent privacy, rotation, or recovery properties.