Internet-Draft AEP did:web June 2026
Kavian Expires 30 December 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-kavian-aep-did-web-identity-method-00
Published:
Intended Status:
Standards Track
Expires:
Author:
N. Kavian
Jarwin, Inc. (InFlow)

The did:web Identity Method for the Agent Enrollment Protocol

Abstract

This document defines the did:web identity method for the Agent Enrollment Protocol (AEP). The method lets an AEP Service verify Agent client assertion JWTs by resolving an Agent did:web identifier to a DID document published over HTTPS.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 30 December 2026.

Table of Contents

1. Introduction

The Agent Enrollment Protocol (AEP) defines an identity-method substrate for authenticated commands [AEP-CORE]. AEP Services advertise enabled identity methods in the Inspect document's identity.methods array.

This document defines the did:web identity method. A Service that enables this identity method accepts Agent identifiers using the did:web DID method [DID-WEB] and resolves verification material from the corresponding HTTPS origin.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Identity Method

The identity method identifier is:

did:web

A Service that enables this identity method lists did:web in the Inspect document:

{
  "identity": {
    "methods": ["did:web"]
  }
}

Services that do not enable this identity method MUST NOT list did:web in identity.methods.

4. Agent Identifiers

An Agent using this identity method identifies itself with a did:web URI.

The Agent DID appears in the client assertion JWT iss and sub claims. The JOSE kid header contains the Agent DID and MAY include a fragment selecting a verification method in the resolved DID document.

{
  "alg": "EdDSA",
  "typ": "JWT",
  "kid": "did:web:agent.example.com:agents:123#key-1"
}
{
  "iss": "did:web:agent.example.com:agents:123",
  "sub": "did:web:agent.example.com:agents:123"
}

The DID portion of kid MUST equal the Agent DID carried in iss and sub.

5. DID Resolution

The Service resolves the Agent DID according to the did:web method specification [DID-WEB]:

Services MUST resolve did:web documents over HTTPS. Plaintext HTTP resolution is not allowed.

The resolved DID document MUST be a JSON object [RFC8259] and MUST contain a verification method referenced by the JWT kid header. The verification method MUST expose a public key in a form the Service can validate against the selected JOSE signing algorithm.

If the Service cannot resolve the DID document, cannot locate the referenced verification method, or cannot use the verification method with the selected JOSE algorithm, client assertion verification fails with the AEP not_recognized error defined by the core protocol.

6. Caching

Services SHOULD cache resolved DID documents and SHOULD honor upstream HTTP cache metadata [RFC9110]. A default cache lifetime of 300 seconds is RECOMMENDED when no shorter upstream lifetime is provided.

Services MUST ensure that cache lifetimes do not prevent timely key replacement after compromise. Services MAY impose a local maximum cache lifetime.

7. IANA Considerations

This document requests registration of did:web in the AEP Identity Methods registry.

Table 1
Field Value
Identity Method did:web
Description DID Web identity method for AEP client assertions
Reference This document

8. Security Considerations

The did:web method relies on the HTTPS origin that publishes the DID document. A Service that accepts an Agent's did:web identity trusts the corresponding web origin to publish the correct verification method.

Services MUST reject did:web client assertions when the resolved DID document does not contain the verification method referenced by kid, when the verification method cannot validate the selected JOSE algorithm, or when the JWT signature does not verify.

Services SHOULD cache DID documents for operational stability but MUST ensure that cache lifetimes do not prevent timely key replacement after compromise.

9. Privacy Considerations

A did:web Agent identity can be correlatable if the same DID is reused across Services. Platforms or Agent operators that require unlinkability SHOULD use a distinct did:web URI and signing key per Service enrollment.

The URI path component SHOULD be opaque and SHOULD NOT reveal the Agent's master identity, account identifier, or target Service.

10. Normative References

[AEP-CORE]
Kavian, N., "The Agent Enrollment Protocol", Work in Progress, Internet-Draft, draft-kavian-agent-enrollment-protocol-01, , <https://datatracker.ietf.org/doc/draft-kavian-agent-enrollment-protocol/>.
[DID-WEB]
W3C Credentials Community Group, "The did:web Method Specification", n.d., <https://w3c-ccg.github.io/did-method-web/>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.

Author's Address

N. Kavian
Jarwin, Inc. (InFlow)