KYAPay Token

2.1.1. Initiator Roles

Initiator Agent:

An Agent performing tasks on behalf of an Initiator Principal, that has its own Agent Identity, grouped into the aid claim.¶

Initiator Agent Platform:

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

Initiator Principal:

A legal entity (human or organization) behind the purchase / consumption of a product or service. In buyer/seller transactions, the Initiator is the buyer. The Principal typically interacts with the target via an Initiator Agent. Many targets are required to be able to determine the Initiator Identity in order to comply with KYC/AML regulations, accounting standards, and to maintain a direct customer relationships. The initiator principal's identity is grouped into the hid claim.¶

Initiator Identity:

The aggregate verified identity assertions of the initiator entities, typically encompassing the Initiator Principal, the Initiator Agent Platform, and the Initiator Agent itself. This composite identity is conveyed via the KYA token, allowing the target to verify the entire chain of responsibility behind a request. The initiator identity utilizes the hid, apd, and aid claims.¶

2.1.2. Target Roles

Target Agent:

An Agent performing tasks on behalf of a Target Principal, directly interacting with Initiator Agents to facilitate discovery and purchase. Typically runs on Internet-connected infrastructure, and discoverable via service directories. Target agent identity claims are also grouped into the aid claim if KYA tokens are generated for the targets.¶

Target Agent Platform:

The Agent Platform that hosts Target Agents. Some use cases require the Platform to have its own verified identity assertions, grouped into the apd claim.¶

Target Principal:

A human principal (individual or organization) that owns the product, service, API, website, or content being consumed or sold, and serves as the ultimate beneficiary of a transaction. In buyer/seller transactions, the Target is the seller. The target principal's identity is grouped into the hid claim.¶

Target Identity:

The aggregate verified identity assertions of the target entities, typically encompassing the Target Principal, the Target Agent Platform, as well as the Target Agent Identity. These various aspects of Target Identity allow Initiators and Initiator 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. The target identity utilizes the hid, apd, and aid claims.¶

2.1.3. Ecosystem Infrastructure Roles

KYA Token Issuer:

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

Payment Token Issuer:

A trusted entity responsible for facilitating the exchange of payments and credentials between the Initiator and Target. It issues signed pay tokens that enable settlement via various schemes (Cards, Banks, Cryptocurrency), without exposing raw credentials or secrets. Like a KYA Token Issuer, it conducts Know Your Customer (KYC) and Know Your Business (KYB) verifications of the Initiator. KYAPay does not provide for anonymous payment, so a Payment Token Issuer does not issue a pay token for an Initiator it has not verified.¶

Verifier:

The party used by the KYA Token Issuer to verify the identity of the human, organization, or agent or the party used by the Payment Token Issuer to verify the payment method.¶

3.1.1. Identifying the Target

Three claims identify the party a token was minted for, and they answer different questions.¶

The aud claim is the counterpart, on the Target side, of sub on the initiating side, and it names the same three things. Where sub identifies the combination of identities the issuer has verified for the initiator (the human principal, the agent platform and the agent), aud identifies that combination for the Target: the Target's agent, the platform it runs on, and the human principal behind it.¶

"Agent" is used broadly on the Target side. On the initiating side it is a program acting for a person. On the Target side it is whatever the initiator is dealing with, which may be a website, an API, an MCP server, or another agent. The tsi claim identifies the particular service offered under that Target agent.¶

The Token Issuer assigns both, and both are present in every token it creates, so that it can account for the tokens it has issued. Their values are meaningful to the issuer and to a Target that has onboarded to it; onboarding is what allows a Target to interpret them, not what causes them to be set.¶

The two sides differ in what stands behind them. The identities named in sub are verified by the issuer. Those named in aud and tsi are verified where the Target has onboarded to the issuer; where the issuer has no means of confirming the Target, they are its record of the Target that the initiator asserted it was minting for, and tdm carries the domain the initiator supplied.¶

