Using KYAPay Tokens
draft-skyfire-oauth-using-kyapay-tokens-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ankit Agarwal , Michael B. Jones , Srinivasa | ||
| Last updated | 2026-07-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-skyfire-oauth-using-kyapay-tokens-00
Web Authorization Protocol A. Agarwal
Internet-Draft Skyfire Systems Inc.
Intended status: Standards Track M. B. Jones
Expires: 20 January 2027 Self-Issued Consulting
S. Thumma
Akamai
19 July 2026
Using KYAPay Tokens
draft-skyfire-oauth-using-kyapay-tokens-00
Abstract
The KYAPay Token is a JSON Web Token (JWT) that carries verified
identity ("Know Your Agent", KYA) and payment (PAY) information for
requests made by software agents on behalf of human principals. This
document describes how security intermediaries -- bot managers, fraud
managers, account-takeover (ATO) protection systems, and customer
identity and access management (CIAM) systems -- consume KYAPay
tokens to answer a question that traditional bot detection cannot:
"did a verified human authorize this agent?", rather than "is this a
human?". It specifies how KYAPay tokens are carried in HTTP
requests, how they are validated (including in combination with
request-signing layers such as HTTP Message Signatures), and how the
verified, layered identity in a token is used to make access,
routing, fraud detection, account-lifecycle, and step-up decisions.
It defines the token-consuming "verifier" role that the KYAPay Token
leaves unspecified. It is intentionally non-prescriptive about how
tokens are created, because agent architectures, agent-identity
technologies, and agent-communication protocols are diverse and still
emerging; the token itself is the interoperability contract.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://skyfire-
xyz.github.io/draft-skyfire-oauth-using-kyapay-tokens/draft-skyfire-
oauth-using-kyapay-tokens.html. Status information for this document
may be found at https://datatracker.ietf.org/doc/draft-skyfire-oauth-
using-kyapay-tokens/.
Discussion of this document takes place on the Web Authorization
Protocol Working Group mailing list (mailto:oauth@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/oauth/.
Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.
Agarwal, et al. Expires 20 January 2027 [Page 1]
Internet-Draft Using KYAPay Tokens July 2026
Source for this draft and an issue tracker can be found at
https://github.com/skyfire-xyz/draft-skyfire-oauth-using-kyapay-
tokens.
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 20 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Relationship to Other Documents . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Human Identity is Paramount . . . . . . . . . . . . . . . 7
3.2. Ubiquity of Access on the Existing Web . . . . . . . . . 7
3.3. Works with Today's Web at Zero Merchant Tech Lift . . . . 8
3.4. One Source of Truth Across All Layers of Defense . . . . 8
3.5. Runtime Business Decisions . . . . . . . . . . . . . . . 8
Agarwal, et al. Expires 20 January 2027 [Page 2]
Internet-Draft Using KYAPay Tokens July 2026
4. The Trust Stack: Bearer Tokens Today, Proof of Possession
Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. KYA is an Issuer-Signed Bearer Token Today . . . . . . . 9
4.2. Identity and Proof of Possession are Different Layers . . 9
4.3. The Proof-of-Possession Path (Planned Evolution) . . . . 10
5. Conveying KYAPay Tokens in Requests . . . . . . . . . . . . . 11
5.1. The KYAPay-Token HTTP Header Field . . . . . . . . . . . 11
5.2. Conveying Tokens over Other Interfaces . . . . . . . . . 12
5.3. Authenticating the Counterparty . . . . . . . . . . . . . 13
6. Using KYAPay Tokens at Security Intermediaries . . . . . . . 13
6.1. Common Processing Model . . . . . . . . . . . . . . . . . 13
6.2. Determining Human Presence and Assurance . . . . . . . . 14
6.3. Bot Managers . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Fraud Managers . . . . . . . . . . . . . . . . . . . . . 16
6.5. Step-Up Authentication . . . . . . . . . . . . . . . . . 17
6.6. Account-Takeover Protectors . . . . . . . . . . . . . . . 17
6.7. CIAM Systems . . . . . . . . . . . . . . . . . . . . . . 18
6.8. Consistency Across Layers . . . . . . . . . . . . . . . . 19
6.9. Granular Bad-Actor Mitigation and Triage . . . . . . . . 19
6.10. Feedback to the Token Issuer . . . . . . . . . . . . . . 19
6.11. Non-Payment and Handoff Flows . . . . . . . . . . . . . 20
7. Token Creation Considerations . . . . . . . . . . . . . . . . 21
7.1. Why this Document is Not Prescriptive about Creation . . 21
7.2. Guidance for KYAPay Token Issuers . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.1. Transport Confidentiality . . . . . . . . . . . . . . . . 23
8.2. Token Freshness and Lifetime . . . . . . . . . . . . . . 23
8.3. Replay and Proof of Possession . . . . . . . . . . . . . 24
8.4. Malicious or Compromised Target Reuse . . . . . . . . . . 24
8.5. Compromised Agent Host (Irreducible) . . . . . . . . . . 24
8.6. Issuer Trust . . . . . . . . . . . . . . . . . . . . . . 24
8.7. Revocation . . . . . . . . . . . . . . . . . . . . . . . 25
8.8. Continuity of Human Control . . . . . . . . . . . . . . . 25
8.9. Key Management . . . . . . . . . . . . . . . . . . . . . 25
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Minimal Disclosure . . . . . . . . . . . . . . . . . . . 25
9.2. Consent . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.3. Handling by Intermediaries . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. HTTP Field Name Registration . . . . . . . . . . . . . . 26
10.2. JWT and Media Type Registrations . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Document History . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
Agarwal, et al. Expires 20 January 2027 [Page 3]
Internet-Draft Using KYAPay Tokens July 2026
1. Introduction
For most of the history of the web, the operative question asked by
web security infrastructure was binary: is this request from a human
or from a bot? Bots were treated as unwelcome, and bot managers, web
application firewalls, and related systems were built to detect and
block automated traffic. As automation became more nuanced, the
question evolved into a three-way distinction: human, "good bot"
(such as a search-engine crawler or a monitoring probe), and "bad
bot".
The rise of capable AI agents changes the question again. The
relevant distinction is now:
* a *human* interacting directly;
* a *human acting through an agent* (a "human-via-agent" request),
where a person or organization has authorized a software agent to
act on their behalf; and
* a *bot*: unattended automation acting without the authorization
of, or on behalf of, an identified human principal.
Put succinctly, the distinction that matters is no longer human
versus good bot versus bad bot; it is human-direct and human-via-
agent, together, versus bots. And the sharper form of the question
is "did a verified human authorize this agent?", rather than "is this
a human?". An AI agent is neither a bot to be managed nor a human to
be onboarded through a conventional flow; it is a new category of
legitimate client that existing bot and fraud detection cannot, on
its own, distinguish from malicious automation.
Bots were unwelcome, and they remain unwelcome. The new requirement
is that both human requests and human-via-agent requests must be able
to succeed across the existing web security infrastructure. A human-
via-agent request is, at the transport and application layers,
frequently indistinguishable from a bot; it is programmatic, it may
originate from data-center IP space, and it may not carry a
conventional interactive browser fingerprint. Absent a reliable
signal, security intermediaries either block legitimate agents
(destroying utility for the human principal) or relax their defenses
(admitting malicious bots). What has been missing is a consistent,
verifiable signal of human authorization behind an otherwise
programmatic request.
KYAPay tokens [I-D.skyfire-oauth-kyapay-token] supply that signal. A
KYAPay token is a signed JWT [RFC7519] [RFC7515] that conveys
verified identity claims about the human principal, the agent, and
Agarwal, et al. Expires 20 January 2027 [Page 4]
Internet-Draft Using KYAPay Tokens July 2026
the agent platform (the KYA, or "Know Your Agent", information), and
optionally payment credentials (the PAY information). A validated
KYA token asserts that a trusted issuer has verified that this human
principal (to some level of assurance) authorized this agent (running
on this platform) to act on their behalf; a validated PAY token
further asserts that a trusted issuer has authorized this agent to
pay a specific amount to a specific target. Together, they form a
chain of trust from the human principal to the action, and -- for
payments -- to settlement.
1.1. Scope
This document describes how _consumers_ of KYAPay tokens -- in
particular the security intermediaries that guard websites, APIs, and
accounts -- convey, validate, and act on KYAPay tokens. It does not
redefine the token; the claims, their meanings, and the base
validation rules are specified in the KYAPay Token
[I-D.skyfire-oauth-kyapay-token] and are referenced normatively here.
This document is deliberately *normative about consumption* and *non-
prescriptive about creation*. Section 6 places requirements on how
intermediaries validate and use tokens. Section 7 discusses token
creation as a software-architecture problem and intentionally does
not mandate a mechanism; the rationale is given in Section 7.1.
1.2. Relationship to Other Documents
This document builds directly on the KYAPay Token
[I-D.skyfire-oauth-kyapay-token], which defines the KYA, PAY, and
KYA-PAY token types, the claim schema (including the layered identity
claims hid, apd, and aid), and the core token validation procedure.
The specification defines the token and the roles of issuer,
initiator, and target, but it does not define the role of the party
that receives and validates a token in order to make a security
decision. This document defines that role -- the _verifier_ (or
relying party) -- and specifies its behavior.
Three related specifications define JWT claims and values that a
verifier can use to reason about how a principal was authenticated
and verified, and that MAY appear in KYAPay tokens: the Additional
Authentication Method Reference Values specification
[I-D.skyfire-oauth-amr-values], which defines additional amr
[RFC8176] claim values, the Identity Verification Methods Values
specification [I-D.skyfire-oauth-id-verification], which defines the
ivm claim and values, and the Anti-Money Laundering Methods Values
specification [I-D.skyfire-oauth-aml-methods], which defines the aml
claim and values.
Agarwal, et al. Expires 20 January 2027 [Page 5]
Internet-Draft Using KYAPay Tokens July 2026
2. Conventions and Definitions
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.
2.1. Terminology
This specification uses the Initiator/Target and agent identity terms
Initiator Agent, Initiator Principal, Agent Platform, and the
identity grouping claims hid, apd, and aid defined by
[I-D.skyfire-oauth-kyapay-token].
This document defines the following terms:
*Human-via-agent request*: An HTTP request or protocol message
issued by an agent that carries a valid KYAPay token attesting
that the agent is acting on behalf of an identified, authorizing
human principal (an individual or an organization).
*Bot*: Unattended automation that is not acting on behalf of, or
with the authorization of, an identified human principal, and that
does not present a valid KYAPay token. This document does not
attempt to further classify bots; existing "good bot" / "bad bot"
mechanisms are orthogonal and continue to apply.
*Verifier (Relying Party)*: The entity that receives a KYAPay token,
validates it, and acts on the result. A verifier may be a
security intermediary (below), a Target's own resource server, or
an edge/CDN provider acting on a Target's behalf.
*Security intermediary*: A verifier, typically operated by a
security vendor or by the Target, that inspects requests and makes
an admission, routing, scoring, or lifecycle decision before or as
the request reaches the Target's application. This document
addresses four common (and often overlapping) kinds of security
intermediary:
*Bot manager*: A system operating primarily at the network and
transport layer that decides whether to admit, challenge,
throttle, or block a request based on whether it appears to be
automated.
*Fraud manager*: An application-layer system that scores the risk
of a transaction or action, typically using identity,
reputation, behavioral, and device signals.
Agarwal, et al. Expires 20 January 2027 [Page 6]
Internet-Draft Using KYAPay Tokens July 2026
*Account-takeover (ATO) protector*: A system that detects and
prevents unauthorized access to existing accounts, for example
by distinguishing legitimate sessions from hijacked or
automated ones.
*CIAM (customer identity and access management) system*: A system
that manages account creation, authentication, and login for a
Target's customers.
*Human presence signal*: The aggregate assurance, derived from a
validated KYAPay token, that a request is authorized by an
identified human principal. See Section 6.2.
*Assurance level*: A per-entity indication of how strongly an
identity in the token was verified (for example, the identity-
proofing level of the human principal). See Section 6.2.
3. Design Principles
This section is informative. It records the assumptions that
motivate the normative requirements in later sections.
3.1. Human Identity is Paramount
An underlying hypothesis of KYAPay is that commerce -- with or
without payment -- is conducted between humans and human
organizations, not between machines. An agent is a tool through
which a human or organization acts. Consequently, the identity that
matters most is the human identity behind the request, and liability
for a request must ultimately be assignable to a human party: the
principal, the developer of the agent, the operator of the agent
platform, or some other identified party. KYAPay tokens are
structured to convey these identities so that this auditable,
cryptographically verifiable chain of responsibility -- from agent
action back to an accountable human -- can be established.
3.2. Ubiquity of Access on the Existing Web
Agents are useful in proportion to the breadth of the web they can
act across. If a human must pre-configure access for an agent at
each site before the agent can act, the result is indistinguishable
from the workflow automation that already exists, and the principal
loses the probabilistic discovery -- of new merchants, products,
services, and alternatives -- that is one of the main reasons to use
an agent at all. The goal is therefore agentic access to the
existing web, not a parallel, agent-only surface that must be set up
in advance. This goal can only be met if security intermediaries
admit legitimate human-via-agent requests by default when a valid
Agarwal, et al. Expires 20 January 2027 [Page 7]
Internet-Draft Using KYAPay Tokens July 2026
token is present.
3.3. Works with Today's Web at Zero Merchant Tech Lift
Websites exist today, in the millions, and merchants and services
already know how to sell through them, manage fraud, make offers,
build brand loyalty, and test changes. A key property of a website
(and, similarly, of a merchant-controlled MCP [MCP] server) is that
the merchant controls its own interface and is not locked into an API
schema that must be carefully versioned; agents driven by large
language models (LLMs) can frequently learn to use these interfaces
automatically. A protocol for delivering agent identity and payment
credentials should therefore work with today's web without requiring
merchants to build new APIs. KYAPay meets this by conveying
credentials in the HTTP request itself (Section 5), which requires no
change to how a merchant's site is built.
3.4. One Source of Truth Across All Layers of Defense
Bot managers operate at the transport/network layer; fraud managers,
ATO protectors, and CIAM systems operate at the application layer.
Today, each makes its decision in isolation, and their verdicts on
the same request can contradict one another. A single validated
KYAPay token gives every layer the same verified identity and, where
present, payment context, so that their decisions are more likely to
be consistent than conflicting.
3.5. Runtime Business Decisions
A further goal is to give the Target the information it needs to make
a business decision at request time: do I want to do business with
this human, arriving via this agent, on this platform, for this
action? Because the token carries verified, layered identity and
(optionally) payment context, the Target and its intermediaries can
decide at runtime whether to admit, price, personalize, step up, or
decline. As one illustration, a merchant that recognizes a KYAPay-
bearing request MAY adapt its existing pages for agent consumption
using the same techniques it already uses to restyle pages, retaining
ownership of its interface and its existing fraud and good/bad-actor
signals rather than exposing a separate API surface.
4. The Trust Stack: Bearer Tokens Today, Proof of Possession Ahead
This section is informative. It situates KYAPay tokens among the
other mechanisms a verifier encounters and, importantly,
distinguishes what is deployed today from the planned evolution, so
that the consumption requirements in Section 6 are read against the
correct baseline.
Agarwal, et al. Expires 20 January 2027 [Page 8]
Internet-Draft Using KYAPay Tokens July 2026
4.1. KYA is an Issuer-Signed Bearer Token Today
As currently deployed, a KYA (or KYA-PAY) token is an issuer-signed,
short-lived bearer token. Its single most valuable operational
property is that a Target has to do almost nothing to consume it:
verify a JWT against the issuer's public key via JWKS, exactly as it
would verify any OpenID Connect [OpenID.Core] or OAuth [RFC6749]
token. Any Target with a standard JWT library can participate,
including those behind CDNs, API gateways, and serverless platforms.
Preserving that low bar is a primary design goal (Section 3);
mechanisms that would raise it are weighed against the adoption they
would cost.
A bearer token establishes identity but not proof of possession:
possession of the token is all that is needed to present it, so a
token captured within its validity window can be replayed. Today
this residual, in-window risk is bounded rather than eliminated, by
means that do not raise the consumption bar:
* short token lifetimes (exp), so a captured token expires quickly;
* audience binding (aud, and where used tdm/tsi), so a token minted
for one Target cannot be presented to another;
* TLS on every hop, which mitigates on-the-wire capture and man-in-
the-middle; and
* issuer-gated onboarding (KYC/KYB), which mitigates malicious
agents and Targets being admitted to the network in the first
place.
The accepted residual threats, and the irreducible ones, are stated
in Section 8.
4.2. Identity and Proof of Possession are Different Layers
It is useful to separate two questions a verifier may want answered:
* _Who is behind this request?_ This is answered by the KYA token: a
trusted, neutral issuer that performs KYC/KYB attests to the
identity of the human principal (hid), agent platform (apd), and
agent (aid), acting as a client-side trust anchor analogous to a
Certificate Authority. KYA is a set of verifiable _nouns_ --
identity, verification status, authorization, payment -- and,
being a JWT, it is transport-agnostic: the same token rides HTTP,
WebSockets, gRPC metadata, a message queue, or a stdio MCP
channel, and can be logged and independently re-verified at rest.
Agarwal, et al. Expires 20 January 2027 [Page 9]
Internet-Draft Using KYAPay Tokens July 2026
* _Did the sender actually hold the credential's key?_ This is proof
of possession, which a bearer token does not provide.
Establishing it requires the agent to sign the request itself;
over HTTP, HTTP Message Signatures [RFC9421] are a mechanism for
this. A signature proves control of a key but says nothing about
whose key it is -- it is a _verb_, not an identity format.
Because these are different layers, HTTP Message Signatures [RFC9421]
and similar request-signing mechanisms are complementary to KYA, not
alternatives to it; request signing supplies authenticity and
possession, while KYA supplies identity, authorization, and payment.
A complete proof-of-possession design uses both, bound together, as
described next.
4.3. The Proof-of-Possession Path (Planned Evolution)
When per-request signing becomes practical at scale, the planned
evolution of KYA is a Certificate-Authority-like model that adds
proof of possession without changing the trust anchor:
1. the issuer onboards the agent as a CA would;
2. the agent generates a key pair and provides its public key to the
issuer;
3. the issuer binds that public key into the KYA token using the JWT
confirmation claim cnf (cnf.jkt or cnf.jwk) [RFC7800]; and
4. the agent signs each request in place -- a signature over the
request (method, path, body digest, timestamp/nonce) using
[RFC9421] -- verified against the key in cnf, with no separate
proof-of-possession token.
This yields an unbroken chain from request to key to identity: the
request is signed by a key, and that key is vouched for as the
initiator's by the issuer. Preferring a request signed against the
cnf key over a detached, DPoP-style proof [RFC9449] keeps a single
token -- the verifier validates the KYA token once (per session),
caches the cnf key, then performs only a fast per-request signature
check, instead of validating two artifacts and confirming they are
bound to each other. When present, this binding is consumed as
specified in Section 6.1 and closes the in-window replay and
malicious-Target-reuse risks of the bearer model (Section 8).
Adoption remains the constraint on when this becomes mandatory. Per-
request signing is costly: hardware-protected keys are secure but
slow, software keys are fast but exfiltratable, and post-quantum
algorithms do not make signing faster. Defeating replay of the proof
Agarwal, et al. Expires 20 January 2027 [Page 10]
Internet-Draft Using KYAPay Tokens July 2026
itself further requires either per-Target nonce caches or binding the
signature to the request content, and other request-bound designs
considered (mutual TLS [RFC8705], TLS channel binding, session-based
schemes) each raise the participation bar or add Target-side state.
Until fast, secure signing and a workable anti-replay approach exist
that keep the Target's job about as simple as verifying a JWT, KYA
remains a bearer token by default and proof of possession is an
optional, forward-compatible upgrade rather than a precondition for
participation.
5. Conveying KYAPay Tokens in Requests
5.1. The KYAPay-Token HTTP Header Field
When KYAPay tokens are used with websites and HTTP APIs, a human-via-
agent request carries its token(s) in an HTTP header field, in the
same spirit that a human's browser conveys identity and payment
details in the request itself. For a directly interacting human,
such details are typically carried in the request body (for example,
form fields at checkout); for a human-via-agent request, they are
carried in the KYAPay-Token header field defined here.
The KYAPay-Token header field is an HTTP request header field whose
value is a KYA, PAY, or KYA-PAY token, as defined in
[I-D.skyfire-oauth-kyapay-token]. HTTP field names are case-
insensitive [RFC9110].
KYAPay-Token = token-jwt *( OWS "," OWS token-jwt )
token-jwt = 1*( ALPHA / DIGIT / "-" / "_" / "." )
A request MAY convey more than one token (for example, separate KYA
and PAY tokens) either as a comma-separated list in a single KYAPay-
Token header field or as multiple KYAPay-Token header fields; per
Section 5.2 of [RFC9110], multiple field lines with the same name are
equivalent to a single comma-separated field line. Because a JWT
uses only the base64url alphabet plus the period (".") separator, it
never contains a comma, so list parsing is unambiguous.
A sender:
* MUST place exactly one JWT in each list member;
* SHOULD NOT send more than one token of the same typ
([I-D.skyfire-oauth-kyapay-token]) in a single request; and
* MUST NOT rely on the ordering of tokens within the field to convey
meaning.
Agarwal, et al. Expires 20 January 2027 [Page 11]
Internet-Draft Using KYAPay Tokens July 2026
A recipient:
* MUST determine the type of each token from its typ header
parameter ([I-D.skyfire-oauth-kyapay-token]), not from its
position; and
* MUST ignore a KYAPay-Token member it cannot parse as a JWT, while
continuing to process the remaining members, unless local policy
requires rejecting the whole request.
Intermediaries and caches MUST treat KYAPay-Token as containing
sensitive, request-specific credentials; it MUST NOT be cached in a
way that would allow it to be replayed on a different request, and it
MUST NOT be logged or forwarded to parties other than legitimate
participants (see Section 9).
The KYAPay-Token header field is intended for use over TLS. A token
MUST NOT be sent over a non-TLS-protected connection. When the token
carries a proof-of-possession key (Section 4), it SHOULD be
accompanied by a request Message Signature [RFC9421] over that key;
otherwise it is a bearer token, subject to the controls and accepted
risks in Section 8.
5.2. Conveying Tokens over Other Interfaces
Beyond HTTP requests to websites and APIs, agents interact through a
growing set of interfaces and protocols, including agent-to-tool
interactions such as MCP [MCP], agent-to-agent interactions such as
A2A [A2A], agent-to-API interactions (for example, OpenAPI
descriptions converted into locally callable tools), and emerging
protocols such as Universal Commerce Protocol [UCP] and Verifiable
Intent [VINTENT]. KYAPay is designed so that the same self-contained
token can be conveyed across any of these interfaces -- as an HTTP
header field, a message field, or a tool argument -- to deliver
verified identity and payment credentials to the receiving service,
API, or agent. Because a KYA token is a self-contained JWT, it is
transport-agnostic in a way that a request-signing mechanism is not:
HTTP Message Signatures [RFC9421] are meaningful only for HTTP
exchanges, whereas the same token can ride HTTP, WebSockets, gRPC
metadata, message queues, or a stdio MCP channel, and can also sit at
rest in a store or audit log for later verification. This document
specifies only the HTTP header binding in Section 5.1; bindings for
other protocols are expected to be defined by those protocols or by
companion specifications. In all cases, the validation and usage
rules of Section 6 apply to the token, once received.
Agarwal, et al. Expires 20 January 2027 [Page 12]
Internet-Draft Using KYAPay Tokens July 2026
5.3. Authenticating the Counterparty
Conveying a token securely also requires that the sending agent
deliver it to the intended recipient and that the recipient be able
to bind the token to itself. The aud claim, together with the
optional tdm (target domain) and tsi (target service identifier)
claims defined in [I-D.skyfire-oauth-kyapay-token], allows a
recipient to confirm that a token was minted for it and to mitigate
replay to a different party (Section 8). At the transport and
discovery layers, mechanisms such as DNS domain names (with TLS
server authentication), A2A agent cards [A2A], and MCP server
identification [MCP] help an agent confirm that it is communicating
with the correct counterparty before presenting a token.
6. Using KYAPay Tokens at Security Intermediaries
This section is normative. It defines a common processing model and
then describes how each kind of security intermediary uses the
validated token. Throughout, "validate the token" means to perform
the validation procedure defined in [I-D.skyfire-oauth-kyapay-token],
Section 4 (JWT header validation, signature and issuer validation,
and validation of exp, iat, jti, aud, and env), plus the PAY-specific
validation for pay+jwt and kya-pay+jwt tokens.
6.1. Common Processing Model
On receiving a request that carries one or more KYAPay tokens, a
security intermediary:
1. MUST extract each token as described in Section 5.
2. MUST validate each token as specified in
[I-D.skyfire-oauth-kyapay-token], Section 4. A token that fails
validation MUST NOT be treated as conveying a human presence
signal, and the intermediary MUST fall back to its default
(token-absent) policy for that request.
3. MUST verify the token signature against a key obtained from the
issuer's JWK Set, discovered via the iss claim using the /.well-
known/jwks.json mechanism ([I-D.skyfire-oauth-kyapay-token]).
Because KYAPay tokens are self-contained, this verification
SHOULD be performed locally, without a synchronous callout to the
issuer per request; issuer keys SHOULD be cached and refreshed
according to standard JWK Set practice.
4. MUST confirm that the token's issuer is one the verifier trusts
for the claims being relied upon (see Section 8).
Agarwal, et al. Expires 20 January 2027 [Page 13]
Internet-Draft Using KYAPay Tokens July 2026
5. MUST confirm that the token is intended for this recipient by
checking the aud claim (and, if used, the tdm and tsi claims) as
described in Section 8.
6. MUST confirm that the env claim (for example, production) matches
the environment the intermediary is operating in. When the token
carries a proof-of-possession key (the cnf claim [RFC7800],
Section 4), MUST verify that the request is signed by that key --
over HTTP, using HTTP Message Signatures [RFC9421] -- and reject
the request if the signature is absent or invalid.
7. When the token carries no such key, it is a bearer token: the
intermediary MUST rely on the controls in Section 8 (short
lifetime, audience binding, TLS, issuer-gated onboarding) and
MUST NOT assume that mere presentation of the token proves the
sender holds a key bound to it.
8. SHOULD use the token's claims to inform its decision, as
described in the following subsections, only after successful
validation.
A security intermediary MUST NOT treat the mere presence of a KYAPay-
Token header field as a human presence signal; only a successfully
validated token from a trusted issuer conveys that signal.
6.2. Determining Human Presence and Assurance
The core purpose of consuming a KYAPay token is to distinguish a
human-via-agent request from a bot, and to gauge how strongly to
trust it. After validation, a verifier SHOULD derive the human
presence signal from the layered identity in the token, treating each
layer as a distinct entity verified by distinct means:
* the human principal (hid): the presence and content of the human
identity claim, and how strongly it was verified -- for example a
verified status and verifier ([I-D.skyfire-oauth-kyapay-token]),
and, where a deployment conveys it, an identity-proofing assurance
level (such as an Identity Assurance Level per [NIST-800-63A]) and
the amr [I-D.skyfire-oauth-amr-values], ivm
[I-D.skyfire-oauth-id-verification], and aml
[I-D.skyfire-oauth-aml-methods] claims describing how the
principal was authenticated and verified;
* the agent platform (apd): the identity of the operator that built
and runs the agent, and whether it was verified (for example, a
business/Know-Your-Business attestation), which supports
reputation-based logic about the platform; and
Agarwal, et al. Expires 20 January 2027 [Page 14]
Internet-Draft Using KYAPay Tokens July 2026
* the agent instance (aid): the specific agent, including a
meaningful name and, where present, references to its OAuth
identity ([I-D.ietf-oauth-client-id-metadata-document]) and a
proof-of-possession key bound to the token via cnf [RFC7800] (or a
request-signing key published in an A2A Agent Card [A2A]).
Because these are different entities verified to different degrees, a
verifier SHOULD NOT collapse them into a single yes/no signal.
Instead, it SHOULD apply per-entity, per-action policy. For example,
a verifier might require a higher human-principal assurance level and
a "registered" agent for a payment than for browsing:
/checkout: require hid assurance >= document+biometric
require apd verified as a business
require aid bound to a verified domain
/payment: require hid assurance >= document+biometric
require hid authenticated with a hardware key
require aid registered by its platform
The strength of the human presence signal is a function of which
identities are present, how strongly each was verified, and how much
the verifier trusts the attesting issuer and verifier. A verifier
MAY combine the token signal with its existing signals rather than
replacing them, and MAY accept a lower assurance for low-risk actions
while requiring step-up (Section 6.5) for higher-risk ones.
6.3. Bot Managers
A bot manager operates at the transport/network layer and is chiefly
concerned with admitting or blocking a request with minimal added
latency. KYAPay tokens are well suited to this role:
* *Low Latency.* Because the token is a self-contained, signed JWT,
the bot manager performs standard JWT verification and needs no
per-request callout to a third party. Issuer keys SHOULD be
cached.
* *Access Control by Identity.* A validated token gives the bot
manager verified initiator identity (and, when the request targets
an agent, target identity), which it MAY use to admit the request
rather than challenging or blocking it as suspected automation.
Agarwal, et al. Expires 20 January 2027 [Page 15]
Internet-Draft Using KYAPay Tokens July 2026
* *Replay Resistance.* A bearer token captured within its validity
window can be replayed; a bot manager bounds this with short
lifetimes, audience binding, and TLS (Section 8). Where a token
carries a proof-of-possession key (Section 4), the bot manager (or
the edge/CDN provider acting for the Target) SHOULD additionally
verify the per-request signature [RFC9421] against that key, which
removes the in-window replay exposure.
* *Routing.* Target identity claims MAY be used for routing
decisions.
Network-origin claims (for example, an agent's declared source IP
ranges) MAY be used as a weak corroborating signal only. They are
unreliable as proof of origin -- addresses change and can be masked
by VPNs, CGNAT, or shared pools -- and a verifier MUST NOT treat an
IP match alone as sufficient to bypass other controls, nor treat an
IP mismatch as conclusive. Short lifetimes and audience binding
today, and proof-of-possession where available (Section 4), not IP
correlation, are the recommended controls against token misuse.
A bot manager that completes the checks above SHOULD admit the
request (subject to rate and abuse limits) rather than subjecting it
to bot-blocking challenges designed for unattended automation.
6.4. Fraud Managers
A fraud manager operates at the application layer and scores the risk
of an action or transaction. It benefits from the token's layered
identity and verification metadata:
* It SHOULD incorporate the per-entity verified identity (hid, apd,
aid) and assurance levels into its risk model, distinguishing a
request backed by a strongly verified human principal on a
reputable platform from a weakly verified or anonymous one.
* It SHOULD use the verifier/verified/verification_id sub-claims,
and the amr [I-D.skyfire-oauth-amr-values] ivm
[I-D.skyfire-oauth-id-verification], and aml
[I-D.skyfire-oauth-aml-methods] claims where present, to weight
how the principal was authenticated and verified.
* For pay+jwt and kya-pay+jwt tokens, it SHOULD use the payment
context (amt, cur, stp, sti, and the pricing claims tpr and tps)
as additional transaction risk signals, after performing the PAY-
token validation of [I-D.skyfire-oauth-kyapay-token], Section 4.
Because the PAY token pins amount, currency, and target, the fraud
manager MAY rely on those as hard limits enforced by the token
rather than re-deriving them.
Agarwal, et al. Expires 20 January 2027 [Page 16]
Internet-Draft Using KYAPay Tokens July 2026
A fraud manager need not sit inline in the request path. In practice
the token is made available to it either inline (the Target forwards
the received token to its fraud manager) or out of band (for example,
script running on the Target's page captures the KYAPay-Token value
and sends it to the fraud manager before the request reaches the
Target's application). The same token MAY be inspected before the
action, after it, or both. In all of these arrangements, the token
issuer is not in the transaction path; the fraud manager verifies the
self-contained token locally by JWKS, as described in Section 6.1.
The fraud manager MAY continue to apply its existing behavioral and
device models; the token supplements, and does not replace, those
signals.
6.5. Step-Up Authentication
Not all actions carry the same risk; viewing a loyalty balance is far
less sensitive than making a large payment. A KYAPay token attests
the assurance established at the time of issuance, which may be
insufficient for a high-value action. A verifier SHOULD be able to
require a higher assurance level for sensitive actions and to signal
that requirement so that a fresh token can be obtained after
additional verification of the human principal (for example, a step-
up authentication such as a push-notification approval, a one-time
code, or a re-run of identity verification).
This document does not define a wire mechanism for a Target to
request step-up out of band from an issuer; that is an open item (see
Section 8). Until such a mechanism is standardized, verifiers SHOULD
express assurance requirements as local policy over the assurance
signals in Section 6.2 and decline actions whose required assurance
is not met.
6.6. Account-Takeover Protectors
An ATO protector distinguishes legitimate account sessions from
hijacked or unauthorized ones. KYAPay tokens let it separate three
cases that previously looked alike: a direct human-present session, a
human-initiated agentic session, and an unauthorized automated
session.
* It SHOULD treat a validated KYAPay token, bound to its request per
Section 4, as evidence that a session is a human-initiated agentic
session rather than an unattended attack, and SHOULD record that
distinction for auditing.
* When the agent needs to act within an existing account, the token
MAY be exchanged for an OAuth access token using KYAPay Token
Exchange [I-D.skyfire-oauth-kyapay-token-exchange] or OAuth 2.0
Agarwal, et al. Expires 20 January 2027 [Page 17]
Internet-Draft Using KYAPay Tokens July 2026
Token Exchange [RFC8693]. A Security Token Service, Identity
Provider, or OAuth 2.0 [RFC6749] Authorization Server validates
the KYA token, extracts principal claims such as the email address
from hid, and issues an access token that the agent uses against
the Target.
* The access token resulting from such an exchange SHOULD be sender-
constrained (for example, via DPoP [RFC9449] or mutual TLS
[RFC8705]) rather than issued as a freely transferable bearer
token, so that exchanging the KYA token does not simply
reintroduce a replayable credential.
* Cross-domain trust must be established: the Target's authorization
server can fetch the issuer's keys via the iss JWKS endpoint, but
it must also decide whether to trust that issuer and how to
interpret its claims (see Section 8).
* A valid token attests authorization at the moment of issuance, not
continuous human control. An ATO protector SHOULD NOT assume that
the human remains in control for the token's whole lifetime,
SHOULD prefer short token lifetimes, and SHOULD apply step-up
(Section 6.5) for sensitive actions.
6.7. CIAM Systems
A CIAM system manages account creation and login for a Target's
customers. With KYAPay tokens it can manage agents consistently with
humans:
* It MAY create an account for an agent (or for the human principal
behind an agent) directly from a validated KYA or KYA-PAY token,
drawing account attributes such as the email address from the hid
claim.
* It SHOULD use KYAPay Token Exchange
[I-D.skyfire-oauth-kyapay-token-exchange] or OAuth 2.0 Token
Exchange [RFC8693] to exchange a KYA token for an access token,
enabling logged-in experiences (loyalty, saved preferences,
offers) for human-via-agent sessions, applying the sender-
constraining and cross-domain-trust considerations of Section 6.6.
* It SHOULD maintain the linkage between a human principal and the
agents authorized to act for them, so that a principal can be
given visibility into, and control over, agent activity and vice
versa.
Agarwal, et al. Expires 20 January 2027 [Page 18]
Internet-Draft Using KYAPay Tokens July 2026
6.8. Consistency Across Layers
Because all of the intermediaries above validate the _same_ token and
draw on the _same_ verified claims, an operator SHOULD configure them
to reach consistent verdicts on a given request: a request admitted
as a verified human-via-agent request by the bot manager should not
be scored as an anonymous bot by the fraud manager.
6.9. Granular Bad-Actor Mitigation and Triage
The layered identity in a KYA token (hid for the principal, apd for
the platform, aid for the agent instance) lets intermediaries choose
the scope of a mitigation deliberately, rather than being forced into
a single broad, "nuclear" block. Because every request carries all
three identities, a verifier can select the narrowest scope that is
effective and escalate only as warranted:
* the individual *human principal* (hid) -- e.g., block or throttle
one abusive user while all other users of the same agent continue
to be served;
* the specific *agent instance* (aid) -- e.g., isolate one
compromised or malfunctioning agent without affecting the
principal's other agents or the rest of the platform; or
* the entire *agent platform* (apd) -- e.g., when an operator is
systematically abusive, unresponsive, or untrusted, block or de-
rate all traffic from that platform.
The same granularity supports responses short of blocking the
requests, such as throttling, requiring step-up (Section 6.5), or
lowering an assurance score, applied at whichever tier is
appropriate. Choosing the tightest effective scope isolates threats
while protecting the reputation of well-behaved platforms and
avoiding collateral damage to legitimate human-via-agent requests;
reserving platform-wide action for cases that genuinely warrant it
keeps that option available without making it the default.
6.10. Feedback to the Token Issuer
The mitigation described above is local: a verifier acts on its own
traffic. Because the token issuer is the party that vouches for the
initiator and can decline to vouch again, there is value in a
feedback loop that lets a security intermediary report observed bad
behavior back to the issuer, so that action can be taken at the
source rather than only at each verifier independently. When a
security intermediary observes abusive or anomalous behavior that it
can attribute, using the layered identity in the token, to a
Agarwal, et al. Expires 20 January 2027 [Page 19]
Internet-Draft Using KYAPay Tokens July 2026
particular entity, it MAY report that observation to the token's
issuer (identified by iss). The attribution follows the same tiers
as Section 6.9:
* the individual human principal (hid);
* the specific agent instance (aid); or
* the agent platform as a whole (apd).
On receiving such feedback, and subject to its own verification and
anti-abuse safeguards, the issuer MAY take appropriate action, up to
and including ceasing to issue tokens to the implicated initiator,
agent, or platform -- the issuance-side counterpart to a verifier's
refusal to accept a token, and complementary to the token-lifetime
and revocation considerations of Section 8. This mirrors the
Certificate-Authority analogy of Section 8: just as a CA can stop
issuing (and can revoke) certificates for a misbehaving subscriber, a
KYAPay issuer can stop vouching for a misbehaving initiator.
This document does not define the mechanism, format, or trust model
for this feedback channel; how a verifier authenticates to an issuer,
how reports are structured, how issuers guard against false or
malicious reports, and what evidence is required are all open items.
Feedback SHOULD be treated as sensitive: reports identify principals,
agents, or platforms and MUST be shared only with the relevant issuer
and handled per Section 9. An issuer SHOULD corroborate feedback
(for example, requiring reputation, multiple independent reports, or
evidence) before taking action that would affect a principal, so that
the channel cannot itself be used to deny service to legitimate
initiators.
6.11. Non-Payment and Handoff Flows
Not every human-via-agent flow includes a payment made by the agent.
In a common pattern, the agent performs discovery and assembles a
cart but does not pay; it then hands off to the human, who completes
checkout in a browser, in a later session, or even in a physical
store. In such flows, the KYA token (carried without a PAY token)
still provides the human presence signal that lets a security
intermediary admit the agent's discovery and cart-building activity.
Intermediaries SHOULD accept KYA-only requests (those conveying a KYA
token but no PAY token) for actions that do not themselves settle a
payment, and MUST NOT treat the absence of a PAY token as a reason to
classify an otherwise valid human-via-agent request as a bot.
Agarwal, et al. Expires 20 January 2027 [Page 20]
Internet-Draft Using KYAPay Tokens July 2026
Because the human identity claim hid (for example, an email address)
is stable across these touchpoints, a Target or fraud manager MAY
link the agent's earlier work to the human's eventual purchase -- for
attribution, personalization, and fraud analysis -- even when the
purchase completes outside the agent session or on a different
channel.
7. Token Creation Considerations
This section is non-normative with respect to _how_ tokens are
created. It records considerations that KYAPay Token Issuers and
agent developers should weigh, but it deliberately does not mandate a
mechanism. The normative interoperability contract is the token
defined by [I-D.skyfire-oauth-kyapay-token] and consumed as specified
in Section 6; how a given agent obtains a valid token is an
implementation and architecture choice.
7.1. Why this Document is Not Prescriptive about Creation
Readers accustomed to fixed API contracts may expect a specification
to prescribe exactly how a credential is minted. For agents, such
prescription is neither possible nor desirable at this time, for
several reasons:
* *Agent architectures are diverse.* Agents are built in
fundamentally different ways -- computer-use agents that drive a
desktop, browser-use agents that drive a browser, and programmatic
agents that call APIs or tools -- and there is no single formula
for building one. An agent may be an individual's personal, ad
hoc creation, or a highly governed and deterministic enterprise
agent for a regulated workflow, or anything in between.
* *Credentials may need to be shielded from the LLM.* In many
designs, it is desirable that the LLM driving an agent never sees
raw credentials. Token creation may therefore be placed inside
deterministic tools that the LLM can invoke but whose outputs (the
tokens, or the secrets used to mint them) it cannot read. Whether
this matters depends on the deployment; a specification that
mandated a single creation flow could not accommodate both
shielded and unshielded designs.
Agarwal, et al. Expires 20 January 2027 [Page 21]
Internet-Draft Using KYAPay Tokens July 2026
* *Agent-identity and communication protocols are still emerging.*
Multiple protocols for agent identity and for agent communication
-- agent-to-tool (MCP [MCP]), agent-to-agent (A2A [A2A]), request
signing ([RFC9421]), OAuth client identity
([I-D.ietf-oauth-client-id-metadata-document]), agent-to-API,
Verifiable Intent [VINTENT], UCP [UCP], and others -- are under
active development and require significant investment to reach
production. Standardizing a single creation mechanism now would
bind KYAPay to choices that are not yet settled.
* *The web already exists.* In contrast to those emerging
interfaces, websites and merchant-controlled endpoints exist today
at scale and require no new integration effort from merchants
(Section 3). A usable protocol must therefore work now, over the
existing web, which argues for standardizing the delivered token
rather than the creation path.
KYAPay's position is that the token is the fixed point, and creation
is allowed to vary. This is what lets a single token type serve
individual and enterprise agents, shielded and unshielded designs,
and today's web alongside tomorrow's agent protocols.
7.2. Guidance for KYAPay Token Issuers
Given the above, KYAPay Token Issuers are encouraged to make token
creation possible and easy regardless of the technology an agent
uses:
* *Match the issuing interface to the agent.* A programmatic agent
using a deterministic tool may be well served by a single REST
endpoint with optional arguments -- one call that can mint a KYA,
PAY, or KYA-PAY token with any supported settlement type (payment
cards, stablecoins, and so on). An agent driven through MCP [MCP]
may instead be better served by several narrow, specific tools
(one per token type and per settlement type), so as to reduce the
decision burden placed on the LLM.
* *Support multiple identity technologies.* Because there is no
single agent-identity standard today, issuers should be prepared
to accept and bind a variety of identity inputs when minting
tokens, including (for example) CIMD
[I-D.ietf-oauth-client-id-metadata-document], WIMSE / SPIFFE
[SPIFFE], Agent Name Service (ANS), request-signing keys published
in A2A Agent Cards [A2A], and public/private key pairs.
Agarwal, et al. Expires 20 January 2027 [Page 22]
Internet-Draft Using KYAPay Tokens July 2026
* *Be available across agent technologies and protocols.* Issuers
should be reachable by agents irrespective of the agent's runtime
technology, the identity protocol it uses, and the communication
protocol it speaks.
Origination and issuance need not be performed by the same party.
The iss claim identifies the party that signs (issues) the token,
while the optional ori claim ([I-D.skyfire-oauth-kyapay-token])
identifies the party that originated -- that is, assembled and
requested -- it; these can be the same entity or different entities.
Likewise, the verified identity information carried in hid and apd
may be supplied by the agent platform or a third-party verifier and
merely attested by the issuer. Verification itself need not be
completed up front: it can be progressive, beginning with a
lightweight check (such as email verification) and stepping up as a
Target's requirements demand. Consumers observe the result of these
choices through the verified/verifier sub-claims and, where used, the
ivm [I-D.skyfire-oauth-id-verification], amr
[I-D.skyfire-oauth-amr-values], and aml
[I-D.skyfire-oauth-aml-methods] claims, rather than through any
mandated creation flow.
The objective of all of the above is a single outcome: a valid KYAPay
JWT that is consumable by every transacting party -- the Initiator,
the Target, and the bot managers, fraud managers, ATO protectors, and
CIAM systems in between.
8. Security Considerations
When validating the JWTs described here and in
[I-D.skyfire-oauth-kyapay-token], implementers MUST follow the JSON
Web Token Best Current Practices [RFC8725], in addition to the
validation steps of [I-D.skyfire-oauth-kyapay-token], Section 4.
8.1. Transport Confidentiality
KYAPay tokens convey identity and, for PAY tokens, payment
credentials. They MUST be transmitted over TLS and MUST NOT be sent
in the clear.
8.2. Token Freshness and Lifetime
A long-lived token is a credential that can be captured, farmed, and
resold for reuse against the same Target. The exp claim MUST be
present; verifiers SHOULD require short lifetimes (for high-assurance
actions, on the order of a few minutes) and MUST reject tokens whose
lifetime exceeds their local policy maximum. Verifiers SHOULD reject
tokens whose iat is outside an acceptable window.
Agarwal, et al. Expires 20 January 2027 [Page 23]
Internet-Draft Using KYAPay Tokens July 2026
8.3. Replay and Proof of Possession
A bare bearer token can be replayed by anyone who captures it within
its validity window. As deployed today (Section 4), KYAPay accepts
this bounded in-window risk and mitigates rather than eliminates it:
verifiers MUST validate the aud claim (and tdm/tsi where used) so
that a token minted for one Target cannot be presented to another,
MUST keep accepted lifetimes short, and SHOULD use the jti claim to
detect replay to the same recipient. Where a token carries a proof-
of-possession key (cnf [RFC7800]), verifiers MUST additionally verify
a per-request signature [RFC9421] over that key (Section 6.1), which
removes the in-window replay exposure. Access tokens produced by
token exchange (Section 6.6) SHOULD be sender-constrained ([RFC9449],
[RFC8705]).
8.4. Malicious or Compromised Target Reuse
A Target that legitimately receives a bearer token can, within the
token's window, reuse it to act elsewhere on the agent's behalf.
Audience binding limits this to the intended Target; the proof-of-
possession model (Section 4), which binds each use to a fresh request
signature, closes it. Verifiers and Targets MUST NOT forward
received tokens to other parties (see Section 9).
8.5. Compromised Agent Host (Irreducible)
Malware resident on the agent's host can drive the agent's legitimate
key as a signing oracle for as long as it is present. Proof of
possession does not prevent this: the malware's requests convey valid
bindings and are indistinguishable from the real agent's. This risk
is bounded not by the token bindings but by short token lifetimes --
so anything signed during a compromise expires quickly once the
malware is evicted -- together with host-level controls such as
attestation, anomaly detection, and hygiene.
8.6. Issuer Trust
A token is only as trustworthy as its issuer and the verifiers it
cites. The system is federated: many issuers are possible, and a
verifier MUST maintain an explicit set of trusted issuers and the
claims and assurance levels it will accept from each. Establishing
this trust at scale is an open problem analogous to the Certificate
Authority model (audits, a maintained issuer list, a removal
mechanism, and possibly transparency logs); this document does not
define such a framework, and deployments should not assume one
exists. Until it does, trust is established out of band (for
example, configured relationships with well-known issuers).
Agarwal, et al. Expires 20 January 2027 [Page 24]
Internet-Draft Using KYAPay Tokens July 2026
8.7. Revocation
An agent whose platform is deregistered, or a human whose identity
verification is revoked, may still hold unexpired tokens. This
specification does not define a revocation mechanism. Verifiers
SHOULD keep accepted lifetimes short to bound exposure, and SHOULD
consult an issuer's live-status or revocation endpoint, where one is
offered, for high-assurance or high-value actions.
8.8. Continuity of Human Control
A valid token attests that the human principal authorized the agent
at the time of issuance. It does not prove the human remains in
control -- for example, if the agent is later prompt-injected, or if
credentials are exfiltrated from the agent or its host. Verifiers
SHOULD treat high-value actions as warranting step-up (Section 6.5)
rather than relying solely on a previously issued token.
8.9. Key Management
If an issuer or platform rotates a signing key, tokens signed with
the old key may fail validation prematurely. Issuers SHOULD retain
superseded verification keys in their JWK Set for at least the
maximum token lifetime after rotation.
9. Privacy Considerations
The privacy considerations of [I-D.skyfire-oauth-kyapay-token] apply.
In particular:
9.1. Minimal Disclosure
Only the information needed to facilitate the intended interaction
should be placed in a token and conveyed to intermediaries and
Targets. Issuers and senders SHOULD prefer the least revealing set
of claims sufficient for the decision at hand -- for example, an
assurance level or a boolean verified status rather than underlying
identity documents or personally identifying verification data.
Because KYA tokens are JWTs, selective disclosure (for example, SD-
JWT [RFC9901]) is a forward-compatible path to revealing only the
claims a given Target needs.
9.2. Consent
Tokens assert that an agent acts on behalf of a principal. That
assertion is only legitimate when the principal has authorized the
interaction. Systems SHOULD be designed so that tokens are minted
only with the principal's authorization.
Agarwal, et al. Expires 20 January 2027 [Page 25]
Internet-Draft Using KYAPay Tokens July 2026
9.3. Handling by Intermediaries
Security intermediaries receive verified personal data in the course
of making decisions. They MUST treat KYAPay-Token values and their
decoded contents as sensitive personal data: not caching them for
replay, not logging them in the clear, and not sharing them with
parties other than legitimate participants in the interaction.
10. IANA Considerations
10.1. HTTP Field Name Registration
IANA is requested to register the following entry in the "Hypertext
Transfer Protocol (HTTP) Field Name" registry established by
[RFC9110]:
* Field Name: KYAPay-Token
* Status: permanent
* Structured Type: List
* Reference: Section 5.1 of this document
* Comments: Carries one or more KYAPay tokens in an HTTP request
10.2. JWT and Media Type Registrations
This document defines no new JWT claims, JWT confirmation methods, or
media types. The claims and media types used by KYAPay tokens are
registered by [I-D.skyfire-oauth-kyapay-token]. The amr extensions
and the ivm and aml claims and values are registered by
[I-D.skyfire-oauth-amr-values], [I-D.skyfire-oauth-id-verification],
and [I-D.skyfire-oauth-aml-methods], respectively.
11. References
11.1. Normative References
[I-D.skyfire-oauth-kyapay-token]
Agarwal, A. and M. B. Jones, "KYAPay Token", Work in
Progress, Internet-Draft, draft-skyfire-oauth-kyapay-
token-00, 5 July 2026,
<https://datatracker.ietf.org/doc/html/draft-skyfire-
oauth-kyapay-token-00>.
Agarwal, et al. Expires 20 January 2027 [Page 26]
Internet-Draft Using KYAPay Tokens July 2026
[I-D.skyfire-oauth-kyapay-token-exchange]
Agarwal, A., Jones, M. B., Hingnikar, A., and J. Hickman,
"KYAPay Token Exchange", Work in Progress, Internet-Draft,
draft-skyfire-oauth-kyapay-token-exchange-01, 19 July
2026, <https://datatracker.ietf.org/doc/html/draft-
skyfire-oauth-kyapay-token-exchange-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/rfc/rfc7800>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
11.2. Informative References
[A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification",
2025, <https://a2a-protocol.org/latest/specification>.
Agarwal, et al. Expires 20 January 2027 [Page 27]
Internet-Draft Using KYAPay Tokens July 2026
[I-D.ietf-oauth-client-id-metadata-document]
Parecki, A. and E. Smith, "OAuth Client ID Metadata
Document", Work in Progress, Internet-Draft, draft-ietf-
oauth-client-id-metadata-document-02, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
client-id-metadata-document-02>.
[I-D.skyfire-oauth-aml-methods]
Agarwal, A., Jones, M. B., and N. Ali, "Anti-Money
Laundering Methods Values", Work in Progress, Internet-
Draft, draft-skyfire-oauth-aml-methods-00, 18 July 2026,
<https://datatracker.ietf.org/doc/html/draft-skyfire-
oauth-aml-methods-00>.
[I-D.skyfire-oauth-amr-values]
Agarwal, A., Jones, M. B., Ali, N., and Srinivasa,
"Additional Authentication Method Reference Values", Work
in Progress, Internet-Draft, draft-skyfire-oauth-amr-
values-01, 19 July 2026,
<https://datatracker.ietf.org/doc/html/draft-skyfire-
oauth-amr-values-01>.
[I-D.skyfire-oauth-id-verification]
Agarwal, A., Jones, M. B., Ali, N., and Srinivasa,
"Identity Verification Methods Values", Work in Progress,
Internet-Draft, draft-skyfire-oauth-id-verification-01, 19
July 2026, <https://datatracker.ietf.org/doc/html/draft-
skyfire-oauth-id-verification-01>.
[KYAPAY-ORG]
Skyfire Systems Inc., "KYAPay: Verified Agent Identity and
Payments", <https://kyapay.org/>.
[MCP] Anthropic and the Model Context Protocol Contributors,
"Model Context Protocol Specification", November 2025,
<https://modelcontextprotocol.io/
specification/2025-11-25>.
[NIST-800-63A]
National Institute of Standards and Technology, "Digital
Identity Guidelines: Identity Proofing and Enrollment
(NIST SP 800-63A)",
<https://pages.nist.gov/800-63-3/sp800-63a.html>.
Agarwal, et al. Expires 20 January 2027 [Page 28]
Internet-Draft Using KYAPay Tokens July 2026
[OpenID.Core]
Sakimura, N., Bradley, J., Jones, M. B., Medeiros, B. de.,
and C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", 15 December 2023,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC8176] Jones, M., Hunt, P., and A. Nadalin, "Authentication
Method Reference Values", RFC 8176, DOI 10.17487/RFC8176,
June 2017, <https://www.rfc-editor.org/rfc/rfc8176>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/rfc/rfc8705>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/rfc/rfc8725>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
[RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JSON Web Tokens", RFC 9901,
DOI 10.17487/RFC9901, November 2025,
<https://www.rfc-editor.org/rfc/rfc9901>.
[SPIFFE] SPIFFE Project / Cloud Native Computing Foundation,
"Secure Production Identity Framework for Everyone
(SPIFFE)",
<https://spiffe.io/docs/latest/spiffe-about/overview/>.
[UCP] UCP Contributors, "Universal Commerce Protocol (UCP)
Specification", 2025,
<https://ucp.dev/latest/specification/overview/>.
[VINTENT] Verifiable Intent Contributors, "Verifiable Intent
Specification", 2025,
<https://verifiableintent.dev/spec/>.
Agarwal, et al. Expires 20 January 2027 [Page 29]
Internet-Draft Using KYAPay Tokens July 2026
Acknowledgments
The authors thank the contributors to the KYAPay Token
[I-D.skyfire-oauth-kyapay-token] specification and the partners in
the KYAPay consortium (see [KYAPAY-ORG]) -- including bot-management,
fraud, CIAM, and ATO vendors and merchants -- whose deployment and
review experience informed the usage patterns and open issues
described here.
Document History
[[ to be removed by the RFC Editor before publication as an RFC ]]
-00
* Initial draft.
Authors' Addresses
Ankit Agarwal
Skyfire Systems Inc.
Email: ankit_agarwal@yahoo.com
URI: https://skyfire.xyz
Michael B. Jones
Self-Issued Consulting
Email: michael_b_jones@hotmail.com
URI: https://self-issued.info/
Srinivasa Thumma
Akamai
Email: sthumma@akamai.com
Agarwal, et al. Expires 20 January 2027 [Page 30]