Agent Network Identity

​

Signature profiles

​

TAP body objects

• where the objects sit in the body (default: top-level agenticConsumer and agenticPaymentContainer members);
• what the object signature covers (default: RFC 8785 JCS of the object without signature, signature base64url).

​

The Grantex consent record object

​

The registry key directory

PUT /v1/agents/{agentId}/http-signature-directory
Authorization: Bearer <developer API key>
Content-Type: application/json

{ "published": true }

• Only keys that are usable now are listed: active, or rotated and inside their overlap; never pending, unproven or compromised; the agent must be active. Removing a key from the directory is how it is deactivated.
• Only P-256 (ecdsa-p256-sha256) and Ed25519 (ed25519) keys are listed.
• Each entry has kid = its RFC 7638 thumbprint, use: "sig", nbf and, for a rotated key, exp.
• The response carries Content-Digest and Cache-Control: public, max-age=300.

​

Signature-Agent on Grantex agent requests

const grantex = signWithProfile(request, { key, agentPassport, agentGrant });
const webBotAuth = signWithProfile(request, {
  profile: 'web-bot-auth',
  key,
  label: 'sig2',
  components: ['@method', '@authority', '@path', 'content-digest', 'signature-agent'],
  signatureAgent: { url: 'https://registry.example' },
});
Object.assign(request.headers, combineSignatures(grantex, webBotAuth));

​

Scheme agent ids

"scheme_agent_ids": [
  { "scheme": "visa_tap", "agent_id": "tap-agent-0001" },
  { "scheme": "mastercard_agent_pay", "agent_id": "agent-pay-0001" }
]

• The schemes are visa_tap and mastercard_agent_pay. The identifiers are opaque, scheme-scoped strings of 1 to 256 characters. Neither scheme publishes an identifier format (TAP keys an agent by the keyid of its key store; Mastercard Agent Pay’s wire details are not public), so the registry never parses or validates them beyond length.
• A relying party finds the agent with GET /v1/registry/agents?scheme=visa_tap&scheme_agent_id=tap-agent-0001. The answer is the usual minimised lookup, and each counted attestation shows the scheme_agent_ids it carries.
• /.well-known/agent-registry.json names the schemes, each with id_format: "opaque", and the agent_by_scheme_agent_id lookup template.

​

Scheme token binding on the payment capability

"token_binding": {
  "scheme": "visa",
  "token_ref": "tokref_0001",
  "agent_id": "shopper-01",
  "merchant_scope": ["merchant.example"],
  "limits": { "max_amount": 250000, "currency": "INR", "expires_at": "2026-11-01T00:00:00Z" }
}

• token_ref is an opaque reference to the token the scheme or provider holds, never the token and never an account number: a run of 13 to 19 digits is refused.
• The binding must sit inside the capability: the same buyer agent, merchants within its merchant_scope, the same currency, a limit no higher than its max_amount, and no expiry after the artifact’s. Anything else is refused with token_binding_invalid.
• Grantex describes and checks the binding; it never executes it. The relying party’s executor (AgenticOrg’s Plural executor, for example) calls the scheme or provider.

​

KYA tier on the Agent Passport

​

HTTP 402 payments: challenges, receipts and commitment evidence

• MPP uses the “Payment” HTTP authentication scheme (draft-ryan-httpauth-payment-01): WWW-Authenticate: Payment … on the 402, Authorization: Payment <base64url JSON> on the retry, Payment-Receipt on success. @grantex/mpp implements the challenge binding, the credential checks, the receipt, the problem details and an Express middleware.
• x402 v2 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE. @grantex/x402 pays through them and reads the settlement receipt.
• Commitment evidence. POST /v1/commerce/oacp/commitment-evidence/settlement-receipts (AgenticOrg service token, scope commerce.oacp.commitment_evidence.write, allow-listed tenants) binds a successful x402 settlement or MPP receipt to a commitment as a signed commitment_evidence artifact on the OACP status list: commitment_type: "settlement_receipt_reference", the artifacts the commitment relied on (issued, unrevoked, same tenant and merchant), and the receipt’s sha-256 over its RFC 8785 form with the network or method and the transaction or reference. The payer is never copied. Neither receipt form is signed, so the artifact records receipt_verification: "reported_not_verified_by_grantex". It is idempotent per commitment: the same receipt returns the same artifact, another receipt is 409 commitment_receipt_conflict; a failed settlement is 422 settlement_not_successful.

{
  "tenant_id": "cten_example",
  "merchant_id": "merchant.example",
  "seller_agent_id": "seller-01",
  "buyer_agent_id": "shopper-01",
  "commitment_id": "commit-0001",
  "artifact_refs_used": ["oacp_art_..."],
  "policy_version": "2026-10-01",
  "receipt": {
    "protocol": "x402",
    "x402_version": 2,
    "settlement": { "success": true, "transaction": "0x...", "network": "eip155:84532" },
    "gdt_jti": "gdt_..."
  }
}