Internet-Draft KYAPay Profile January 2026
Agarwal Expires 25 July 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-skyfire-kyapayprofile-latest
Published:
Intended Status:
Informational
Expires:
Author:
A. Agarwal
Skyfire

KYAPay Profile

Abstract

This document defines a profile for agent identity and payment tokens in JSON web token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to consume identity and payment tokens in an interoperable manner.

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/kyapay-ietf-draft/draft-skyfire-kyapayprofile.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-skyfire-kyapayprofile/.

Source for this draft and an issue tracker can be found at https://github.com/skyfire-xyz/kyapay-ietf-draft.

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 25 July 2026.

▲

Table of Contents

1. Introduction

As software agents evolve from pre-orchestrated workflow automations to truly autonomous or semi-autonomous assistants, they require the ability to identify themselves -- and more importantly, identify their human principals -- to external systems. Agents acting on behalf of users to discover services, create accounts, or execute actions currently face significant operational barriers.

The KYAPay token addresses these challenges by providing a standard envelope to carry verified identity and payment information. By utilizing "kya" (Agent Identity) and "pay" (Payment) tokens, agents can identify their human principals to services, sites, bot managers, customer identity and access management (CIAM) systems, and fraud detectors. This enables agents to bypass common blocking mechanisms and access services that were previously restricted to manual human interaction.

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.

The terms iss, iat, exp, jti, aud, typ are defined in [RFC7519].

The alg value ES256 is a digital signature algorithm described in Section 3.4 of [RFC7518].

2.1. Roles

Agent:

An application, service, or specific software process, executing on behalf of a Principal.

Agent Identity:

A unique identifier and a set of claims describing an agent. Grouped into the aid claim for convenience. Because an agent can be public or confidential (as described in Section 2.1 of [RFC6749]), the level of assurance for these claims varies dramatically. Agents also vary in terms of longevity -- they can have stable long-running identities (such as those of a server-side confidential client), or they can be transient and ephemeral, and correspond to individual API calls or compute workloads.

Agent Platform:

The service provider and runtime environment hosting the Agent, such as a cloud compute provider or AI operator service. Assertions about the agent platform are grouped into the apd claim, and are primarily used to identify the Principal entity operating the platform, allowing consumers of the token to apply reputation-based logic or offer platform-specific services.

Principal:

A legal entity (human or organization) on whose behalf / in whose authority an agent or service is operating.

2.1.1. Buy-Side Roles

Buyer Agent:

An Agent performing tasks on behalf of a Buyer Principal, that has its own Agent Identity.

Buyer Agent Platform:

The Agent Platform hosting the Buyer Agent. Some use cases require the Platform to have its own verified identity assertions, grouped into the apd claim.

Buyer Identity:

The aggregate verified identity assertions of the buy-side entities, typically encompassing the Buyer Principal, the Buyer Agent Platform, and the Buyer Agent itself. This composite identity is conveyed via the KYA token, allowing the seller to verify the entire chain of responsibility behind a request. Grouped into the bid claim.

Buyer Principal:

A legal entity (human or organization) behind the purchase / consumption of a product or service. The Principal typically interacts with the seller via a Buyer Agent. Many sellers are required to be able to determine the Buyer Identity in order to comply with KYC/AML regulations, accounting standards, and to maintain a direct customer relationships.

2.1.2. Sell-Side Roles

Seller Agent:

An Agent performing tasks on behalf of a Seller Principal, directly interacting with Buyer Agents to facilitate discovery and purchase. Typically runs on Internet-connected infrastructure, and discoverable via service directories.

Seller Agent Platform:

The Agent Platform that hosts Seller Agents.

Seller Identity:

The aggregate verified identity assertions of the sell-side entities, typically encompassing the Seller Principal, the Seller Agent Platform, as well as the Seller Agent Identity. These various aspects of Seller Identity allow Buyers and Buyer Agents to perform reputation-based logic, to verify that they are interacting with the authorized (and expected) counter-party, and to fulfill KYC/AML regulation requirements.

Seller Principal:

A legal entity (human or organization) that owns the product, service, or content being sold, and serves as the ultimate beneficiary of a business transaction.

2.1.3. Ecosystem Infrastructure Roles

Identity Token Issuer:

A trusted neutral entity that conducts Know Your Customer (KYC) and Know Your Business (KYB) verifications. It is responsible for issuing cryptographically signed kya tokens that attest to the identity of the Principal, Agent, and Agent Platform, for both Buyers and Sellers.

Payment Token Issuer:

A trusted entity responsible for facilitating the exchange of payments and credentials between the Buyer and Seller. It issues signed pay tokens that enable settlement via various schemes (Cards, Banks, Cryptocurrency), without exposing raw credentials or secrets.

3. KYAPay Token Schemas

3.1. Common Token Claims

The following are claims in common, used within the KYA (Know Your Agent), PAY (Payment), and KYA+PAY (combined Know Your Agent and Payment) Tokens.

iss:

REQUIRED - Url of the token's issuer. Used for discovering JWK Sets for token signature verification, via the /.well-known/jwks.json suffix mechanism.

sub:

