Enrollment lifecycle and Owner action

One Agent identity, one Service decision

An enrollment state describes how one Service currently treats an Agent identity. Enroll creates the initial decision for that identity; Status reads the current decision later. A successful response to either command returns 200 OK with a lifecycle status. That field is not an HTTP status code, and it does not by itself authorize every application operation.

For a new enrollment, the Service can initially return active, pending, or rejected. An existing record can have any of the six lifecycle states below. The Service controls its enrollment decision; AEP gives Agents a shared vocabulary for observing it.

Respond to the six states

These meanings do not define a universal transition diagram. A Service's policy determines when it changes a state and what separate process, if any, can resolve a disabled or rejected identity.

Read the separate pending signals

The lifecycle state answers whether the Agent is operational. Additional fields explain work still outstanding. verification_pending names claims already submitted but awaiting asynchronous verification. requirements_pending names requirements the Agent still needs to satisfy. They are not aliases: an email under verification is not an email that was never supplied.

owner_action_required is independent of both lists. When its string value is true, the Agent's Owner must complete an out-of-band action before the identity can become or remain active. The Agent should surface that need to the Owner rather than guessing at an action or retrying Enroll. The Service determines the action and how it communicates it.

{
  "owner_action_required": "true",
  "status": "pending",
  "verification_pending": ["contact.email"]
}

This response reports one submitted claim awaiting verification and a separate Owner action. It does not say that another requirement is missing. Either pending list can appear on Enroll or Status, and either can appear without the Owner-action flag. Empty lists are omitted; absence means there are no items in that category. The lists contain names, never claim values.

The Claims and verification guide explains how claims reach this point and why a submitted value is not proof.

Follow changes with Status, not Enroll

After a pending response, the Agent can call an advertised Status command to read the Service's current record. When present, since is the timestamp of the last state transition, not the time of the first enrollment request. A later Status response can show a changed state without a new Enroll request.

If the authenticated Agent already has an enrollment record, Enroll returns that record's current lifecycle representation. Even with a new idempotency key, Enroll does not renew or replace the record, rerun enrollment policy, or reset its timestamps. Use Check status for the Agent-side request and response.

Do not confuse state with a blocked-operation error

A 200 OK Enroll or Status response with status equal to suspended reports a lifecycle state. If the Agent then attempts an operation that the Service blocks, that operation can receive a Problem Details error such as identity_suspended. The error describes the failed operation; it does not change the meaning of the earlier lifecycle response.

Likewise, an operation blocked while verification is unfinished can return a verification_pending error, and unmet required claims can produce requirements_unmet. Error details may name the outstanding claims or requirements after the Agent is recognized, but must not include claim values. Pending Enroll and Status responses remain successful lifecycle responses. See Errors and idempotency for the full error model, or Claims and approval for a concrete sequence.