Inspect a Service
Fetch the Inspect document
The Inspect document is the Service's public description of its AEP capabilities. Reading it answers the first practical question for your Agent: can it use an identity method the Service accepts, and is Enroll available? It also identifies the Service and any claims the Service requests. Inspect does not itself enroll the Agent or grant access to an application resource.
Start with the Service's HTTPS origin and send an unauthenticated GET /.well-known/aep request. The successful response must contain JSON with the application/aep+json media type. Do not attach an Agent assertion, a session credential, or application credentials to Inspect.
Treat the document as an advertisement, not proof that every advertised operation will succeed for your Agent. Honor its HTTP cache metadata and refresh an expired copy before calling an AEP command. Discovery and Inspect gives the full response, redirect, cache, and size-limit rules.
Choose an SDK
Use an official SDK to handle Inspect retrieval, identity checks, and the later enrollment commands. Choose your language for installation instructions and runnable Agent examples. The rest of this quick start explains the Service information your application uses.
Check the Service and protocol
Read service.did before doing anything that uses your Agent's identity. For a did:web Service, its DID must encode the same HTTPS origin as the final Inspect response URL. If they differ, reject the document before provisioning identity, requesting a client assertion, or sending credentials. A Directory listing does not replace this check.
Check that your Agent supports the major version in aep_version and one of the advertised bindings.supported values. This quick start uses the AEP 1.0 HTTP binding. A matching version does not imply support for every optional command or method; inspect the advertised lists individually.
Read the enrollment advertisement
The following Inspect document advertises Enroll and Status, accepts did:web Agent identities, and requests a contact email. It advertises no session-credential type or authentication method for protected application resources.
{
"aep_version": "1.0",
"bindings": {"supported": ["http"]},
"claims": {"required": ["contact.email"]},
"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"}
}To use Enroll, your Agent needs a supported identity method and an advertised signing algorithm. In this example, an Agent with a did:web identity and a verification method backed by an EdDSA or ES256 key can prepare an AEP client assertion. The advertised base makes the Enroll endpoint POST /aep/enroll. Do not construct or call a command that is absent from commands.supported.
Plan the requested claims
Read claims.required, claims.preferred, and claims.optional as three distinct requests from the Service. In the example, ask for a contact.email value your Agent is authorized to submit. Do not invent a value or treat submission as verification by the Service.
A required claim that is unavailable does not, by itself, prove that Enroll must be skipped. The Service may return a pending lifecycle state with requirements_pending or reject the attempt with requirements_unmet. Your Agent should determine what it can submit and whether its Owner needs to provide information or approval; the Service decides the enrollment result.
Keep later options separate
authentication.methods advertises methods accepted by protected application resources. Its absence does not remove the baseline AEP client assertion from an exposed Enroll endpoint. Likewise, commands.grant_types describes optional session credentials; your Agent does not need a Grant type to begin Enroll.
If the Service advertises either capability, record it for the later resource-access or credential step. Do not interpret it as an instruction to send a credential with the unauthenticated Inspect request.
Choose the next action
If the Service identity and protocol checks pass, Enroll is advertised, and your Agent has an accepted identity method and signing algorithm, continue to Enroll an Agent. That page covers the client assertion, claim submission, and enrollment response.
If Enroll is absent or the Agent cannot use any advertised identity method or signing algorithm, do not guess an endpoint or send credentials. A missing claim needs an explicit decision about whether to proceed and accept a possible pending or unmet-requirement response.
