Abstract

This specification defines a DID-method-agnostic identity authentication protocol for agents communicating over HTTP. A client identifies a verification method with a DID URL, signs the HTTP request using HTTP Message Signatures, and binds any request content using Digest Fields. The server resolves and validates the DID according to the applicable DID Method Binding Profile, verifies that the selected verification method is authorized for authentication, verifies replay protections, and then makes a separate authorization decision.

Introduction

The Agent Identity layer enables agents operated by different platforms, organizations, and deployment environments to authenticate without a proprietary identity federation. Decentralized Identifiers (DIDs) are used as the identity primitive, while the HTTP authentication protocol remains independent of any particular DID method.

DID creation, resolution, update, deactivation, and method-specific trust guarantees are defined by the applicable DID method and by DID Method Binding Profiles. The did:wba DID Method Specification is maintained as a separate document.

Scope

This specification defines:

This specification does not define:

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.

A conforming implementation of the AI Agent Protocol Web DID profile MUST support the did:wba, did:web, and did:webvh Binding Profiles defined in DID Method Binding Profiles. Implementations MAY support additional DID methods through additional binding profiles.

Terminology

Agent Identity
The DID authenticated by the process defined in this specification.
DID Method Binding Profile
A set of method-specific resolution, validation, and security rules that connects a DID method to the common authentication protocol.
binding key
A verification method whose key material is cryptographically bound to a method-specific identifier. The term applies only where the selected DID method defines such a binding.
verifier
The HTTP server that authenticates a signed request.

Agent Identity Model

Design Principles

The design reuses mature Web infrastructure, including DNS, HTTPS, Web PKI, HTTP caching, and ordinary Web hosting, while preserving the decentralized identity model. Each platform may retain its own account and domain management system, while agents interoperate through resolvable DID Documents and standardized verification methods.

Common authentication and authorization behavior is defined independently of any one DID method. Creation, resolution, update, deactivation, and method-specific validation remain governed by the selected DID method. An implementation MUST NOT assume that a security property defined by one DID method also applies to another DID method.

The DID method name encoded in the DID is authoritative. Implementations MUST select the resolver and Binding Profile from the DID itself and MUST NOT require duplicate metadata declaring the same DID method.

A DID is a verifiable identifier and is not necessarily a stable human-readable name. Rotation and persistence semantics are method-specific. An upper-layer naming system MAY provide stable user-facing references.

Authentication and Authorization Boundary

Successful authentication establishes control of a verification method authorized by the DID Document's authentication relationship. It does not grant access to any resource.

After authentication succeeds, the server MUST independently evaluate its authorization policy. A server MUST return an authorization failure, such as 403 Forbidden, when the authenticated DID lacks permission to access the requested resource.

DID Resolution and Verification Method Selection

The keyid parameter in Signature-Input MUST be an absolute DID URL that identifies a verification method. The verifier MUST extract the primary DID from that DID URL and select the corresponding DID Method Binding Profile from the method name encoded in the DID.

The verifier MUST perform the following steps:

  1. Validate that keyid is a syntactically valid absolute DID URL.
  2. Extract the primary DID from keyid.
  3. Select a supported DID Method Binding Profile based only on the DID method name.
  4. Resolve and validate the DID according to that Binding Profile.
  5. Verify that the resolved DID Document id matches the requested DID.
  6. Verify that the DID has not been reported as deactivated.
  7. Dereference keyid to a verification method in the validated DID Document.
  8. Verify that the verification method is authorized by the authentication relationship.
  9. Apply every additional method-specific postcondition defined by the selected Binding Profile.

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

Cross-Platform Identity Authentication over HTTP

A client authenticates the server using HTTPS and authenticates itself by signing the HTTP request with a verification method authorized by its DID Document. The verifier resolves and validates the DID, verifies the verification relationship, validates the request signature, and separately evaluates authorization.

The first request uses the Signature-Input and Signature fields defined by RFC 9421. When a request contains a message body, it also uses the Content-Digest field defined by RFC 9530. 

sequenceDiagram
    participant Client as Agent Client
    participant Server as Agent Server
    participant Resolver as DID Resolver

    Client->>Server: Signed HTTP request
    Server->>Resolver: Resolve DID selected from keyid
    Resolver->>Resolver: Apply method-specific validation
    Resolver-->>Server: Validated DID Document
    Server->>Server: Verify authentication relationship,
                    HTTP signature, digest, time, and replay state
    Server->>Server: Evaluate authorization independently
    Server-->>Client: HTTP response; optional access token

    Client->>Server: Subsequent request with access token
    Server-->>Client: HTTP response
DID-method-agnostic authentication flow

Initial Request

Request Header Format

Clients MUST send authentication information using the Signature-Input and Signature fields defined by RFC 9421. When a request includes a message body, the client MUST also send Content-Digest as defined by RFC 9530.

The minimum signature coverage set is:

  • @method;
  • @target-uri;
  • content-digest, when the request contains a message body.

Recommended additional covered components are:

  • @authority;
  • content-type;
  • content-length.

The signature parameters have the following requirements:

  • keyid: MUST be a complete DID URL identifying a verification method in the client's DID Document.
  • created: MUST be present.
  • expires: SHOULD be present.
  • nonce: MAY be present. If the server issued a challenge nonce, the client MUST use that nonce.
  • alg: OPTIONAL. A verifier may determine the algorithm from the verification method type identified by keyid.

