[a]authored byinflow
Introduction

Use AEP with discovery and payment

AEP enrolls and authenticates Agents. Discovery helps them find Services, while the application decides access and a payment protocol handles any charge.

Finding a Service is separate from enrollment

An Agent can start with a Service origin it already knows. It may also find a Service and an operation through the Offering Discovery Protocol. ODP discovery is useful, but it is not required to use AEP.

When enrollment is needed, the Agent retrieves that Service's AEP Inspect document. The document advertises the Service's enrollment requirements, supported commands, identity methods, and protected-resource authentication methods. The Agent follows those AEP requirements regardless of how it found the Service.

Start with Inspect a Service to read an AEP advertisement.

Enrollment establishes recognition

The Agent presents an identity method the Service accepts and sends a signed Enroll request. The Service decides whether that identity is active, pending further work, or rejected. AEP also defines Status, command authentication, and optional session-credential Grant and Revoke operations.

Recognition by the Service is not permission to perform every operation it offers. Enrollment answers whether the Service recognizes the Agent; the application still decides whether the Agent may access a particular resource.

The application authorizes the request

A protected resource can challenge an unauthenticated Agent. The Agent then selects an authentication method the Service advertises and presents its credential on a safe retry. AEP authentication establishes which Agent made that request and, when applicable, the credential's scopes.

The protected application evaluates its own resource policy and scopes after authentication. It can deny an authenticated Agent that lacks permission. AEP does not define the application's business decision or authorize an operation simply because enrollment succeeded. See Protected-resource access for the request and retry rules.

Payment is a separate requirement

A resource can be free, paid, authenticated, or both authenticated and paid. AEP does not define payment terms or settlement; MPP or x402 handles a live payment requirement. For a resource that requires both, AEP authentication succeeds before payment processing begins.

A payment protocol may need the standard Authorization field. When an AEP credential normally uses that field, an Agent combining AEP with payment should select AEP-Authorization before the authenticated retry. A Service-issued API key continues to use its Service-selected header. These carriers keep authentication and payment credentials separate.

One request path

Suppose an Agent wants to call a Service's protected, paid search operation. The same boundaries apply if the Agent found that operation through ODP or already knew its URL.

  • Find the operation: Use ODP discovery if needed; otherwise start with the known Service and resource.
  • Establish Agent access: If the resource requires AEP, inspect the Service, enroll when necessary, and authenticate the protected request.
  • Satisfy remaining requirements: The application evaluates permission, and a payment protocol handles any live charge. When both AEP and payment apply, payment processing follows AEP authentication.
  • Receive the result: The Service's search operation produces the response; neither AEP nor ODP defines its contents.

Hosted identity is optional

An Agent may manage its own identity and signing key. It may instead use a Platform to host identity material or sign its assertions. AEP does not require a Platform, and the Service still verifies the Agent's identity and assertions for itself.

On this page