REQUIRED - Subject Identifier. Must be pairwise unique within a given issuer.

aud:

REQUIRED - Audience (used for audience binding and replay attack mitigation), uniquely identifying the seller agent. A single string value.

iat:

REQUIRED - as defined in Section 4.1.6 of [RFC7519].

jti:

REQUIRED - Unique ID of this JWT as defined in Section 4.1.7 of [RFC7519].

exp:

REQUIRED - as defined in Section 4.1.4 of [RFC7519].

env:

OPTIONAL - Issuer environment (such as "sandbox" or "production").

ver:

OPTIONAL - Version of the token schema.

ssi:

OPTIONAL - Seller Service ID that this token was created for.

btg:

OPTIONAL - Buyer tag, an opaque reference ID internal to the buyer.

3.2. KYA Token

The following identity related claims are used within KYA and KYA+PAY tokens:

bid:

OPTIONAL (Required for buyer identity use cases) - A map of buyer identity claims.

apd:

OPTIONAL - Agent Platform identity claims.

aid:

OPTIONAL - Agent identity claims.

rid:

OPTIONAL - Referrer identity claims.

The following informative example displays a decoded KYA type token.

{
  "kid": "<JWK Key ID>",
  "alg": "ES256",
  "typ": "kya+JWT"
}.{
  "iss": "<URL of the token issuer>",
  "iat": 1742245254,
  "exp": 1773867654,
  "jti": "b9821893-7699-4d24-af06-803a6a16476b",
  "sub": "<Buyer Agent Account ID>",
  "aud": "<Seller Agent Account ID>",

  "env": "<Issuer environment (sandbox, production, etc)>",
  "ver": "1",
  "ssi": "<Seller Service ID>",
  "btg": "<Buyer Tag (Buyer's internal reference ID)>",

  "bid": {
    "email": "buyer@buyer.com”
  },
  "apd": {
  },
  "aid": {
  },
  "rid": {
  }
}
Figure 1: A KYA type token

3.2.1. bid - Buyer Identity Sub-claims

The Buyer Identity (bid) claim contains sub-claims useful for buyer use cases, as follows.

email:

REQUIRED - Buyer email.

3.2.1.1. OPTIONAL Human Principal Sub-claims
nameFirst:

First name of buyer human principal.

nameMiddle:

Middle name of buyer human principal.

nameLast:

Last name of buyer human principal.

phoneNumber:

Phone number associated with principal.

addressStreet1:

First line of address.

addressStreet2:

Second line of address.

addressCity:

City.

addressSubdivision:

Subdivision.

addressPostalCode:

Postal Code.

addressCountryCode:

ISO country code.

birthdate:

Human principal birth date.

3.2.1.2. OPTIONAL Organizational or Business Entity Principal Sub-claims
businessName:

Name of principal entity.

businessTaxIdentificationNumber:

Relevant Tax Identification Number of principal entity.

businessPhysicalAddressFull:

Full physical address of principal entity.

businessPhysicalAddressStreet1:

First line of physical address of principal entity.

businessPhysicalAddressStreet2:

Second line of physical address of principal entity.

businessPhysicalAddressCity:

City component of physical address.

businessPhysicalAddressSubdivision:

Subdivision component of physical address.

businessPhysicalAddressPostalCode:

Postal code component of physical address.

businessPhysicalAddressCountryCode:

ISO country code component of physical address.

businessRegisteredAddressStreet1:

First line of registered address of principal entity.

businessRegisteredAddressStreet2:

Second line of registered address of principal entity.

businessRegisteredAddressCity:

City component of registered address of principal entity.

businessRegisteredAddressSubdivision:

Subdivision component of registered address of principal entity.

businessRegisteredAddressPostalCode:

Postal code component of registered address of principal entity.

businessRegisteredAddressCountryCode:

ISO country code of registered address of principal entity.

3.2.2. Agent Platform Identity aid Sub-claims

The aid claim itself is optional. If present, it may contain the following sub-claims.

id:

REQUIRED - Agent Platform identifier.

name:

REQUIRED - Agent Platform name.

nameFirst:

First name of agent platform human principal.

nameMiddle:

Middle name of agent platform human principal.

nameLast:

Last name of agent platform human principal.

phoneNumber:

Phone number associated with agent platform.

businessName:

Business name associated with agent platform.

3.3. PAY Token

The following payment related claims are used within PAY and KYA+PAY type tokens:

spr:

OPTIONAL - Seller service price.

sps:

OPTIONAL - Seller service pricing model (for example, PAY_PER_USE).

amount:

OPTIONAL - Token amount in currency units.

cur:

OPTIONAL - Currency unit, as defined in ...

value:

OPTIONAL - Token amount in settlement network

mnr:

OPTIONAL - Maximum number of requests when sps is PAY_PER_USE

stp:

OPTIONAL - Settlement type (one of COIN, CARD, or BANK).

sti:

OPTIONAL - Meta information for payment settlement, depending on settlement type.

The following informative example displays a decoded PAY type token.

