Protected-resource authentication
Authenticate a resource request, not another AEP command
Enroll and Status manage the Agent's relationship with a Service. A protected resource is an application endpoint the Agent wants to use. Its authentication establishes which Agent made that request; the Service separately applies its enrollment and application-access policies. Payment, when required, is another step after AEP authentication succeeds.
The Service advertises accepted protected-resource methods in Inspect authentication.methods, in preference order. aep-jwt means a client assertion with op equal to authenticate; other values identify registered session-credential grant types. If the field is absent, the Service advertises no protected-resource authentication method. This advertisement is separate from the baseline assertions accepted by AEP command endpoints. authenticate is not a command endpoint and must not appear in commands.supported.
A resource must reject an assertion for enroll, grant, revoke, or status. An AEP command endpoint must reject authenticate and every other non-matching operation. The shared assertion format does not make the operations interchangeable.
Start from a valid AEP challenge
An Agent may first request the exact resource without an AEP credential. If authentication is required, the resource answers with 401 Unauthorized and a WWW-Authenticate challenge naming the Service DID and Inspect URL. For example, a request to https://api.example.com/protected/report could receive:
HTTP/1.1 401 Unauthorized WWW-Authenticate: AEP service_did="did:web:api.example.com",inspect="https://api.example.com/.well-known/aep"
The Agent begins AEP discovery only when the response contains a valid AEP challenge with both service_did and inspect. An unrelated 401 is not permission to provision an identity or send credentials. Before discovery or authenticated retry, the Agent must know it can reproduce the original request body exactly; otherwise it stops rather than replaying a changed operation.
After inspecting the Service and selecting an advertised method, an Agent using aep-jwt can retry with a fresh assertion. The assertion uses op=authenticate, sets aud to the Service DID, and binds resource to the protected request target:
GET /protected/report HTTP/1.1 Host: api.example.com Authorization: AEP <jwt>
This example uses the ordinary Authorization field. The assertion cannot be reused for another resource or AEP command. An Agent may also use a session credential when its registered grant type appears in the Service's authentication.methods and the credential is valid for the request.
Choose one AEP credential carrier
Protected resources accept AEP client assertions and authorization-based session credentials in Authorization or AEP-Authorization. A generic Agent defaults to Authorization. For a request that also uses MPP or x402, the Agent should choose AEP-Authorization before its first authenticated retry and keep that choice for the operation. The dedicated field carries the complete value, such as AEP-Authorization: AEP <jwt> or AEP-Authorization: Bearer <token>. This leaves Authorization: Payment <credentials> or PAYMENT-SIGNATURE available for payment.
The Agent sends at most one AEP credential carrier in a request. The Service checks AEP-Authorization first, using Authorization only when the dedicated field is absent. If both contain AEP-recognized credentials, it rejects the request as not_recognized; it does not choose between them. An invalid dedicated credential cannot fall back to another AEP credential. Repeated or combined AEP-Authorization values are likewise rejected as ambiguous.
An AEP-issued API key is different: the Agent uses exactly the header selected by the Service in the Grant response, not a second generic representation. Both authorization fields contain sensitive values and must be redacted from logs and telemetry. After AEP authentication, its layer must leave an unrelated payment Authorization value untouched; payment processing follows AEP authentication. See Session credentials for credential formats.
Recheck the request after a redirect
A credential never travels to a different origin merely because the resource redirects there. On a same-origin redirect, the Agent may follow with its credential only if that credential still authorizes the redirected request. With aep-jwt, it issues a new assertion whose resource names the redirect target and keeps the AEP carrier already selected for the operation.
On a cross-origin redirect, the Agent removes Authorization, AEP-Authorization, PAYMENT-SIGNATURE, all AEP assertions and session credentials, and any payment credential. It restarts with an anonymous request at the new origin and requires that origin's valid AEP challenge before authenticating there. A Service-selected API-key header must not be copied across the origin change. These rules also apply when authentication and payment are composed.
Verify identity, then decide application permission
For aep-jwt, the resource verifies the assertion's signature, audience, authenticate operation, resource binding, time window, and unique jti. It must consume jti atomically before accepting the assertion so simultaneous replays cannot both succeed. Successful authentication establishes an Agent principal and credential metadata, including granted scopes when applicable.
The protected application then evaluates its own resource policy and scopes. A valid credential lacking permission produces 403 insufficient_scope, not an authentication failure. Missing credentials use authentication_required; a method absent from authentication.methods uses unsupported_authentication_method. Malformed or expired credentials, wrong operation, audience, or resource, and replayed assertions use the non-disclosing not_recognized error. Do not reveal which recognition check failed.
For step-by-step integration, continue to Protect a resource or Access a protected resource.
