Protect a resource
Choose the resource and authentication method
This example protects GET https://api.example.com/v1/orders/123. The Service has already published an Inspect document identifying did:web:api.example.com, and it can determine the requesting Agent's enrollment state. Protecting this application route does not add another AEP command endpoint.
Advertise the method this resource accepts in Inspect authentication.methods. This quick start uses the aep-jwt client-assertion method:
"authentication": {
"methods": ["aep-jwt"]
}This fragment is not a complete Inspect document. The method advertisement is for protected resources; it does not change how Enroll, Grant, Revoke, or Status command endpoints authenticate. Those commands remain bound to their own operations, and authenticate must not appear in commands.supported.
Challenge an unauthenticated request
When an Agent requests the order without an AEP credential, return 401 Unauthorized with an AEP WWW-Authenticate challenge. Its service_did identifies this Service, and its inspect points to the Service's Inspect document:
HTTP/1.1 401 Unauthorized WWW-Authenticate: AEP service_did="did:web:api.example.com",inspect="https://api.example.com/.well-known/aep"
A caller can use that challenge to discover your enrollment and authentication requirements. An unrelated 401 should not be mistaken for this AEP invitation. If the resource will also require payment, the anonymous response is still the AEP challenge; evaluate payment only after AEP authentication succeeds.
Receive one AEP credential
After Inspect and enrollment, the Agent retries the same resource with a fresh assertion. A generic Agent sends it in Authorization:
GET /v1/orders/123 HTTP/1.1 Host: api.example.com Authorization: AEP <jwt>
Your resource must also accept the same AEP <jwt> value in AEP-Authorization. That dedicated field allows Authorization to carry an MPP payment credential, or PAYMENT-SIGNATURE to carry an x402 payment signature, without competing with AEP authentication. Do not treat an AEP-issued API key as another form of this JWT: it uses the exact header selected by the Service when the key was granted.
Accept at most one AEP carrier. Check AEP-Authorization first and use Authorization only when the dedicated field is absent. Reject two AEP-recognized credentials, repeated dedicated fields, or a combined dedicated value as not_recognized. Never fall back from an invalid dedicated credential to another AEP credential. Redact both authorization fields from logs and telemetry.
Verify the assertion for this resource
Resolve the Agent DID identified by the assertion's kid, select its verification method, and verify the signature using an algorithm your Service advertised. Confirm that iss, sub, and the DID portion of kid identify the same Agent. Then check aud against your Inspect service.did and require op=authenticate. An Enroll or Status assertion must not authenticate this route.
The assertion's resource must identify the normalized absolute HTTPS request target, here https://api.example.com/v1/orders/123. Check iat and exp under the protocol's time-window rules, and accept each jti only once. Consume the replay identifier atomically before accepting the assertion so concurrent copies cannot both pass. The Identity methods and client assertions page covers the full verification contract.
A bad signature, unknown Agent, wrong audience or operation, wrong resource, expired assertion, or replay fails with the non-disclosing not_recognized error. Do not reveal which recognition check failed. Check the Agent's enrollment state before allowing resource use; a recognized but pending or disabled identity can be blocked with the corresponding lifecycle error.
