[a]authored byinflow
Introduction

Understand the AEP model

Know who participates in enrollment, what a Service advertises, and how an Agent authenticates after it enrolls.

Participants

AEP is used when software acting as an Agent needs a Service to recognize it. The Service publishes its requirements; the Agent introduces a verifiable identity and requests enrollment; the Service makes the decision. An Owner, Platform, or Verifier may help establish identity or satisfy requirements, but none is required in every integration or replaces the Agent-to-Service exchange.

  • Agent: Software that holds or controls a signing key and sends AEP requests.
  • Service: The HTTP server that publishes enrollment requirements and decides whether to enroll or recognize an Agent.
  • Owner: The person or organization that controls an Agent. A Service may request Owner-related claims or require Owner action.
  • Platform: An optional operator that hosts Agent identity material or signs on an Agent's behalf. The Service still verifies the Agent's requests.
  • Verifier: A party that checks claims about an Agent or Owner. AEP does not prescribe the attestation format it might issue.

Inspect document

The Service publishes its JSON Inspect document at /.well-known/aep. It identifies the Service and advertises the commands, identity methods, claim requirements, and endpoint configuration available to an Agent.

The Agent reads that advertisement before it sends an authenticated command. It invokes only commands listed by the Service; it does not infer that an unlisted command exists. The document also lists authentication methods for protected application resources, which are separate from command authentication.

See Discovery and Inspect for the document fields and retrieval rules.

Identity and client assertions

An Agent uses an identity method accepted by the Service. Its cryptographic key signs a client assertion: a short-lived JSON Web Token that identifies the Agent and binds the request to the Service and the operation being performed. When using this baseline method, the Agent signs an assertion for each authenticated AEP command request.

The Agent identity and assertions guide covers signing and identity choices.

Every exposed Enroll, Grant, Revoke, or Status command accepts the baseline client assertion. A protected application resource accepts only methods advertised in authentication.methods; it accepts a client assertion only if aep-jwt is listed there.

Enrollment and status

Enroll asks the Service to recognize an Agent identity. An initial decision can be active, pending, or rejected. Pending means the Service has not finished its decision; the Agent can call Status to obtain the current lifecycle state.

A claim value submitted by an Agent is not automatically a verified claim. The Service may be verifying a submitted value, waiting for another requirement, or waiting for Owner action. These are separate reasons for a pending state. Read Enrollment lifecycle and Owner action for the full state model.

Session credentials

A Service may support Grant to issue a session credential. An Agent can present that credential on later requests according to its grant type, instead of signing a new assertion for every protected-resource request. Grant is optional; an Agent can enroll without obtaining a session credential.

The Service gives each issued credential a credential_id so the Agent can store or manage it. The identifier is not the credential secret presented to a protected resource. Baseline client assertions remain available for authenticated AEP commands even when the Agent has a session credential. See Session credentials for grant types, use, expiry, and revocation.

Next steps

On this page