A recipient reads these claims accordingly. They bind a token to one Target and so limit where it can be presented, which holds in either case because the binding narrows the token rather than granting anything. A recipient MUST NOT read tdm alone as the issuer confirming the Target's identity.¶

The tdm claim identifies a Target reached over a URL-based interface, such as a website or an HTTP API: at least its domain, and optionally its host and a path. Unlike aud and tsi it is not issuer-specific, so any recipient can interpret it without a relationship with the issuer. It is present in addition to aud and tsi where such a Target is identified by a domain name.¶

The value of tdm is a host name in lower case, optionally followed by a path, with no scheme, port, query or fragment; for example example.com, shop.example.com or shop.example.com/store. The Target's domain is the registrable domain of that host, determined using the Public Suffix List [PSL], including its private section. A host on a shared hosting platform that the list names is therefore a domain of its own, and a token minted for one such host does not name the platform's other hosts.¶

tdm and tsi are alternates rather than duplicates: they name the same Target by different means, one publicly interpretable and one not. A recipient validates whichever it is in a position to interpret. A Target that has onboarded to the issuer checks aud and tsi. A recipient that has not, including a security intermediary acting for many Targets, checks at least that tdm names the domain it is protecting for that request. The Authenticating the Counterparty section of [I-D.skyfire-oauth-using-kyapay-tokens] describes that choice.¶

A recipient that checks more than the domain checks that tdm names the Target it is protecting for the request: the host in tdm is that Target's host, and where that Target is identified by a path, the path in tdm is that path or one below it. Paths are matched as cookie paths are (Section 5.1.4 of [RFC6265]), after both are normalized as described in Section 6.2.2 of [RFC3986]. Ports are not compared. For example, for a Target at shop.example.com/store, a tdm of shop.example.com/store or shop.example.com/store/cart passes, but shop.example.com, shop.example.com/storefront and example.com/store do not. A recipient that checks only the domain does not enforce the host or the path. A Target whose host serves several tenants, or that protects only some of its paths, therefore checks the host and path itself, or aud and tsi where it has onboarded to the issuer.¶

3.4.1. hid - Human Identity Sub-Claims

The Human Identity (hid) claim contains sub-claims identifying the human principal (individual or organization) as follows.¶

id:

REQUIRED - Human principal identifier. An opaque, pseudonymous identifier for the human principal, assigned by the issuer. It MUST NOT be, or reveal, an email address, telephone number or other directly identifying attribute. An issuer MUST use the same value for the same principal acting through the same agent platform at the same Target service (tsi), whatever the agent, and MUST use a different value for each agent platform and for each Target service. Values for different agent platforms or Target services MUST NOT be linkable to one another without the issuer's cooperation; an issuer can, for example, assign each value at random or derive it using a key known only to itself. The value is unique within a given issuer, so a recipient that compares hid.id values from two tokens MUST first check that both carry the same iss.¶

email:

OPTIONAL - Email address associated with the human individual or organization.¶

given_name:

OPTIONAL - Given name(s) or first name(s) of the human principal if they are an individual.¶

middle_name:

OPTIONAL - Middle name(s) of the human principal if they are an individual.¶

family_name:

OPTIONAL - Surname(s) or last name(s) of the human principal if they are an individual.¶

phone_number:

OPTIONAL - Phone number associated with the human individual or organization.¶

organization_name:

OPTIONAL - Name of the organization.¶

verifier:

OPTIONAL - URL of the party that performed the identity verification¶

verified:

OPTIONAL - Boolean verification status. When present, the value MUST be true. An issuer does not issue a token carrying unverified identity claims, so a token never asserts false. The claim gives a recipient an explicit affirmative signal rather than requiring it to infer verification from other claims. A recipient that receives false MUST treat the claim as not asserting verification, and MUST NOT treat the token as carrying a verified identity on the strength of the claim's presence.¶

