KYA and KYAPay: Reading the Identity and Payment Claims an Agent Presents

A retailer receives an automated request to buy an item. Knowing which agent platform sent it is useful, but the retailer may also need to know which customer is represented and whether suitable payment authority accompanies the request. These are different claims, with different verification requirements.

KYA and KYAPay aim to make that information portable. A merchant still has to decide which claims it trusts and what action they permit.

Research boundary: official project material and the October 2026 Internet-Drafts reviewed November 1, 2026. This article is desk research, not a merchant onboarding, token-validation test or payment demonstration. The cited drafts are work in progress, not IETF endorsement or a finalized standard.

Distinguish the protocol from its providers

The project’s about page describes KYA as a way to identify agents, their represented users and intent, with KYAPay adding payment credentials. Its standardization page links related work on token formats, consuming tokens and token exchange.

Skyfire is associated with the protocol’s development and example implementations. The project repository separates core token material and example APIs, while describing further specification work. Evaluating a Skyfire service therefore remains a separate product exercise: accounts, commercial terms, supported settlement and operational availability must be checked for that service, not inferred from the protocol name.

Three token roles should stay visible

The current token draft distinguishes identity, payment and combined tokens using kya+jwt, pay+jwt and kya-pay+jwt. Recipients validate the issuer and signature, token type, intended audience and time-related claims; payment tokens require additional payment checks.

Conceptual claim-consumption flow, not a tested merchant integration. Issuing or validating a token is not the same event as completing a payment.

For the retailer, an identity-only token cannot be treated as payment authorization merely because it names a customer. Conversely, a payment credential does not necessarily contain every identity attribute the merchant needs. Build the acceptance policy around the actual token role and required evidence.

A valid JWT is only part of validation

In an integration review, ask which issuers the retailer accepts and how that decision is maintained. A mathematically valid signature from an unfamiliar issuer is not automatically evidence the retailer has chosen to rely on.

Then check the connection to this request: intended audience, environment, service, user account and amount where applicable. A sandbox credential should not become a production purchase because both use the same parser. Missing optional claims should remain missing; do not fill them with guesses and label them verified.

The token-consumption draft defines an HTTP header path and discusses proof-of-possession binding alongside bearer-token use. An integration must know which mode it enforces. Merely attaching a token does not establish that the current requester holds a separate bound signing key.

Signed does not mean encrypted

The token draft explicitly distinguishes integrity protection from confidentiality: signed JWT claims are readable by whoever obtains the token. Its handling rules call for protected transport and restricted disclosure, and prohibit putting primary card account numbers (PANs) or static card-verification values into the defined settlement field.

For product teams, make this a data-flow review rather than a sentence in a privacy policy. Identify every edge service, origin, log collector and support tool that could receive the token. Store a safe correlation reference where possible, not a complete credential in an analytics event. Provide enough failure context for debugging without copying customer identity and payment material into an LLM conversation.

The consumption draft likewise treats the header as sensitive, request-specific credential material. If an intermediary verifies it, define what verified result is forwarded and prevent an untrusted client from impersonating that result at the origin.

Review expiration and uncertain payment separately

A practical acceptance plan should include an expired token, the wrong audience, an untrusted issuer, an unsupported token type and a valid identity token without sufficient payment authority. Add a replay scenario under the exact bearer or proof-of-possession mode being used.

For a timeout after payment submission, preserve the attempt identifier and inspect the payment result. Obtaining a fresh token should not automatically cause a second charge. Likewise, expiration of a credential does not itself reverse an already completed payment.

These are proposed tests and operational rules, not verified behavior of a particular KYAPay provider. Version-pin both the token profile and recipient implementation before writing fixtures; older launch examples should not silently override the later draft’s field definitions.

Where KYA/KYAPay fits

KYA/KYAPay is relevant when an agent-mediated request needs portable claims about a represented principal and possibly payment. It is adjacent to Web Bot Auth, which authenticates signed HTTP requests, but the evidence carried and the decisions made are different.

Our view is to adopt only the claims a specific transaction needs, with clear issuer trust and a separate payment-result ledger. Start from the KYA/KYAPay directory reference and keep protocol conformance distinct from provider onboarding.