AEP Claim Values

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The Agent Enrollment Protocol (AEP) lets a Service advertise claim names in its Inspect document and lets an Agent submit corresponding claim values in an Enroll request. AEP core defines the negotiation and HTTP transport mechanics using HTTP semantics [RFC9110]. This document defines interoperable names and value shapes for common person and contact claims.¶

The catalog is intentionally small. It gives implementations a common baseline without making AEP a general identity-proofing, know-your-agent, payments, or compliance data model. Future documents can define additional claim names and additional optional members for object-valued claims.¶

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

This document uses the Agent, Service, Owner, Inspect document, and Enroll terms from AEP core [AEP-CORE]. JSON values are encoded as described by [RFC8259].¶

Claim Name:

A dotted lowercase identifier advertised by a Service and used as a member name in an Enroll request's claims object.¶

Claim Value:

The JSON value associated with a Claim Name in an Enroll request.¶

4. Claim Negotiation Model

A Service requests claims by listing Claim Names in claims.required, claims.preferred, or claims.optional in its Inspect document. An Agent submits supported Claim Values in the Enroll request claims object.¶

Claim Values submitted during Enroll are assertions made by the Agent or Owner, unless another AEP document or Service policy requires an attestation, proof, or asynchronous verification step. The presence of a Claim Value does not by itself prove that the value is true.¶

Services MUST NOT require claims absent from their Inspect document for the same enrollment interaction. Services MAY reject unsupported, malformed, or policy-disallowed Claim Values with requirements_unmet as defined by AEP core.¶

5. Forward Compatibility

Claim Name registration is additive. A future document MAY define new Claim Names without changing the meaning of existing Claim Names.¶

Agents MUST ignore unknown Claim Names in claims.optional and claims.preferred. An Agent that does not understand a Claim Name in claims.required cannot satisfy that requirement unless local policy or an extension supplies support for that Claim Name.¶

Services MUST ignore unknown submitted Claim Names unless local policy requires rejection. Services SHOULD reject claim names that are absent from the Inspect document only when accepting extra values creates a privacy, security, or compliance risk.¶

Object-valued claims defined by this document are open to additional members. Consumers MUST ignore object members they do not understand unless a later document explicitly changes that rule for a new Claim Name. Adding an optional member to an existing object-valued claim is non-breaking. Removing a required member, changing the JSON type of a Claim Value, or changing the meaning of an existing member is breaking and requires a new Claim Name.¶

Claim Names defined by this document use unversioned names because the names identify stable concepts. Versioning belongs in new Claim Names only when the wire value semantics are incompatible.¶

6. Claim Catalog

This section defines Claim Names for common person and contact information.¶

7. Person Claims

person.birthdate:

A string containing a full-calendar birth date in the RFC 3339 full-date form, for example 1990-04-12 [RFC3339]. The value is a date, not a date-time.¶

person.first_name:

A non-empty string containing the person's given name.¶

person.last_name:

A non-empty string containing the person's family name.¶

person.username:

A non-empty string containing a user-selected or system-assigned username for the person.¶

8. Example

The following Enroll request fragment shows the Claim Values defined by this document:¶

{
  "claims": {
    "contact.address.primary": {
      "city": "San Francisco",
      "country": "US",
      "line1": "123 Market Street",
      "postal_code": "94105",
      "region": "CA"
    },
    "contact.email": "owner@example.com",
    "contact.mobile": "+14155550100",
    "person.birthdate": "1990-04-12",
    "person.first_name": "Ada",
    "person.last_name": "Lovelace",
    "person.username": "ada"
  }
}

9. IANA Considerations

This document requests creation of the "AEP Claim Names" registry. The registration policy is Specification Required as defined by RFC 8126 [RFC8126]. Designated experts are requested to verify that new registrations define a stable Claim Name, JSON value type, compatibility behavior, privacy considerations, and security considerations.¶

Each entry contains:¶

The registry contains the following entries:¶

10. Security Considerations

Claim Values can influence enrollment, protected-resource authorization, fraud controls, compliance review, and account recovery. Services MUST NOT treat an unverified Claim Value as independently verified. When a Service requires proof, it needs an attestation, proof, out-of-band verification workflow, or local verification procedure appropriate to the risk.¶

Services SHOULD validate Claim Value syntax before storing or acting on a value. Services MUST treat claim parsing failures as requirements_unmet, invalid_request, or another AEP core error that does not reveal unrelated identity-recognition state.¶

Claim Values are submitted through the authenticated and idempotent Enroll operation defined by AEP core. Implementations MUST apply the authentication, replay, idempotency, and anti-enumeration requirements from AEP core before acting on Claim Values. Receiving the same Claim Value through another unauthenticated interface does not make it an authenticated AEP assertion.¶

Claim Values can contain attacker-controlled strings. Services and Agents need ordinary input-handling protections when displaying, storing, logging, or forwarding values.¶

Services MUST bound the encoded size, string length, object depth, and member count they accept under local policy. Audit records SHOULD identify the policy decision and verification method without copying raw Claim Values.¶

11. Privacy Considerations

Claim Values can contain personal data and contact information. Services SHOULD request the minimum claims required for the interaction and SHOULD place non-essential claims in claims.preferred or claims.optional rather than claims.required.¶

Agents SHOULD send the minimum Claim Values needed to satisfy the Service's Inspect document and the Owner's intended interaction. Agents SHOULD avoid sending birth dates or postal addresses unless those values are requested and necessary.¶

Stable contact details, usernames, birth dates, and addresses can correlate an Owner or Agent across Services. Services SHOULD avoid using Claim Values as cross-Service identifiers. Agents SHOULD prefer Service-specific values when the interaction permits them.¶

Services SHOULD avoid logging raw Claim Values in ordinary logs or telemetry. When retention is required, Services SHOULD minimize stored values, separate sensitive data from operational records, and apply access controls appropriate to personal data.¶

12. References

Author's Address