Foundations

HTTP Signatures Profile

AAuth doesn't reinvent signing — it profiles two existing specs. This page lists exactly what AAuth pins down: the algorithms it requires, the components that MUST be covered, the timestamp window, and the well-known document names used for key discovery.

How the specs compose

AAuth SPEC

Profiles 4 schemes, pins Ed25519/P-256, fixes base covered components, sets 60s validity window, defines dwk values.

RFC 9421

HTTP Message Signatures. Defines Signature-Input, Signature, covered components, and signature base construction.

Signature-Key draft

Defines the Signature-Key header with 5 schemes (hwk, jkt-jwt, jwks_uri, jwt, x509), Accept-Signature sigkey, and Signature-Error.

Every AAuth request includes three headers — Signature-Key, Signature-Input, Signature — and follows the profile rules below.

Algorithms

Algorithm	Level	Reference	Notes
Ed25519 (EdDSA)	MUST	RFC 8032	Recommended default for both agents and servers.
ECDSA P-256 (deterministic)	SHOULD	RFC 6979	Deterministic signatures per RFC 6979 required.
alg=none	MUST NOT	—	Never accepted by AAuth verifiers.

Spec: §HTTP Message Signatures Profile · Signature Algorithms

Covered components

Every AAuth signature MUST cover the four base components. Resources can require more via the additional_signature_components field in their metadata. A missing component returns invalid_input with required_input.

Component	Requirement	Why
@method	base	HTTP request method (RFC 9421 §2.2.1)
@authority	base	Target host (RFC 9421 §2.2.3)
@path	base	Request path (RFC 9421 §2.2.6)
signature-key	base	Binds Signature-Key header to the signature — prevents scheme/identity substitution
authorization	conditional	REQUIRED when presenting an AAuth-Access token — binds token to request
content-digest	optional	Body integrity (RFC 9530). Resources opt in via additional_signature_components

Signature parameters

created (Unix time)

REQUIRED on every signature. The server rejects signatures outside a validity window relative to its current time.

Signature-Input: sig=("@method" "@authority"
    "@path" "signature-key");created=1730217600

Validity window (default 60s)

Resources can advertise a larger or smaller window via signature_window in their metadata. Clock skew must be handled by NTP.

{
  "signature_window": 120
}

Key discovery — `dwk` values

The Signature-Key draft defines the dwk ("dot well-known") parameter abstractly. AAuth pins four concrete values — one per role — each rooted at {iss}/.well-known/{dwk}.

dwk value	Published by	Contains
aauth-agent.json	Agent provider	agent token issuer keys
aauth-resource.json	Resource	resource token issuer keys
aauth-person.json	Person server	auth-token & permission keys
aauth-access.json	Access server	auth-token issuer keys

Signature-Key Schemes →

The four schemes AAuth uses (and the one it doesn't).