verification_id:

OPTIONAL - Verification identifier. This is the verifier's identifier for the identity verification performed. This could be used during auditing and dispute resolution.¶

ivm:

OPTIONAL - Identity Verification Methods [I-D.skyfire-oauth-id-verification]. A JSON array of the methods by which the human principal's identity was verified. An issuer SHOULD include this sub-claim when it knows the methods used.¶

amr:

OPTIONAL - Authentication Methods References, as defined in Section 2 of [OpenID.Core], with values from [RFC8176] and [I-D.skyfire-oauth-amr-values]. A JSON array of the methods by which the human principal authenticated. An issuer SHOULD include this sub-claim when it knows the methods used.¶

aml:

OPTIONAL - Anti-Money Laundering Methods [I-D.skyfire-oauth-aml-methods]. A JSON array of the anti-money laundering and counter-terrorist financing methods applied to the human principal. An issuer SHOULD include this sub-claim when it knows the methods used.¶

The ivm, amr, and aml sub-claims use the syntax and values of the claims of the same names defined in the cited specifications. The absence of any of them does not indicate that a method was not used.¶

The sub-claims email, given_name, middle_name, family_name, phone_number and organization_name directly identify the human principal, and verification_id is the same at every Target. An issuer MUST NOT include any of them unless a Target requires it for the action at hand and the principal has authorized its disclosure to that Target, whether to the issuer or to the agent platform (Section 6).¶

Additional sub-claims MAY be defined and used, including further identifiers for the human principal where a Target requires them to recognize an account. An issuer MUST NOT assert an identifier of the human principal unless it has verified that the principal controls it. This document does not prescribe how control is verified. The recipient MUST ignore any unrecognized sub-claims.¶

3.4.2. Agent Platform Identity apd Sub-Claims

The apd claim is REQUIRED in KYA and KYAPay tokens. It contains the following sub-claims.¶

id:

REQUIRED - Agent Platform identifier.¶

name:

REQUIRED - Agent Platform name.¶

email:

OPTIONAL - Email associated with agent platform.¶

phone_number:

OPTIONAL - Phone number associated with agent platform.¶

organization_name:

OPTIONAL - Legal name associated with agent platform.¶

verifier:

OPTIONAL - URL of the party that verified the agent identity (KYA)¶

verified:

OPTIONAL - Boolean verification status. When present, the value MUST be true. An issuer does not issue a token carrying unverified Know Your Agent claims, so a token never asserts false. The claim gives a recipient an explicit affirmative signal rather than requiring it to infer verification from other claims. A recipient that receives false MUST treat the claim as not asserting verification, and MUST NOT treat the token as carrying a verified identity on the strength of the claim's presence.¶

verification_id:

OPTIONAL - Verification identifier. This is the verifier's identifier for the KYA verification performed. This could be used during auditing and dispute resolution.¶

ivm:

OPTIONAL - Identity Verification Methods [I-D.skyfire-oauth-id-verification]. A JSON array of the methods by which the agent platform's identity was verified. An issuer SHOULD include this sub-claim when it knows the methods used.¶

aml:

OPTIONAL - Anti-Money Laundering Methods [I-D.skyfire-oauth-aml-methods]. A JSON array of the anti-money laundering and counter-terrorist financing methods applied to the agent platform. An issuer SHOULD include this sub-claim when it knows the methods used.¶

The ivm and aml sub-claims use the syntax and values of the claims of the same names defined in the cited specifications. The absence of either does not indicate that a method was not used.¶

In a KYAPay token, the ivm, amr, and aml claims appear only as sub-claims of hid and apd, so that each describes the party whose claim contains it: in hid, how the human principal was vetted; in apd, how the agent platform was vetted. amr does not apply to the agent platform and is not used in apd. Issuers MUST NOT include ivm, amr, or aml as top-level claims in a KYAPay token, and recipients MUST ignore them if they appear there.¶

