Skip to content

RFC: Verify Your Agent (VYA) Standard

Status: Draft

Version: 1.0

1. Overview

The Verify Your Agent (VYA) Standard establishes the mandatory baseline requirements for Payment Service Providers (PSPs) and autonomous software Agents during the execution of a transaction. While the KYA standard governs the initial establishment of identity, the VYA standard governs the continuous, cryptographically secure verification of every individual payment or action initiated by an Agent.

The core objective of the VYA framework is to systematically verify that every payment request: 1. Is Authentic and originates from the rightfully registered Agent. 2. Maintains Data Integrity and has not been tampered with. 3. Is Fresh and explicitly protected against replay and delay attacks. 4. Strictly adheres to the Authorized Boundaries previously specified by the user.

2. Mandatory Requirements

Requirement 1: Cryptographic Proof of Origin and Data Integrity

Objective: Guarantee that every transaction request represents the explicit, untampered intent of the specific Agent holding the securely stored private key.

  • 1.1 Comprehensive Payload Signing: The Agent must construct a canonical string encompassing all critical transaction parameters (e.g., HTTP method, URI, Authorization ID, Timestamp, Nonce, and structured Body payload).
  • 1.2 Non-Repudiable Signatures: Every payment request must include a cryptographic signature generated by hashing the canonical string (e.g., via SHA-256) and signing it with the Agent's locally protected private key.

Requirement 2: Dual-Layer Authentication

Objective: Establish a defense-in-depth approach to authenticate the incoming request at both the transport layer and the application layer.

  • 2.1 Transport Layer Identity Guarantee: The PSP must verify the origin of the request using mutual TLS (mTLS). The unique client certificate presented during the connection must strictly match the certificate issued to the Agent during the KYA registration phase.
  • 2.2 Application Layer Identity Binding: The PSP must definitively verify that the Authorization ID provided in the request headers is legally bound to the specific Agent ID authenticated at the transport layer.

Requirement 3: Defense Against Replay and Delay Attacks

Objective: Eliminate the possibility of transaction duplication, malicious request interception, and delayed execution by enforcing strict "freshness" constraints.

  • 3.1 Strict Time Windows (Anti-Delay Mechanism): Every request must contain a definitive generation timestamp. The PSP must enforce a strict, narrow expiration window (e.g., rejecting any request where the time drift exceeds 30 seconds from the PSP's current system time).
  • 3.2 Single-Use Nonces (Anti-Replay Mechanism): Every request must include a unique cryptographic nonce. The PSP must actively track, cache (e.g., for at least the duration of the timeout window), and definitively reject any previously submitted nonces.

Requirement 4: Continuous Authorization Compliance

Objective: Ensure that the transaction strictly adheres to the limits and state agreed upon during the user's initial KYA authorization.

  • 4.1 Cryptographic Key Validation: The PSP must retrieve the Agent's original registered public key and mathematically verify the payload signature before executing the transaction.
  • 4.2 Authorization State Validation: The PSP must confirm that the provided Authorization ID corresponds to an active state and has not been revoked, paused, or artificially expired.
  • 4.3 Boundary Enforcement Checks: The PSP must validate that the specific parameters of the current transaction (e.g., transaction amount, currency) are strictly within the remaining limits or constraints explicitly authorized by the user.

3. Best Practice Implementation (Non-Normative)

This section provides a detailed, compliant implementation of the VYA protocol during a payment event.

Step 1: Agent Initiates Payment (Request Construction)

The Agent prepares a payment request with security headers.

API Endpoint: POST https://api.payments.com/payments

Headers: * Authorization-ID: auth_456xyz * X-Timestamp: 1710000000 * X-Nonce: random_nonce_123 * X-Signature: SIGNATURE_DATA...

Body Payload: 

{
  "amount": 50.00,
  "currency": "GBP",
  "merchant": "merchant_identifier"
}

Step 2: Signature Generation Logic (Agent Side)

  1. Construct Canonical String: 
    POST
/payments
auth_456xyz
1710000000
random_nonce_123
{"amount":50,"currency":"GBP","merchant":"merchant_identifier"}
  2. Generate Hash: H = SHA256(canonical_string)
  3. Sign: SIGNATURE_DATA = SignWithPrivateKey(agent_private_key, H)

Step 3: PSP Validation Workflow

Upon receiving the request, the PSP undergoes the following check sequence:

  1. mTLS Verification: PSP verifies the client_cert presented in the mTLS handshake to identify the caller as agent_789.
  2. Identity Correlation: PSP looks up auth_456xyz and confirms it is bound to agent_789. If mismatch, return 403 Forbidden.
  3. Freshness Check:
    • |server_time - X-Timestamp| < 30s.
    • Checks if random_nonce_123 exists in the "Recently Used Nonce" cache (e.g., Redis). If found, return 401 Unauthorized (Replay Attack).
  4. Signature Verification: PSP retrieves PUB_KEY_ABC associated with agent_789 and verifies the X-Signature against the reconstructed canonical string.
  5. Limit Check: PSP checks the limits set in the database for auth_456xyz.
    • If amount (50.00) <= remaining_limit, proceed to transaction execution.
    • If amount > limit or RiskScore > Threshold, trigger Challenge (Transition to Attended Transaction).

Step 4: Success Response

{
  "status": "success",
  "transaction_id": "txn_999",
  "timestamp": "1710000005"
}