Network Working Group N. Kavian Internet-Draft Jarwin, Inc. (InFlow) Intended status: Standards Track 23 July 2026 Expires: 24 January 2027 AEP Claim Values draft-kavian-aep-claims-00 Abstract This document defines a claim-value catalog for the Agent Enrollment Protocol (AEP). It specifies stable claim names and forward- compatible JSON value shapes that Agents can submit during enrollment when requested by a Service Inspect document. 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. Kavian Expires 24 January 2027 [Page 1] Internet-Draft AEP Claims July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Claim Negotiation Model . . . . . . . . . . . . . . . . . . . 3 5. Forward Compatibility . . . . . . . . . . . . . . . . . . . . 3 6. Claim Catalog . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Contact Claims . . . . . . . . . . . . . . . . . . . . . 4 7. Person Claims . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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]. Kavian Expires 24 January 2027 [Page 2] Internet-Draft AEP Claims July 2026 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. Kavian Expires 24 January 2027 [Page 3] Internet-Draft AEP Claims July 2026 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. 6.1. Contact Claims contact.email: A string containing an email address for the Owner or Agent operator. The value MUST conform to the Mailbox rule in Section 4.1.2 of RFC 5321 [RFC5321], as referenced by the JSON Schema email format. The value is intended for contact and verification workflows and does not imply that the Service has verified control of the mailbox. Syntax validation does not establish that the mailbox exists or that the Owner or Agent controls it. contact.mobile: A string containing a mobile telephone number in international form. The value begins with +, followed by 2 to 15 decimal digits, and the first digit after + is not zero; for example, +14155550100. The value is intended for contact and verification workflows and does not imply that the Service has verified control of the number. contact.address.primary: An object containing a primary postal address for the Owner or Agent operator. The object fields defined by this document are: Kavian Expires 24 January 2027 [Page 4] Internet-Draft AEP Claims July 2026 +=============+=============+=============================+ | Member | Requirement | Description | +=============+=============+=============================+ | line1 | Required | Non-empty first address | | | | line. | +-------------+-------------+-----------------------------+ | line2 | Optional | Second address line. | +-------------+-------------+-----------------------------+ | city | Required | Non-empty locality or city. | +-------------+-------------+-----------------------------+ | region | Optional | State, province, region, or | | | | other subdivision. | +-------------+-------------+-----------------------------+ | postal_code | Optional | Postal or ZIP code. | +-------------+-------------+-----------------------------+ | country | Required | Two uppercase ASCII letters | | | | representing an ISO 3166-1 | | | | alpha-2 country code. | +-------------+-------------+-----------------------------+ Table 1 Services MAY validate that country is an assigned ISO 3166-1 alpha-2 code under local policy. The wire-shape requirement is two uppercase ASCII letters. 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: Kavian Expires 24 January 2027 [Page 5] Internet-Draft AEP Claims July 2026 { "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: +=============+========================================+ | Field | Description | +=============+========================================+ | Claim Name | Dotted lowercase Claim Name. | +-------------+----------------------------------------+ | Value Type | JSON value type or named object shape. | +-------------+----------------------------------------+ | Description | Short claim description. | +-------------+----------------------------------------+ | Reference | Stable specification reference. | +-------------+----------------------------------------+ Table 2 The registry contains the following entries: Kavian Expires 24 January 2027 [Page 6] Internet-Draft AEP Claims July 2026 +=========================+========+==================+===========+ | Claim Name | Value | Description | Reference | | | Type | | | +=========================+========+==================+===========+ | contact.address.primary | object | Primary postal | This | | | | address. | document | +-------------------------+--------+------------------+-----------+ | contact.email | string | Email address. | This | | | | | document | +-------------------------+--------+------------------+-----------+ | contact.mobile | string | Mobile telephone | This | | | | number. | document | +-------------------------+--------+------------------+-----------+ | person.birthdate | string | Full-calendar | This | | | | birth date. | document | +-------------------------+--------+------------------+-----------+ | person.first_name | string | Given name. | This | | | | | document | +-------------------------+--------+------------------+-----------+ | person.last_name | string | Family name. | This | | | | | document | +-------------------------+--------+------------------+-----------+ | person.username | string | Username. | This | | | | | document | +-------------------------+--------+------------------+-----------+ Table 3 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. Kavian Expires 24 January 2027 [Page 7] Internet-Draft AEP Claims July 2026 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 12.1. Normative References [AEP-CORE] Kavian, N., "The Agent Enrollment Protocol", Work in Progress, Internet-Draft, draft-kavian-agent-enrollment- protocol-02, 23 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Kavian Expires 24 January 2027 [Page 8] Internet-Draft AEP Claims July 2026 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . 12.2. Informative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Author's Address N. Kavian Jarwin, Inc. (InFlow) Email: nas@inflowpay.ai Kavian Expires 24 January 2027 [Page 9]