Additional sub-claims MAY be defined and used. The recipient MUST ignore any unrecognized sub-claims.¶

3.4.3. Agent Identity aid Sub-Claims

The aid claim is REQUIRED. It contains the following sub-claims.¶

id:

REQUIRED - Agent identifier. An issuer MUST use the same value for the same agent at the same Target service (tsi), and a different value at each Target service. The value MUST NOT be, or reveal, a directly identifying attribute, and values at different Target services MUST NOT be linkable to one another without the issuer's cooperation.¶

name:

REQUIRED - Agent name. The name should reflect the business purpose of the agent. The name MUST be unique among the agents of a given agent platform at a given issuer, so that the issuer, the agent platform and the agent name together identify the agent unambiguously.¶

creation_ip:

OPTIONAL - The public IP address of the system / agent that requested the token. Its value is a string containing the public IPv4 or IPv6 address from where the token request originated. When present, it MUST be captured directly from the token request. It is a diagnostic aid, for example when investigating an incident, and is not an access-control signal: a recipient MAY use it as a weak corroborating signal only and MUST NOT treat it as sufficient on its own (Section 6.3 of [I-D.skyfire-oauth-using-kyapay-tokens]). It is personal data, subject to the privacy considerations in Section 6.¶

source_ips:

OPTIONAL - Valid public IP address, or range of public IP addresses, from where the system / agent's requests to merchants / services will originate. A JSON array of IPv4 addresses or ranges, IPv6 addresses or ranges, or domain names resolvable to an IP address via DNS. IPv4 and IPv6 addresses can be a single IPv4 or IPv6 address or a range of IPv4 or IPv6 addresses in CIDR notation or start-and-end IP pairs.¶

Additional sub-claims MAY be defined and used. The recipient MUST ignore any unrecognized sub-claims.¶

3.5.1. Settlement Information sti Sub-Claims

The sti claim is REQUIRED in Pay Tokens. It contains the following sub-claims, with the requirement levels marked below.¶

The sti claim carries the settlement instrument, and its contents depend on the value of stp.¶

When the stp value is card, the settlement instrument is an agentic payment credential issued by a payment network under an agentic-commerce programme -- for example Visa Intelligent Commerce (visa_vic) or Mastercard Agent Pay, using Secure Card on File (mastercard_scof). Such a credential is a payment token issued by the payment network (Section 3.5.2). It is used with a single-use token cryptogram (token_security_code), and the network restricts its use to one initiator, one target, and one amount. It is not a Primary Account Number (PAN), and the underlying PAN cannot feasibly be recovered from it.¶

type:

REQUIRED - "type" is dependent on the "stp" value; for "coin" - "usdc"; for "card" - "visa_vic" or "mastercard_scof". Additional values may be defined and used.¶

payment_token:

REQUIRED when the stp value is card; otherwise OPTIONAL - String containing the network-issued agentic payment credential, formatted per ISO/IEC 7812, 12-19 characters. This value MUST be a payment-network-issued agentic or tokenized credential. It MUST NOT be a Primary Account Number (PAN).¶

token_expiration_month:

REQUIRED when payment_token is present - String containing two-digit Expiration Month Number.¶

token_expiration_year:

REQUIRED when payment_token is present - String containing four-digit Expiration Year.¶

token_security_code:

REQUIRED when payment_token is present - String containing the single-use token cryptogram accompanying the credential in payment_token -- a Dynamic Token Verification Value (DTVV) or Token Authentication Verification Value (TAVV), depending on the network. 3 or 4 digits. This value is generated per transaction and is short-lived; its validity period is determined and enforced by the payment network. It MUST NOT be a static Card Verification Value (CVV, CVC2 or CVV2).¶

verifier:

OPTIONAL - URL of the party that performed the payment method verification¶

verified:

OPTIONAL - Boolean verification status. When present, the value MUST be true. An issuer does not issue a token against an unverified payment method, so a token never asserts false. The claim gives a recipient an explicit affirmative signal rather than requiring it to infer verification from other claims. A recipient that receives false MUST treat the claim as not asserting verification, and MUST NOT treat the token as carrying a verified payment method on the strength of the claim's presence.¶

verification_id:

OPTIONAL - Verification identifier. This is the verifier's identifier for the payment method verification performed. This could be used during auditing and dispute resolution.¶

Additional sub-claims MAY be defined and used. The recipient MUST ignore any unrecognized sub-claims.¶

3.5.2. Scope of Card Settlement

This specification supports card settlement only through payment-network agentic-commerce programmes whose credentials are Payment Tokens as defined by the EMV Payment Tokenisation Specification [EMVCo-PT], used with a single-use token cryptogram and restricted by the payment network to the transaction bound in the token.¶

A token defined in this specification, of any type, MUST NOT contain a Primary Account Number, full magnetic-stripe or chip track data, a static card verification value (CVV, CVC2 or CVV2), or a PIN or PIN block.¶

Settlement instruments that fall within PCI DSS scope require mechanisms this specification does not define -- including confidentiality protection of the token contents and a defined cardholder-data-environment boundary. Support for such instruments is left to future work, and implementers requiring it should not attempt to carry them in the claims defined here.¶

3.5.3. PAY Token Example

The following informative example displays a decoded PAY type token.¶

{
  "kid": "FgT4q8c5IqbBCCjcho5JdeGQvuK1keMDFc9IwCm8J7Y", // JWK Key ID
  "alg": "ES256",
  "typ": "pay+jwt"
}.{
  "iss": "https://pay-issuer.example.net", // Issuer URL
  "iat": 1742245254,
  "exp": 1742245554,
  "jti": "b9821893-7699-4d24-af06-803a6a16476b",
  "sub": "8b810549-7443-494f-b4ad-5bc65871e32b", // Bound identity combination: hid + apd + aid
  "aud": "37888095-2721-48d9-a2df-bfe4075f223a", // Target Agent Account ID

  "env": "sandbox",
  "tsi": "274efc47-024e-466f-b278-152d2ee73955", // Target Service ID
  "itg": "16c135ce-a99a-453d-a7b5-4958fd91de5f", // Initiator Tag (Internal Reference ID)

  "tpr": "0.01",
  "tps": "pay_per_use",
  "amt": "15",
  "cur": "USD",
  "val": "15000000",
  "mnr": 1600,
  "stp": "card",
  "sti": {
    "type": "visa_vic",
    "payment_token": "0000000000000000", // Example only: a network-issued payment token, not a PAN
    "token_expiration_month": "03",
    "token_expiration_year": "2030",
    "token_security_code": "000", // Example only: a single-use cryptogram (DTVV or TAVV), not a CVV
    "verifier": "https://verifier.example.info", // URL of payment method verifier
    "verified": true, // Outcome of the verifier's payment method verification
    "verification_id": "3a6e1b76-8f78-4c24-b1bd-dc78a8cc3711" // Verifier's ID for the payment method verification performed
  }
}

4.1.1. JWT Header Validation

1. alg - The alg header parameter MUST be present. Recipients MUST support ES256 [RFC7518], and MUST accept it from any issuer they trust whose JWK Set publishes an ES256 key. Issuers MUST use ES256, or an algorithm that they know every recipient of the token accepts.¶

   A recipient MUST determine the set of algorithms it will accept for a given issuer, limited to those for which the issuer's JWK Set publishes a suitable key. The set MUST NOT be derived from the token. A token whose alg value is absent from, or outside, that set MUST be rejected, including the value none [RFC7515] and any symmetric (MAC) algorithm, since an issuer's JWK Set publishes only public keys. Verification is then performed using the algorithm named in the token and the key obtained from the issuer's JWK Set, or the token is rejected.¶

   Together, these guarantee that any conforming recipient can verify a token whose recipients the issuer does not know in advance, without constraining which algorithm a deployment uses. Implementations remain free to support and use others, including post-quantum algorithms as they are standardized; this requirement is a floor for interoperability, not a ceiling on agility.¶

   Where the key retrieved from the issuer's JWK Set carries an alg or use parameter, the recipient MUST confirm it is consistent with the parameters of the issued token, and reject the token otherwise.¶