The client MUST sign with a key authorized by the DID Document's authentication relationship. Any additional key-selection requirement is defined by the selected DID Method Binding Profile.

Signed request using a did:web identity:

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:web:client.example:agents:alice#key-1"
Signature: sig1=:BASE64_SIGNATURE:

Signature Generation

  1. If the request contains a message body, calculate Content-Digest according to RFC 9530.
  2. Select a verification method authorized for authentication and permitted by the selected DID Method Binding Profile.
  3. Construct Signature-Input, covering at least the required components defined above.
  4. Construct the signature base according to RFC 9421.
  5. Sign the signature base using the selected private key.
  6. Send Signature-Input, Signature, and, when applicable, Content-Digest to the server.

Server-Side Verification

The verifier MUST perform the following checks:

  1. Verify that Signature-Input and Signature are present and syntactically valid.
  2. When the request contains a message body, verify Content-Digest against the received content.
  3. Extract keyid and the primary DID.
  4. Resolve and validate the DID and verification method as specified in DID Resolution and Verification Method Selection.
  5. Apply the method-specific validation rules defined by the selected DID Method Binding Profile.
  6. Reconstruct the signature base from the actual request and verify the HTTP Message Signature according to RFC 9421.
  7. Verify that created and expires are within the server's accepted time window. A window of one to five minutes is recommended and MAY be configured by the deployment.
  8. Apply the replay-protection requirements below.
  9. Evaluate authorization independently.

Signature Verification

  1. Parse the signature label, covered components, parameters, and signature value.
  2. Reconstruct the signature base according to RFC 9421.
  3. Obtain the validated verification method identified by keyid.
  4. Select the verification algorithm from the verification method type and the supported cryptographic implementation.
  5. Verify the signature using the corresponding public key.
  6. Include the Content-Digest result in the authentication decision whenever a message body is present.

Replay Protection

  • The server MUST reject signatures outside its accepted created/expires window.
  • For a direct proof, the server SHOULD maintain a short-term replay cache keyed by (keyid, nonce), (keyid, jti), or an equivalent unique tuple.
  • A nonce issued by a server challenge MUST be single-use.
  • The replay-cache retention period SHOULD be longer than the maximum accepted signature lifetime.
  • Nonces MUST be generated using a cryptographically secure random number generator.

Access Token after Successful Authentication

After successful authentication and authorization, a server MAY return an access token so that subsequent requests do not require DID resolution and HTTP signature verification on every request. The token format is an implementation choice. JWT, as defined by RFC 7519, is one possible format.

The following token-generation details are non-normative. A JWT payload might contain: 

{
  "sub": "did:web:client.example:agents:alice",
  "iat": 1733402096,
  "exp": 1733488496,
  "scope": "orders.read orders.write"
}

When a token is returned using this protocol, the server MUST return it in the Authentication-Info response field and MUST NOT place it in an Authorization response field. 

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

Sender-constrained access tokens SHOULD be preferred to reduce replay risk after token disclosure. This specification does not define a complete sender-constrained token profile. Implementations MAY reserve a key-binding claim such as cnf and require a proof bound to the token in subsequent requests.

Until a sender-constrained profile is selected, a deployment MAY use Bearer. The client sends a Bearer token in subsequent requests: 

Authorization: Bearer <access_token>

The server MUST validate the token's signature, expiration, audience or resource restrictions, subject, and authorization scope according to the selected token format and local policy.

Error Handling

401 Unauthorized

The server may return 401 Unauthorized when signature verification fails, digest verification fails, a signature is expired, replay is detected, DID validation fails, or a challenge nonce is required.

Challenge information is returned through WWW-Authenticate. The server MAY advertise expected signature components through Accept-Signature. 

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

The AgentDID authentication scheme name is method-neutral. The DID method is selected from keyid.

ErrorMeaning
invalid_requestThe request is malformed or missing required fields.
invalid_nonceThe nonce is invalid, reused, or does not match the challenge.
invalid_timestampThe signature time is outside the accepted window.
invalid_didThe DID is malformed, cannot be resolved, or returns an invalid DID Document.
unsupported_did_methodThe implementation does not support the DID method or Binding Profile.
invalid_did_historyMethod-specific history validation, including did:webvh validation, failed.
invalid_signatureThe HTTP Message Signature is invalid.
invalid_verification_methodThe verification method is absent, unsupported, or not authorized for authentication.
invalid_content_digestThe digest does not match the request content.
invalid_access_tokenThe access token is invalid.
forbidden_didThe DID authenticated successfully but is not authorized.

When a challenge nonce is returned, the client MUST generate a new signature using that nonce. Clients and servers MUST limit retry counts to prevent an infinite challenge loop.

403 Forbidden

A server should return 403 Forbidden when identity authentication succeeds but the authenticated DID lacks permission to access the resource.

Privacy Considerations

Reusing the same DID across unrelated contexts can enable correlation. DID providers and agents SHOULD support purpose-specific DIDs, role-specific keys, or other pairwise or scoped identifiers where stable global correlation is unnecessary.

A stable upper-layer name MAY refer to a DID that changes according to the lifecycle rules of its DID method. Such naming and migration mechanisms are outside this specification.

DID resolution can reveal which identities a verifier is contacting. Implementations SHOULD consider privacy-preserving DNS resolution, caching, proxying, and data-minimization policies appropriate to their environment.

Security Considerations