{
  "kid": "<JWK Key ID>",
  "alg": "ES256",
  "typ": "pay+JWT"
}.{
  "iss": "<URL of the token issuer>",
  "iat": 1742245254,
  "exp": 1773867654,
  "jti": "b9821893-7699-4d24-af06-803a6a16476b",
  "sub": "<Buyer Agent Account ID>",
  "aud": "<Seller Agent Account ID>",

  "env": "<Issuer environment (sandbox, production, etc)>",
  "ver": "1",
  "ssi": "<Seller Service ID>",
  "btg": "<Buyer Tag (Buyer's internal reference ID)>",

  "spr": "0.010000",
  "sps": "PAY_PER_USE",
  "amount": "15.000000",
  "cur": "USD",
  "value": "15000000",
  "mnr": "1500",
  "stp": "<COIN | CARD | BANK>",
  "sti": {
    "type": "<'type' is dependant on 'sti' for COIN - USDC | x402; for CARD - VISA_VIC;>",
    "dynamicDataExpiration": "<Timestamp when DTVV expires>",
    "dynamicDataId": "<Visa specific identifier>",
    "dynamicDataType": "DAVV",
    "dynamicDataValue": "<DAVV value>",
    "paymentToken": "<16 Digit Virtual Payment Card Number>",
    "tokenExpirationMonth": "<Expiration Month Number>",
    "tokenExpirationYear": "<Expiration Year>"
  }
}
Figure 2: A PAY type token

3.4. KYA+PAY Token

The following informative example displays a decoded KYA+PAY type token.

{
  "kid": "<JWK Key ID>",
  "alg": "ES256",
  "typ": "kya+pay+JWT"
}.{
  "iss": "<URL of the token issuer>",
  "iat": 1742245254,
  "exp": 1773867654,
  "jti": "b9821893-7699-4d24-af06-803a6a16476b",
  "sub": "<Buyer Agent Account ID>",
  "aud": "<Seller Agent Account ID>",

  "env": "<Issuer environment (sandbox, production, etc)>",
  "ver": "1",
  "ssi": "<Seller Service ID>",
  "btg": "<Buyer Tag (Buyer's internal reference ID)>",

  "bid": {
    "email": "buyer@buyer.com”,
    ...
  },
  "apd": {
  },
  "aid": {
  },

  "spr": "0.010000",
  "sps": "PAY_PER_USE",
  "amount": "15.000000",
  "cur": "USD",
  "value": "15000000",
  "mnr": "1500",
  "stp": "<COIN | CARD | BANK>",
  "sti": {
    "type": "<'type' is dependant on 'sti'>",
    "dynamicDataExpiration": "<Timestamp when DTVV expires>",
    "dynamicDataId": "<Visa specific identifier>",
    "dynamicDataType": "DAVV",
    "dynamicDataValue": "<DAVV value>",
    "paymentToken": "<16 Digit Virtual Payment Card Number>",
    "tokenExpirationMonth": "<Expiration Month Number>",
    "tokenExpirationYear": "<Expiration Year>"
  }
}
Figure 3: A KYA+PAY type token

4. Token Validation

4.1. Validating KYA and PAY Tokens

4.1.1. JWT Header Validation

  1. alg - JWTs MUST be signed using allowed JWA algorithms (currently, ES256).

  2. kid - The kid claim MUST be present, and set to a valid key id discoverable via the issuer's (payload iss claim) JWK Set.

  3. typ - The typ claim MUST be one of: kya+JWT, pay+JWT, or kya+pay+JWT

4.1.2. JWT Payload Validation

  1. Verify JWT Signature - Valid JWTs MUST be signed with a valid key belonging To the token's issuer (iss claim)

  2. Validate iss Claim - Ensure that the token is signed by the expected valid issuer.

  3. Validate the exp Claim - The verifier MUST validate that the token has not expired, within the verifier's clock drift tolerance.

  4. Validate the iat Claim - The verifier MUST validate that the token was issued in the past, within the verifier's clock drift tolerance.

  5. Validate the jti Claim - Ensure that the jti claim is present, and is a UUID.

  6. Validate the aud Claim - ...

  7. Validate the env Claim - Ensure that the Environment claim is set to an expected and usecase-appropriate value (such as production, sandbox, etc)

4.2. Validating PAY Tokens

For tokens of type pay+JWT or kya+pay+JWT, perform the steps described in the Validating KYA and PAY Tokens section.

In addition, perform the following steps.

  1. The value claim is greater than 0.

  2. The amount claim is greater than 0.

  3. The cur claim is set to a currency the seller supports (such as USD)

  4. The sps claim, if present, matches the pricing scheme that you configured in the seller's service

  5. The spr claim, if present, matches the price that you configured in the seller's service

5. Security Considerations

When validating the JWTs described in this specification, implementers SHOULD follow the best practices and guidelines laid out in [RFC8725].

6. IANA Considerations

This document has no IANA actions.

7. References

7.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7518]
Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, , <https://www.rfc-editor.org/rfc/rfc7518>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

7.2. Informative References

[RFC8725]
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, , <https://www.rfc-editor.org/rfc/rfc8725>.

Contributors

Dmitri Zagidulin

Author's Address

Ankit Agarwal
Skyfire