2. kid - The kid claim MUST be present, and set to a valid Key ID present in the issuer's JWK Set, located as described in Section 3.2.¶

3. typ - The typ header parameter MUST be present, and its value MUST be one of: kya+jwt, pay+jwt, or kya-pay+jwt. As specified in Section 4.1.9 of [RFC7515], values are compared case-insensitively, and a value with the application/ prefix, such as application/kya+jwt, is the same type. A token whose typ is absent or has any other value fails validation. A recipient MUST determine which of these types it accepts for a given request before validating a token. A token of one of these types that the recipient does not accept for that request is set aside: the recipient does not use it for that request, and does not treat it as having failed validation.¶

4.1.2. JWT Payload Validation

1. Validate iss Claim - Ensure that the token's issuer is one the recipient trusts (Section 4.1).¶

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

3. Validate the exp Claim - The recipient MUST validate that the token has not expired, within the clock skew tolerance described in Section 4.1.3.¶

4. Validate the iat Claim - The recipient MUST validate that the token was issued in the past, within the clock skew tolerance described in Section 4.1.3.¶

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

6. Validate the Audience - A recipient that has onboarded to the issuer ensures that aud and tsi identify it as the intended audience. A recipient that has not ensures at least that tdm names the domain it is protecting for the request (Section 3.1.1).¶

7. Validate the env Claim - Ensure that the Environment claim is set to an expected and use case appropriate value (such as production or sandbox)¶

4.1.3. Clock Skew

The iat and exp claims are set from the issuer's clock and evaluated against the recipient's. These are never precisely synchronized, so a recipient applies a tolerance when evaluating them.¶

A recipient MUST accept a token whose iat is up to the tolerance in the future, and MUST accept a token up to the tolerance beyond its exp.¶

A recipient MUST support a tolerance of at least 5 seconds. A recipient SHOULD NOT apply a tolerance greater than 60 seconds; 30 seconds is RECOMMENDED. A tolerance approaching the token's own lifetime defeats the purpose of exp: the effective window in which a captured token is accepted is its lifetime plus twice the tolerance.¶

Where a party generating these timestamps can observe the Date header field (Section 6.6.1 of [RFC9110]) of a response from the intended recipient, it SHOULD use that value to correct subsequent timestamps rather than relying on the recipient's tolerance. Correcting at the sender resolves skew at the only party positioned to detect it.¶

7.1.1. "tdm" Claim

• Claim Name: tdm¶

• Claim Description: Target domain the token is intended for¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.1 of this specification¶

7.1.2. "tsi" Claim

• Claim Name: tsi¶

• Claim Description: Target Service ID that this token was created for¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.1 of this specification¶

7.1.3. "ori" Claim

• Claim Name: ori¶

• Claim Description: URL of the token's originator¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.1 of this specification¶

7.1.4. "env" Claim

• Claim Name: env¶

• Claim Description: Issuer environment (such as "production" or "sandbox")¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.1 of this specification¶

7.1.5. "itg" Claim

• Claim Name: itg¶

• Claim Description: Initiator tag, an opaque reference ID internal to the initiator¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.1 of this specification¶

7.1.6. "hid" Claim

• Claim Name: hid¶

• Claim Description: JSON structure containing human identity claims¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.4 of this specification¶

7.1.7. "apd" Claim

• Claim Name: apd¶

• Claim Description: JSON structure containing agent platform identity claims¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.4 of this specification¶

7.1.8. "aid" Claim

