Examples

Enrollment

Follow one Agent from Service discovery through an immediately active enrollment, without optional Claims or session credentials.

This is the baseline exchange between a Service at https://api.example.com and an Agent with its own did:web identity. The Service asks for no Claims and makes its enrollment decision synchronously. The Enroll an Agent quick start explains the implementation procedure; this example shows the messages and what each one establishes.

01agent

Inspect the Service before signing

The Agent sends GET https://api.example.com/.well-known/aep without a client assertion. The Service returns 200 OK and application/aep+json with this complete minimal Inspect document:

{
  "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"}
}

The origin encoded by the Service DID matches the Inspect URL's origin. Its command list permits Enroll and Status, identity.methods accepts did:web, and http.endpoint_base places Enroll at /aep/enroll. No claims catalog or Grant Type is advertised, so this example submits no Claim values and requests no session credential.

02agent

Sign an assertion for this Enroll operation

The Agent chooses an ES256 key from its DID document and signs a compact JWT. Below are its decoded header and claims for explanation; the Agent sends the signed compact serialization in the HTTP header, not this JSON object. The timestamps and jti are illustrative and must not be reused.

{
  "header": {
    "alg": "ES256",
    "kid": "did:web:agent.example.com:agents:123#key-1",
    "typ": "JWT"
  },
  "claims": {
    "aud": "did:web:api.example.com",
    "exp": 1748428860,
    "iat": 1748428800,
    "iss": "did:web:agent.example.com:agents:123",
    "jti": "01J0AEPVECTORASSERTION00000001",
    "op": "enroll",
    "sub": "did:web:agent.example.com:agents:123"
  }
}

iss and sub name the Agent DID, and the DID portion of kid names that same identity. aud is the inspected Service DID, not the Enroll URL. op binds the assertion to Enroll; iat and exp give it a short lifetime, and jti makes this use distinguishable from a retry. A fresh retry needs a fresh assertion and jti even when the request's idempotency key stays the same.

03agent

Send the Enroll request

The Agent posts to the advertised Enroll endpoint. Its body identifies the same Agent DID as the assertion. The required HTTP Idempotency-Key makes an unchanged retry safe if the response is lost. Because this Service requested no Claims, there is no claims member.

POST /aep/enroll HTTP/1.1
Host: api.example.com
Accept: application/aep+json
Content-Type: application/aep+json
Authorization: AEP <signed-jwt>
Idempotency-Key: 9f8a4d2e-1c3b-4f5e-8b7a-000000000000

{
  "agent_did": "did:web:agent.example.com:agents:123"
}

The Service verifies the assertion's signature, DID identity, audience, operation, lifetime, and replay identifier before applying enrollment policy. It must not reveal which recognition check failed. The Agent identity and assertions guide covers those checks in detail.

04service

Return the enrollment decision

The Service accepts this Agent immediately and returns a successful lifecycle representation:

HTTP/1.1 200 OK
Content-Type: application/aep+json

{"status":"active"}

active establishes that the Service has an operational enrollment record for this Agent identity. It does not issue a session credential or grant permission for every protected resource. This Inspect document advertises no protected-resource authentication method, so the exchange ends here. When another Service does advertise one, an Agent must still use a method that resource accepts, and the application can still deny an authenticated request.

Next steps

  • Claims and approval: Follow an enrollment that remains pending while verification or Owner action is required, then check Status to learn when it becomes active.
  • Protected-resource access: Follow application requests after active enrollment using an authentication method the Service advertises.