Claims and verification

A submitted claim is an assertion

A claim is a named value the Agent or its Owner supplies to a Service during Enroll. For example, contact.email carries an email address. The Service can use that address for contact or verification, but receiving a correctly formatted value does not prove the mailbox exists or that the Owner controls it.

The Service decides what evidence its enrollment policy requires. It might verify a mailbox out of band, require another form of proof, or accept an assertion where verification is unnecessary. AEP carries the claim and reports outstanding work; it does not declare every submitted value true or prescribe one verification method.

Request claims in Inspect

Before Enroll, the Service advertises the claim names it requests in its Inspect document. Put data genuinely needed for enrollment or legal operation in claims.required. Use claims.preferred or claims.optional for non-essential information. These lists name claims; the Agent supplies values later in its Enroll request.

"claims": {
  "required": ["contact.email"],
  "preferred": [],
  "optional": ["person.username"]
}

Here the Service needs an email address and can also accept a username. Advertising these names lets the Agent decide what it can provide before Enroll. An Agent ignores an unfamiliar optional or preferred name; it cannot assume it can satisfy an unfamiliar required name. See Discovery and Inspect for the complete Inspect document.

Use defined names and value shapes

The AEP Claim Values draft defines interoperable names for common contact and person information. For example, contact.email is an email-address string, contact.mobile is an international telephone-number string, and contact.address.primary is an object with defined address members. A Service can also request a claim defined by another document. A name alone does not define a custom value's shape; its defining document must do that.

The Agent sends supported values under those names in the Enroll claims object, using the advertised list and the Owner's intended interaction to decide what to disclose. The Service validates syntax before relying on a value, then applies its own policy and verification process. It must ignore an unknown submitted claim unless local policy requires rejection. See Enroll an Agent for a complete request.

Report what remains without repeating the data

If the Service accepts the enrollment request but has not finished verifying a submitted value, it can return a successful lifecycle response with status set to pending. The verification_pending list names submitted claims still awaiting asynchronous verification:

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

requirements_pending instead names requirements the Agent still needs to satisfy. These lists are independent and must contain names, never the submitted values. owner_action_required is a third, separate signal: when it is true, the Owner has an out-of-band action to complete. Do not interpret that flag as a synonym for an unverified claim or a missing requirement.

The Agent can use Status to learn when the Service's decision changes. A later protected operation blocked by verification or unmet requirements can receive a Problem Details error; that error is different from the successful Enroll or Status response reporting a pending state. Enrollment lifecycle and Owner action explains those states in detail.

Ask for and retain only what is needed

Contact details, addresses, and birth dates can identify or correlate a person across Services. A Service should keep required claims to the minimum its interaction needs. An Agent should avoid sending unadvertised claims and should not send sensitive values merely because it has them. When the interaction permits it, a Service-specific value reduces cross-Service correlation.

The Service should avoid putting raw claim values in ordinary logs or telemetry. If it must retain them, it should limit storage and access under its policy. Pending response fields need only the claim or requirement names. For a concrete claim-submission and verification sequence, continue to Claims and approval.