• Claim Name: aid¶

• Claim Description: JSON structure containing agent identity claims¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.4 of this specification¶

7.1.9. "tpr" Claim

• Claim Name: tpr¶

• Claim Description: JSON string representing target service price in currency units¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.5 of this specification¶

7.1.10. "tps" Claim

• Claim Name: tps¶

• Claim Description: Target pricing scheme, which represents a way for the target list how it charges for its service or content¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.5 of this specification¶

7.1.11. "amt" Claim

• Claim Name: amt¶

• Claim Description: JSON string representing token amount in currency units¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.5 of this specification¶

7.1.12. "cur" Claim

• Claim Name: cur¶

• Claim Description: Currency unit, represented as an ISO 4217 three letter code, such as "EUR"¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.5 of this specification¶

7.1.13. "val" Claim

• Claim Name: val¶

• Claim Description: JSON string representing token amount in settlement network's units¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.5 of this specification¶

7.1.14. "mnr" Claim

• Claim Name: mnr¶

• Claim Description: JSON number representing maximum number of requests¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.5 of this specification¶

7.1.15. "stp" Claim

• Claim Name: stp¶

• Claim Description: Settlement type¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.5 of this specification¶

7.1.16. "sti" Claim

• Claim Name: sti¶

• Claim Description: Meta information for payment settlement, depending on settlement¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

• Reference: Section 3.5 of this specification¶

7.2.1. application/kya+jwt

• Type name: application¶

• Subtype name: kya+jwt¶

• Required parameters: n/a¶

• Optional parameters: n/a¶

• Encoding considerations: Uses JWS Compact Serialization as defined in [RFC7515]¶

• Security considerations: See Security Considerations in [RFC7519]¶

• Interoperability considerations: n/a¶

• Published specification: Section 3.4 of this specification¶

• Applications that use this media type: Applications using Know Your Agent tokens¶

• Additional information:¶

  • Magic number(s): n/a¶

  • File extension(s): n/a¶

  • Macintosh file type code(s): n/a¶

• Person & email address to contact for further information: TBD¶

• Intended usage: COMMON¶

• Restrictions on usage: none¶

• Author: Michael B. Jones - michael_b_jones@hotmail.com¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

7.2.2. application/pay+jwt

• Type name: application¶

• Subtype name: pay+jwt¶

• Required parameters: n/a¶

• Optional parameters: n/a¶

• Encoding considerations: Uses JWS Compact Serialization as defined in [RFC7515]¶

• Security considerations: See Security Considerations in [RFC7519]¶

• Interoperability considerations: n/a¶

• Published specification: Section 3.5 of this specification¶

• Applications that use this media type: Applications using Pay tokens¶

• Additional information:¶

  • Magic number(s): n/a¶

  • File extension(s): n/a¶

  • Macintosh file type code(s): n/a¶

• Person & email address to contact for further information: TBD¶

• Intended usage: COMMON¶

• Restrictions on usage: none¶

• Author: Michael B. Jones - michael_b_jones@hotmail.com¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶

7.2.3. application/kya-pay+jwt

• Type name: application¶

• Subtype name: kya-pay+jwt¶

• Required parameters: n/a¶

• Optional parameters: n/a¶

• Encoding considerations: Uses JWS Compact Serialization as defined in [RFC7515]¶

• Security considerations: See Security Considerations in [RFC7519]¶

• Interoperability considerations: n/a¶

• Published specification: Section 3.6 of this specification¶

• Applications that use this media type: Applications using KYA-Pay tokens¶

• Additional information:¶

  • Magic number(s): n/a¶

  • File extension(s): n/a¶

  • Macintosh file type code(s): n/a¶

• Person & email address to contact for further information: TBD¶

• Intended usage: COMMON¶

• Restrictions on usage: none¶

• Author: Michael B. Jones - michael_b_jones@hotmail.com¶

• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com¶