Service quick start

Publish an Inspect document

Give Agents one public document that identifies your Service and states which AEP capabilities they can use.

Give Agents a starting point

The Inspect document is the public starting point for an Agent that wants to enroll with your Service. It identifies the Service and advertises the commands and methods Agents may use. Publish it so Agents can decide whether they can proceed without guessing endpoints or sending credentials to learn your capabilities. The example on this page advertises Enroll and Status; those endpoints must work before you publish that advertisement.

Choose an SDK

Use an official SDK to publish Inspect and handle AEP commands, assertion verification, and protocol responses. Choose your language for installation instructions and Service examples; your application supplies its enrollment policy and storage. The rest of this quick start explains what to advertise.

Go: Expose a Service through standard Go HTTP handlers.
Java: Choose a JSON provider and a JDK, Servlet, or Spring HTTP adapter.
Node.js: Use the Service package with an optional framework adapter.
Python: Expose a Service through ASGI.
Rust: Use the Service crate directly or with Tower or Axum.

Choose your Service identity

Choose the HTTPS origin where Agents will fetch Inspect and the Service DID they will use as the audience of client assertions. For a did:web Service, the DID must encode the same origin as the final Inspect response URL. The example below uses https://api.example.com and did:web:api.example.com. Replace both with values for your Service.

Publish the document at that origin's /.well-known/aep path. A Directory entry can help an Agent find your Service, but it does not establish the required relationship between the Inspect response and your Service DID.

Advertise what you support

List the AEP commands your Service actually exposes in commands.supported. Include inspect. This example also lists enroll and status, so the Service must implement both at the paths constructed from http.endpoint_base. With the example base, those operations are POST /aep/enroll and GET /aep/status.

Advertise at least one identity.methods value when you expose Enroll, Status, Grant, or Revoke. The example accepts did:web Agent identities. List signing algorithms your Service accepts; the core protocol requires support for EdDSA and ES256.

Do not list Grant or Revoke without a supported session-credential format in commands.grant_types. If your Service protects application resources, authentication.methods advertises the methods those resources accept. That list is separate from AEP command authentication: exposed Enroll, Status, Grant, and Revoke endpoints must accept the baseline AEP client assertion even when authentication.methods is absent.

Publish the document

This is a complete Inspect document for the capabilities described above. It does not advertise claims, protected-resource authentication, session credentials, or OpenAPI because the example Service has not declared any of them.

{
  "aep_version": "1.0",
  "bindings": {"supported": ["http"]},
  "commands": {"supported": ["inspect", "enroll", "status"]},
  "core": {"signing_algorithms": ["EdDSA", "ES256"]},
  "http": {"endpoint_base": "/aep/"},
  "identity": {"methods": ["did:web"]},
  "service": {"did": "did:web:api.example.com"}
}

Serve this JSON from unauthenticated GET /.well-known/aep with 200 OK and Content-Type: application/aep+json. Network use of the AEP HTTP binding requires TLS 1.3 or later. Do not require an Agent assertion, cookie, or session credential to fetch Inspect.

Send cache metadata such as Cache-Control and ETag so Agents can refresh their view of your capabilities. A default freshness lifetime of 300 seconds is recommended unless your Service needs a shorter policy window. If you change an advertised capability, update the document and its cache validators together.

Check the published result

Fetch https://api.example.com/.well-known/aep without credentials, using your own origin instead of the example. Confirm that the response is successful, its media type is application/aep+json, and its body is valid JSON with the fields required by the Inspect schema.

Check that service.did matches the final response origin, including after any redirect. Then verify every command you advertise exists at its constructed path and accepts the authentication required by that command. If a command is not ready, remove it from the advertisement rather than inviting Agents to call it.

If you request claims, add only the names your enrollment flow handles in claims.required, claims.preferred, or claims.optional. If you provide session credentials or a protected-resource OpenAPI document, add their advertisements only after the corresponding endpoints and resource behavior work. Discovery and Inspect describes how Agents interpret these fields.

Next steps

If Enroll and Status are not ready, follow Accept enrollment and status before publishing the example document. Add those commands to commands.supported only when their endpoints work.