ATLAS: Agent Trust Layer and Assurance Standard

Abstract

This specification defines the Agent Trust Layer and Assurance Standard (ATLAS) protocol — a chained-capability-token assessment framework for agentic commerce. ATLAS standardises how authorized Assessor agents obtain bounded, encrypted evidence from subject agents, evaluate intent fidelity and policy compliance, and produce signed artifacts that can be consumed upstream and downstream without exposing raw conversations or unnecessary personal data.

ATLAS supports two assessment-initiation patterns: a holder-mediated path (merchant or credential provider commissions an Assessor) and a direct path (subject agent self-commissions an Assessor for compliance or regulatory evidence). Application trust relies on chained JWS/JWT delegation tokens and JWE-encrypted evidence over HTTPS with standard TLS. Downstream payment-rail integration uses compact ReportToken references assembled into a redeem_tokens field by the merchant processor for ISO 8583, EMV 3-D Secure, and ISO 20022.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document was produced by Hyperlab, the innovation lab within Consult Hyperion (consulting by fime), as part of the Continuous Certification programme for agentic commerce (ATLAS). It is a Working Draft and does not represent a final standard. It has not been reviewed or endorsed by any external standards body.

All terminology, artifact definitions, claim sets, and normative requirements are design intent for a forthcoming base specification rather than binding requirements at this stage. If you wish to make comments regarding this document please use the GitHub issue tracker or contact your Fime / Consult Hyperion programme lead. All comments are welcome.

1. Introduction§

Agentic commerce introduces a new class of trust problem: natural-language user intent passes through autonomous subject agents, merchant agents, and credential providers before it is expressed as cryptographic payment artifacts. Existing protocols — AP2, Verifiable Intent (VI), and UCP — secure the lower layers (mandate delegation, checkout authorisation, and payment completion) but do not define a standard protocol for an independent Assessor to retrieve and assess the pre-checkout intent interpretation and agent reasoning that produced those artifacts.

ATLAS fills this gap. It defines a portable, cryptographically verifiable protocol through which Assessor agents authorized by a trust authority (TA) may obtain scoped, encrypted evidence from a subject agent — without requiring trust in any individual intermediary and without revealing sensitive user intent to parties with no legitimate need.

1.1 Problem Statement§

Autonomous AI agents are increasingly authorised to act on behalf of human principals in commerce, finance, and regulated industries — selecting goods, negotiating terms, and initiating payments without per-transaction human approval. This autonomy introduces a systemic oversight gap: the agent's chain of decisions between the user's original instruction and the final payment action is opaque, probabilistic, and subject to silent drift. No party in the value chain — merchant, credential provider, payment network, issuer, or regulator — currently holds a standardised, independently verifiable record of what the agent understood and acted upon.

For the payment industry this gap is acute. Schemes and issuers require trust signals that travel with the authorisation message and can be used to:

• Mitigate chargeback risk. Distinguish legitimate agent-initiated purchases from fraudulent ones, and provide an assessable record of authorised user intent that survives a "I did not authorise this" dispute.
• Manage fraud liability. Determine whether liability shifts to the agent provider, merchant, or issuer when an agent-initiated transaction is later disputed, based on independent evidence of what the agent was instructed to do versus what it actually did.
• Ensure compliance. Demonstrate that agent-initiated transactions comply with applicable regulations — including the EU AI Act (transparency and explainability obligations for high-risk AI systems), PSD2 / PSD3 (strong customer authentication and transaction monitoring), DORA (operational resilience and assessability of third-party AI systems), and the Interchange Fee Regulation (IFR, EU 2015/751) (cost justification and routing transparency for card-based transactions where agent-selected routing may affect interchange) — as well as network rulebooks, at the time of authorisation and not only at onboarding.
• Protect data privacy. Enable assessability of agent reasoning without exposing raw user data to payment networks, merchants, or processors: the trust signal must be verifiable without being a surveillance instrument.
• Avoid disputes. Give merchants and consumers a common reference record — signed and time-stamped by a neutral party — that can be consulted before a chargeback is filed and used to resolve disputes without litigation.
• Extend and continuously feed KYA monitoring. Know Your Agent (KYA) frameworks perform pre-runtime identity verification — confirming who built the agent, which cryptographic keys it holds, and what scopes it claims at registration. ATLAS extends this static identity layer with runtime behavioural evidence: every AssessmentResult and associated evidence hash constitutes a machine-readable behavioural signal that can be fed back into KYA monitoring pipelines. Over time, a series of AssessmentResult verdicts for a given agent identifier reveals drift patterns — scope creep, intent distortion, or policy violations — that are invisible to static KYA checks but detectable through continuous assessment. Payment networks and issuers can therefore use ATLAS-derived signals to update agent trust scores, trigger re-attestation requirements, or suspend agent credentials when behavioural deviations cross a defined threshold, creating a closed loop between initial agent identity verification and ongoing runtime trustworthiness assessment.

Existing protocols address complementary problems. AP2 and Verifiable Intent (VI) provide strong cryptographic controls once the flow is expressed as mandates and payment artifacts, but do not define a standard protocol for an independent Assessor to assess how the agent interpreted user intent, propagated constraints, and selected merchants before those artifacts were created. Know Your Agent (KYA) frameworks establish pre-runtime identity — who built the agent and which keys it holds — but cannot guarantee what the agent actually did during a live transaction.

Intent drift is the primary and most operationally significant instance of this broader oversight gap. It occurs when the agent's interpretation of natural-language user constraints (budget, allergens, ethical preferences, risk appetite, medical limitations) diverges from the user's actual intent across the interpretation, structuring, and presentation layers of an agentic commerce stack (see §1.4). In the payment context, intent drift translates directly into wrong purchases, misallocated liability, and undetected fraud — with no independent record to adjudicate the outcome.

ATLAS standardises how authorized Assessor agents, operating as neutral third parties, obtain bounded and encrypted evidence from the subject agent, evaluate it against a named policy referential, and produce a compact cryptographic trust signal (ReportToken) that can be carried in ISO 8583, EMV 3DS, and ISO 20022 messages.

1.2 Design Goals§

1. Privacy by default. Structured summaries; encrypt user intent and agent reasoning so only the designated Assessor can read it.
2. Cryptographic chain of trust. Verifiable chain across Subject Agent, Assessor, Merchant, CP, processor, network, bank, and trust authority.
3. Complementarity with AP2/VI/UCP. Align with mandate delegation, key binding, verifier receipts — don't replace them.
4. Durable evidence. Support real-time processing decisions and later dispute review.
5. Direct assessment commissioning. Subject agent may self-commission assessments without a merchant holder.
6. Registry-level Assessor roster. Discover eligible Assessors, TA trust anchors, and authorization metadata without ad hoc configuration.
7. Separation of authority. Separate authority to request an assessment / read private evidence / redeem downstream reports.
8. Rail-compatible token. Downstream token fits in ISO 8583 / EMV 3DS / ISO 20022.
9. Chained signed-token model. JWS/JWT + JWE over HTTPS/TLS.
10. Chained capability tokens (cnf per RFC 7800) - (no human verifier in this flow).

1.4 Why Assessment? The Agentic Commerce Trust Problem§

The Three Risk Layers in Agentic Commerce

An agentic commerce flow converts a human's natural-language expression into a structured payment action — choosing merchants, building carts, and initiating checkout — without the human reviewing every intermediate step. That conversion passes through three consecutive layers, each of which can silently distort the user's original intent:

Interpretation layer.

The large language model (LLM) maps the user's free text to an internal representation using the probability distributions encoded in its weights. Constraints that are rare, ambiguous, or medically nuanced (e.g. a specific allergen interaction with a prescribed drug) may be approximated, under-weighted, or collapsed into a generic label.

Structuring layer.

To invoke tools via MCP or a comparable protocol the LLM must serialise its interpretation into a typed, schema-constrained JSON object. Fields that do not map cleanly to the target schema are compressed or silently dropped. A constraint that survived the interpretation layer may not survive serialisation.

Filtering and presentation layer.

Privacy and safety filters (PII scrubbing, safety classifiers, content moderation) operate between the LLM and downstream systems. These layers are necessary but can unintentionally redact or generalise critical constraints — for example, a medical allergy note — before the tool call or the confirmation screen is rendered. The user then sees a simplified summary that looks correct while missing nuances that matter for safety or compliance.

From KYA to Continuous Runtime Assessment

Payment networks have responded to agentic commerce by introducing Know Your Agent (KYA) frameworks — agent registration, cryptographic key binding, and verifiable credentials that attest to an agent's identity before any token is issued. KYA is a necessary foundation, but it is pre-runtime: it establishes who built the agent and which keys it holds, not what the agent actually does during a live transaction.

Agents placed under ATLAS assessment are typically non-deterministic systems subject to prompt injection, memory poisoning, supply-chain compromise, and non-deterministic drift: identical prompts can produce different outputs across runs, and the agent's effective behaviour can change after a model update or tool swap without any visible modification to its KYA credentials. A clean cryptographic handshake at checkout does not reveal whether the agent silently dropped a medical constraint five steps earlier.

ATLAS addresses this gap by providing a neutral runtime trust layer that continuously verifies what agents actually do, sitting above payment rails and below agents, independently of any single network or agent provider.

What the Assessor Evaluates: Agent Data vs. Referential

an ATLAS Assessor Agent evaluates evidence from complementary sources, unified under the evidence-artifact model (§8.3.1):

• Subject Agent package (AssessmentEvidenceResponse JWE, §8.5) — intent, reasoning, supply-chain provenance, and optional evidence_artifacts[] with provenance: agent_observed.
• Holder-commissioned artifacts (Link 2 requester_evidence, holder mode only) — provenance: holder_commissioned; independent merchant/CP attestation when commissioning the assessment.

The Assessor compares these sources against the active policy referential (policy_referential on Link 1). The JWE is encrypted to the Assessor only and never forwarded to merchants, CPs, or payment networks. Narrative fields include user intent, reasoning chain, supply-chain provenance, and — when required — agent_observed counterparty artifacts (merchant carts, AP2 mandates) relayed by the Subject Agent.

In holder mode, merchants and CPs MAY attach holder_commissioned artifacts on Link 2. In direct mode, the Subject Agent MUST supply counterparty material via agent_observed artifacts in the JWE when the policy referential requires it. The Assessor SHOULD perform evidence_cross_check (§8.6) before issuing AssessmentResult.

The policy referential identifies the framework or rulebook against which the evidence is evaluated. Examples:

the Assessor produces an AssessmentResult (Link 4) containing a binary or graded verdict, a hash of the evidence reviewed, the policy_referential applied, and — when the trust authority so requires — a report_token that can be redeemed by the payment network or issuer for a stored trust-assurance report. This is the mechanism by which a payment authorisation decision can incorporate independent runtime evidence about agent behaviour, complementing the static KYA signals already present in the authorisation message.

1.3 Relationship to Other Specifications§

2. Conformance§

As well as sections marked as non-normative, all diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

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.

Subject Agent

MUST implement Link 1 issuance (§8.1/§8.2), Link 3 assertion verification (§8.4), JWE evidence release (§8.5), and AssessmentResult conveyance (§8.6).

Merchant / Credential Provider (Holder)

MUST implement Link 2 issuance (§8.3) including optional requester_evidence (§8.3.1), and AssessmentResult conveyance (§8.6).

Assessor Agent

MUST implement Link 3 assertion issuance (§8.4), evidence decryption, requester-artifact verification (§8.3.1), evidence cross-check (§8.6), and AssessmentResult / ReportToken issuance (§8.6).

Trust Authority

MUST issue authorization credentials, operate a report API, and participate in the trust registry roster.

Merchant Processor

MUST verify conveyed AssessmentResult payloads, extract report_token values, and assemble redeem_tokens for payment rails (§8.7).

3. Terminology§

Agentic Commerce

A commerce flow in which autonomous AI agents negotiate, select, and authorise transactions on behalf of a user using structured mandate and policy artifacts.

Subject Agent

An autonomous software agent that is the subject of an ATLAS assessment. It issues Link 1, holds user intent and reasoning evidence, and serves as the cryptographic root of trust for that evidence within the protocol.

Holder

The merchant or credential provider that holds an ATLAS AssessmentDelegation and may issue a chained AssessmentSubDelegation. Holder mode only.

Assessor Agent

An authorized software agent that presents an AssessorAccessAssertion, receives encrypted evidence, evaluates it, and issues signed AssessmentResult and ReportToken.

Trust Authority (TA)

An independent organisation that authorizes Assessor agents, signs authorization credentials, stores reports, and redeems ReportToken values.

Trust Registry

A governance framework that manages participating TAs and publishes the authoritative Assessor roster.

AssessmentDelegation (Link 1)

Signed JWT/JWS issued by the subject agent. MUST carry agent_cnf and agent (§8.1.1).

AssessmentSubDelegation (Link 2)

Signed JWT issued by a holder to a specific Assessor, chained to Link 1 via parent_jti, binding the assessor's key in cnf. Holder mode only. MAY carry requester_evidence (§8.3.1).

AssessorAccessAssertion (Link 3)

Signed JWS issued by the Assessor to the subject agent, embedding the delegation chain and authorization credential, signed over a fresh nonce. Unlocks the JWE evidence release on successful verification.

AssessmentEvidenceResponse

JWE (RFC 7516) issued by the subject agent to the Assessor containing sensitive user intent and agent reasoning. Not forwarded to any other party.

AssessmentResult (Link 4)

Signed JWS result envelope issued by the Assessor containing the assessment verdict, policy referential, evidence hashes, optional evidence_cross_check summary (§8.6), and a report_token. Link 4 MUST NOT embed Link 2; it references evaluated artifacts via link2_jti, requester_evidence_digest, and observed_artifacts_digest.

ReportToken (Link 5)

Compact, opaque downstream token providing a redeemable reference to one stored assessment report. One token per assessment.

redeem_tokens

Payment-rail-only field (ISO 8583 / EMV 3DS / ISO 20022) assembled by the merchant processor from up to three report_token values. Not an ATLAS protocol link.

cnf claim

JSON key confirmation claim (RFC 7800) binding a specific public key via JWK thumbprint (jkt) to a JWT.

agent

Scheme-agnostic JSON object on Link 1 naming the Subject Agent and optional registered_identities[] for network-scoped registrations. Cryptographic binding is in agent_cnf (§8.1.1).

agent_cnf claim

RFC 7800 key confirmation on Link 1 binding the Subject Agent issuer public key (jkt). The Subject Agent MUST sign Link 1 and the inner evidence JWS with the matching private key.

identity scheme

A URI in agent.scheme or per registered_identities[] entry identifying an external identity framework (e.g. KYA-OS).

requester_evidence

Link 2 wrapper (holder mode) carrying artifacts[] with provenance: holder_commissioned (§8.3.1).

evidence artifact

Unified signed-object envelope (artifact_id, provenance, source_id, kind, attestation) carried on Link 2 or in the JWE (§8.3.1).

evidence_artifacts

Array on the JWE inner payload of agent_observed artifacts relayed by the Subject Agent (§8.5.1).

evidence cross-check

Assessor step comparing verified artifacts (Link 2 and/or JWE) against Subject Agent narrative under the active policy_referential; recorded in AssessmentResult.evidence_cross_check (§8.6).

assessment_mode

Claim on AssessmentDelegation: holder (Pattern A) or direct (Pattern B).

policy_referential

Identifier for the assessment framework or regulatory standard against which the Assessor evaluates evidence.

Assessor Roster

Machine-readable catalogue published by a trust registry, listing every currently authorized Assessor agent with its public keys, assessment types, regions, and owning TA.

Hyperlab

The Innovation Lab within Consult Hyperion responsible for this specification and related ATLAS artefacts as part of the agentic commerce trust and assurance programme.

4. Roles and Participants§

5. Assessor Roster§

Each trust registry MUST expose an Assessor roster — a machine-readable, periodically updated catalogue of every Assessor agent currently authorized by any TA associated with that registry. The roster is the canonical discovery surface for ATLAS participants.

5.1 Scope§

One trust registry roster aggregates Assessors from all TAs linked to the registry. Subject agents, merchants, and credential providers use a single registry endpoint to learn who may perform which assessment types in which regions.

5.2 Per-Assessor Entry Fields§

Each roster record SHOULD include:

5.3 Publication and Trust§

The registry SHOULD sign roster snapshots or publish over HTTPS with a registry trust anchor, and SHOULD support versioning (roster_version, updated_at) and revocation. Implementations MAY expose the roster as a JSON document, REST collection, or signed JWT bundle.

5.4 Use in ATLAS Flows§

• Subject agent MAY copy jkt values from roster entries into permitted_assessors / permitted_trust_authorities when building Link 1.
• In holder mode, the merchant or CP selects an Assessor from the roster and binds the Assessor's jkt in Link 2 cnf.
• Holders and Assessors SHOULD reject commission if the Assessor's keys or authorization dates do not match the current roster entry.

6. Core Artifacts§

ATLAS defines five signed artifacts. The upstream three are compact JWS/JWT capability tokens with cryptographic key binding via cnf (RFC 7800), not W3C Verifiable Credentials.

6.1 Artifact Summary§

6.2 JWS/JWT Chain Reference§

Each link MUST be signed by the private key named in the previous link's cnf claim.

6.2.1 Holder-Mode Chain (Pattern A)

┌─────────────────────────────────────────────────────────────────────┐
│  LINK 1 — AssessmentDelegation (signed JWT)                         │
│  Subject Agent → Merchant  OR  → CP                                 │
│  typ: "atlas-assessment-delegation+jwt"  assessment_mode: holder    │
│  iss: SA   sub: merchant_id|cp_id                                   │
│  agent_cnf.jkt = Subject Agent key (signs L1 + evidence JWS)        │
│  cnf.jkt = Holder Public Key (signs Link 2)                         │
│  agent { id, registered_identities[] }                              │
│  scope, permitted_assessors, permitted_trust_authorities            │
│  transaction_reference, session_id                                  │
│  exp, nbf, jti (root — NO parent_jti)                               │
└─────────────────────────┬───────────────────────────────────────────┘
                          │ signed by key in Link 1 cnf
                          ▼
┌─────────────────────────────────────────────────────────────────────┐
│  LINK 2 — AssessmentSubDelegation (signed JWT)                      │
│  Merchant / CP → Assessor                                           │
│  typ: "atlas-assessment-subdelegation+jwt"                          │
│  iss: merchant   sub: assessor_id   aud: subject_agent              │
│  parent_jti:  scope ⊆ L1  cnf.jkt = Assessor key                │
│  requester_evidence { holder_commissioned artifacts[] }             │
│  Signed by: Holder key (MUST match Link 1 cnf)                      │
└─────────────────────────┬───────────────────────────────────────────┘
                          │ signed by Link 2 cnf + authorization
                          ▼
┌─────────────────────────────────────────────────────────────────────┐
│  LINK 3 — AssessorAccessAssertion (signed JWS)                      │
│  Assessor → Subject Agent                                           │
│  iss: assessor   aud: subject_agent                                 │
│  nonce:   (replay protection)             │
│  embedded: L1 + L2  (L2 NOT in Link 4)                              │
│  assessor_authorization: JWS signed by TA                           │
│  Signed by: Assessor key (MUST match Link 2 cnf)                    │
└─────────────────────────┬───────────────────────────────────────────┘
                          │ chain verified → evidence release
                          ▼
┌─────────────────────────────────────────────────────────────────────┐
│  AssessmentEvidenceResponse (JWE) — SA → Assessor ONLY              │
│  typ: "atlas-assessment-evidence+jwe"                               │
│  Encrypted to: Assessor key in Link 2 cnf (A256GCM)                 │
│  Payload: intent, reasoning, evidence_artifacts[] opt               │
│  agent_observed provenance (§8.5.1); NOT forwarded                  │
└─────────────────────────┬───────────────────────────────────────────┘
                          │ after evaluation
          ┌───────────────┴──────────────────┐
          ▼                                  ▼
┌─────────────────────┐   ┌───────────────────────────────────────────┐
│ LINK 4 Result       │   │ LINK 5 ReportToken                        │
│ Assessor → requester│   │ atlas:1::               │
│ compliant /         │   │ redeem_nbf … redeem_exp                   │
│ partially_compliant │   │ Signed by: Assessor / TA                  │
│ not_compliant       │   │ One token per assessment                  │
│ link2_jti,          │   │                                           │
│ requester_evidence_ │   │                                           │
│ observed_artifacts_ │   │                                           │
│ digest, report_token│   │                                           │
└─────────────────────┘   └───────────────────────────────────────────┘

6.2.2 Direct-Mode Chain (Pattern B)

In direct mode there is no Link 2: the subject agent binds the Assessor's key directly in Link 1, and the Assessor presents only Link 1 in the AssessorAccessAssertion.

┌─────────────────────────────────────────────────────────────────────┐
│  LINK 1-D — AssessmentDelegation (signed JWT)                       │
│  Subject Agent → Assessor  (direct — no holder)                     │
│  typ: "atlas-assessment-delegation+jwt"  assessment_mode: direct    │
│  iss: SA   sub: assessor_id                                         │
│  agent_cnf.jkt = Subject Agent key (signs L1 + evidence JWS)        │
│  cnf.jkt = Assessor Public Key (encrypt JWE)                        │
│  agent { id, registered_identities[] }                              │
│  scope, permitted_assessors, permitted_trust_authorities            │
│  transaction_reference, session_id                                  │
│  exp, nbf, jti (root — NO parent_jti)                               │
└─────────────────────────┬───────────────────────────────────────────┘
                          │ signed by key in Link 1-D cnf
                          │ (no Link 2)
                          ▼
┌─────────────────────────────────────────────────────────────────────┐
│  LINK 3 — AssessorAccessAssertion (signed JWS)  NO L2               │
│  Assessor → Subject Agent                                           │
│  iss: assessor   aud: subject_agent                                 │
│  nonce:   (replay protection)             │
│  embedded: L1-D ONLY                                                │
│  assessor_authorization: JWS signed by TA                           │
│  Signed by: Assessor key (MUST match Link 1-D cnf)                  │
└─────────────────────────┬───────────────────────────────────────────┘
                          │ chain verified → evidence release
                          ▼
┌─────────────────────────────────────────────────────────────────────┐
│  AssessmentEvidenceResponse (JWE) — SA → Assessor ONLY              │
│  typ: "atlas-assessment-evidence+jwe"                               │
│  Encrypted to: Assessor key in Link 1-D cnf (A256GCM)               │
│  Payload: intent, reasoning, evidence_artifacts[]                   │
│  agent_observed carts/mandates (§8.5.1); NOT forwarded              │
└─────────────────────────┬───────────────────────────────────────────┘
                          │ after evaluation
          ┌───────────────┴──────────────────┐
          ▼                                  ▼
┌─────────────────────┐   ┌───────────────────────────────────────────┐
│ LINK 4 Result       │   │ LINK 5 ReportToken                        │
│ Assessor → SA       │   │ atlas:1::               │
│ compliant /         │   │ redeem_nbf … redeem_exp                   │
│ partially_compliant │   │ Signed by: Assessor / TA                  │
│ not_compliant       │   │ One token per assessment                  │
│ observed_artifacts_ │   │                                           │
│ digest, report_token│   │                                           │
└─────────────────────┘   └───────────────────────────────────────────┘

6.2.3 Signing Chain at a Glance

7. Assessment Initiation Patterns§

7.1 Pattern A — Holder Mode§

The subject agent issues AssessmentDelegation to a merchant or CP during negotiation. The holder selects an eligible Assessor and issues a chained AssessmentSubDelegation. Each delegation is independent — the merchant and CP may each commission different Assessors.

7.2 Pattern B — Direct Mode§

The subject agent commissions an assessment for its own behaviour — for self-compliance, regulatory evidence, or pre-dispute attestation. There is no merchant and no Link 2; counterparty artifacts are carried in the JWE as agent_observed evidence (§8.5.1).

8. Protocol Steps§

All interactions are between server-side agents over HTTPS with server TLS. There is no human in the ATLAS protocol loop. Application trust is entirely in the signed-token chain.

8.1 Step 1 — Assessment Delegation Issuance (Holder Mode)§

The subject agent issues two independent AssessmentDelegation tokens during negotiation — one to the merchant (bound to merchant key and checkout artifacts) and one to the CP (bound to CP key and payment artifacts).

Assessor eligibility constraints

Agent identity (agent + agent_cnf)

Link 1 MUST carry two distinct identity bindings: agent_cnf (cryptographic) and agent (metadata). Together they name the Subject Agent that signed the token in a scheme-agnostic way: a small ATLAS-native core every implementation understands, plus optional fields for external identity frameworks (KYA-OS today; AP2 agent binding or others tomorrow) without changing the Link 1 JWT shape or the downstream signing chain.

agent_cnf (cryptographic binding)

Verifiers MUST confirm that the JWS signature on Link 1 was produced by the key identified in agent_cnf.jkt before evaluating holder constraints or releasing evidence. iss on Link 1 SHOULD equal agent.id.

agent object (metadata)

registered_identities[] entry

Each element names how the same Subject Agent is registered in a payment network, scheme, or external directory. Only agent_cnf is the signing key; registered identities are for lookup, routing, and policy evaluation only.

Attestation wrapper (optional)

When an external framework supplies richer identity or delegation proof, Link 1 carries it inside agent.attestation without mandating a single credential format:

Implementations MAY defer fetching by-reference attestations until evidence release (§8.5) or Assessor evaluation (§8.6), but MUST fail closed when a mandated policy_referential requires attestation verification and the attestation is missing, invalid, or revoked.

Registered scheme profiles (informative)

Example — ATLAS-native profile

{
  "typ": "atlas-assessment-delegation+jwt",
  "iss": "https://agent.shop.example/checkout-v2",
  "sub": "merchant_42",
  "assessment_mode": "holder",
  "agent_cnf": { "jkt": "sha256-SubjectAgentKeyThumbprint..." },
  "cnf": { "jkt": "sha256-HolderKeyThumbprint..." },
  "agent": {
    "id": "https://agent.shop.example/checkout-v2",
    "registered_identities": [
      {
        "scheme": "https://network.example/agent-registry/v1",
        "registered_id": "AGT-8842"
      }
    ]
  },
  "scope": ["intent_fidelity"],
  "transaction_reference": "txn_9f3a...",
  "jti": "l1_01HZ..."
}

Example — KYA-OS profile (by reference)

{
  "iss": "did:web:shop.example/agents/checkout",
  "sub": "merchant_42",
  "assessment_mode": "holder",
  "agent_cnf": { "jkt": "sha256-SubjectAgentKeyThumbprint..." },
  "cnf": { "jkt": "sha256-HolderKeyThumbprint..." },
  "agent": {
    "id": "did:web:shop.example/agents/checkout",
    "scheme": "https://schema.kya-os.org/v1/agent-identity",
    "scheme_version": "1.0.0",
    "authority": { "id": "did:web:shop.example" },
    "attestation": {
      "form": "by-reference",
      "media_type": "application/vc+json",
      "uri": "https://registry.shop.example/vc/urn:uuid:8f14e45f...",
      "digest": {
        "alg": "sha-256",
        "value": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855"
      }
    },
    "extensions": {
      "kya_conformance_level": 2
    }
  }
}

8.2 Step 1b — Direct Assessment Commission§

assessment_mode MUST be direct; sub MUST be the assessor identifier; cnf.jkt MUST be the assessor's public key. agent_cnf and agent MUST be present as defined in §8.1.1. No merchant cnf and no Link 2. Counterparty evidence (carts, mandates) MUST be relayed by the Subject Agent in evidence_artifacts[] with provenance: agent_observed inside the JWE (§8.5.1) when required by the active policy_referential.

8.3 Step 2 — Sub-Delegation and Assessment Commission (Holder Mode Only)§

The holder issues a chained AssessmentSubDelegation, signed with the holder's key matching the parent cnf, that names the Assessor as sub, binds the assessor's key in cnf, references the parent via parent_jti, and narrows or equals the parent scope.

1. Verify subject-agent signature on parent token (iss, exp, nbf, jti).
2. Verify holder signature on sub-delegation matches parent cnf.
3. Verify merchant identity matches parent sub.
4. Verify own signing key matches sub-delegation cnf.
5. Verify eligibility under permitted_assessors / permitted_trust_authorities and optional filters.
6. Verify sub-delegation scope ⊆ parent scope.
7. Verify replay protection on jti.
8. If requester_evidence is present, verify each artifact per §8.3.1 before forwarding Link 2 to the Subject Agent in the assertion chain.

Evidence artifacts (shared model)

ATLAS uses one evidence-artifact shape for carts, mandates, and other signed checkout objects. Each artifact is carried in exactly one of two places, identified by provenance:

The same kind, scheme, and attestation vocabulary applies in both carriages. In holder mode, dispute-grade cross-check SHOULD prefer holder_commissioned artifacts on Link 2 when present. In direct mode, counterparty material MUST use agent_observed in the JWE — there is no Link 2.

Evidence artifact (normative fields)

Verifiers MUST confirm that provenance matches the carriage location (Link 2 vs JWE). The Assessor MUST verify each artifact's cryptographic integrity and source_id signature per kind / scheme regardless of provenance.

Holder carriage — requester_evidence (Link 2, holder mode)

When a holder commissions an assessment, Link 2 MAY include requester_evidence — a wrapper whose artifacts[] entries MUST each carry provenance: holder_commissioned.

The holder MUST sign Link 2 over the entire JWT payload including requester_evidence.

Registered artifact kinds (informative)

Example — holder mode (merchant cart + CP mandate, two Link 2 tokens)

{
  "typ": "atlas-assessment-subdelegation+jwt",
  "iss": "https://merchant.example",
  "sub": "assessor_42",
  "aud": "https://agent.shop.example/checkout-v2",
  "parent_jti": "l1_01HZ...",
  "cnf": { "jkt": "sha256-AssessorKeyThumbprint..." },
  "scope": ["intent_fidelity", "regulated_goods"],
  "requester_evidence": {
    "requester_id": "https://merchant.example",
    "requester_role": "merchant",
    "artifacts": [
      {
        "artifact_id": "cart-001",
        "provenance": "holder_commissioned",
        "source_id": "https://merchant.example",
        "source_role": "merchant",
        "kind": "https://atlas.hyperlab.dev/evidence/cart/v1",
        "scheme": "https://ucp.dev/cart/v1",
        "attestation": {
          "form": "by-value",
          "media_type": "application/jose+json",
          "payload": "eyJ...merchant-signed-cart-jws..."
        }
      }
    ]
  }
}

{
  "iss": "https://cp.wallet.example",
  "requester_evidence": {
    "requester_id": "https://cp.wallet.example",
    "requester_role": "credential_provider",
    "artifacts": [
      {
        "artifact_id": "mandate-001",
        "provenance": "holder_commissioned",
        "source_id": "https://cp.wallet.example",
        "source_role": "credential_provider",
        "kind": "https://ap2.dev/evidence/payment-mandate/v1",
        "scheme": "https://ap2.dev/payment-mandate/v1",
        "attestation": {
          "form": "by-reference",
          "media_type": "application/json",
          "uri": "https://cp.wallet.example/mandates/mand_abc",
          "digest": {
            "alg": "sha-256",
            "value": "K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols="
          }
        },
        "extensions": { "mandate_id": "mand_abc" }
      }
    ]
  }
}

8.4 Step 3 — Assessor Access Assertion to Subject Agent§

the Assessor sends an AssessorAccessAssertion — a signed JWS wrapping the delegation chain plus authorization, signed over a fresh nonce from the subject agent.

Holder-mode verification checklist

Scope for JWE release: sub-delegation scope (holder) / Link 1 scope (direct).

8.5 Step 4 — Assessment Evidence Response§

1. Build JSON payload scoped per Link 2 scope (holder) or Link 1 scope (direct), filtered server-side before encryption.
2. Encrypt to assessor public key in Link 2 cnf (holder) or Link 1 cnf (direct).
3. Algorithms: ECDH-ES or RSA-OAEP for key encryption; A256GCM for content encryption.
4. Nest a Subject-Agent-signed inner JWS inside the JWE (MUST); signature key MUST match agent_cnf.jkt on Link 1.
5. No other party receives this JWE — not the merchant, CP, network, or TA.

Minimum payload: user's natural-language intent + agent reasoning leading to merchant/item selection. Additional categories when in scope: intent_summary, constraint_set, merchant_selection_reasoning, item_selection_reasoning, policy_evaluation_results, evidence_hashes, evidence_artifacts[] for counterparty material the Subject Agent observed (§8.5.1). Legacy transaction_artifact_refs SHOULD NOT be used when a full evidence artifact is available.

Subject Agent evidence package (JWE inner payload)

The inner JWS payload (before encryption) MUST include the Subject Agent narrative fields below and MAY include evidence_artifacts[] — the same artifact model as §8.3.1 with provenance: agent_observed only.

In direct mode, when the policy_referential requires cart or mandate cross-check, the Subject Agent MUST include the corresponding evidence_artifacts (by-value or by-reference with digest). The Assessor MUST verify each source_id signature and perform evidence_cross_check (§8.6). In holder mode, the SA MAY include agent_observed copies for convenience; when the same artifact_id appears on Link 2 as holder_commissioned, the Assessor SHOULD treat the Link 2 copy as authoritative for dispute-grade cross-check.

Prefer attestation.form: by-reference with digest for large carts and mandates; use by-value when the artifact is small or the Assessor cannot reach the uri.

Example — direct mode JWE inner payload (Pattern B)

{
  "typ": "atlas-assessment-evidence+jws",
  "transaction_reference": "txn_9f3a2b1c",
  "intent_summary": "Organic groceries under €80, delivery Tuesday",
  "merchant_selection_reasoning": "Chose merchant.example — shortest delivery slot",
  "item_selection_reasoning": "3 line items; substituted almond milk per user preference",
  "evidence_artifacts": [
    {
      "artifact_id": "cart-001",
      "provenance": "agent_observed",
      "source_id": "https://merchant.example",
      "source_role": "merchant",
      "kind": "https://atlas.hyperlab.dev/evidence/cart/v1",
      "scheme": "https://ucp.dev/cart/v1",
      "attestation": {
        "form": "by-value",
        "media_type": "application/jose+json",
        "payload": "eyJ...merchant-signed-cart-jws..."
      }
    },
    {
      "artifact_id": "mandate-001",
      "provenance": "agent_observed",
      "source_id": "https://cp.wallet.example",
      "source_role": "credential_provider",
      "kind": "https://ap2.dev/evidence/payment-mandate/v1",
      "attestation": {
        "form": "by-reference",
        "media_type": "application/json",
        "uri": "https://cp.wallet.example/mandates/mand_abc",
        "digest": {
          "alg": "sha-256",
          "value": "K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols="
        }
      },
      "extensions": { "mandate_state": "open" }
    }
  ]
}

8.6 Step 5 — Assessment Result Issuance§

AssessmentResult is addressed to the merchant/CP (holder mode) or to the subject agent (direct mode). The requester MUST convey the full signed AssessmentResult peer-to-peer until the merchant processor holds every result for that transaction_reference.

Link 4 structure and evidence digests

AssessmentResult (Link 4) is a compact, forwardable verdict envelope. In holder mode, Link 2 is embedded in Link 3 so the Subject Agent can verify the delegation chain before releasing evidence. Link 4 MUST NOT embed Link 2 or raw artifact payloads — only digests and enumerated findings.

Holder mode: when requester_evidence was present, Link 4 SHOULD carry link2_jti and requester_evidence_digest. Direct mode: when evidence_artifacts[] was evaluated, Link 4 SHOULD carry observed_artifacts_digest and agent_evidence_digest.

Evidence cross-check (both patterns)

When verified artifacts exist — holder_commissioned on Link 2 and/or agent_observed in the JWE — the Assessor SHOULD compare each artifact against the Subject Agent narrative (e.g. cart lines vs. item_selection_reasoning; mandate limits vs. checkout actions). In holder mode, when the same artifact_id appears in both carriages, the holder_commissioned copy SHOULD take precedence for dispute-grade findings. The outcome is recorded in evidence_cross_check:

Digests belong at Link 4 top level (table above). evidence_cross_check carries only the enumerated evaluation outcome.

A material_mismatch SHOULD yield not_compliant or partially_compliant per the active policy_referential. The Assessor MUST NOT include raw artifact payloads or decrypted agent evidence in AssessmentResult.

8.7 Step 6 — Downstream Report Redemption§

The merchant processor collects conveyed AssessmentResult payloads, extracts report_token from each, and writes an ordered redeem_tokens list (max 3 entries) into the payment message. The TA MUST reject redemption outside [redeem_nbf, redeem_exp] and MAY enforce one-time redemption via jti tracking.

Each report_token is a compact opaque handle (Link 5), typically atlas:1:<ta_id>:<report_id>. The token carries no TA report API endpoint — the payment network resolves ta_id via the scheme Trust Registry (ta_report_api) before calling GET /report/{token}.

redeem_tokens assembly (processor)

After verifying each conveyed AssessmentResult, the processor builds redeem_tokens in assessment order (merchant, then CP, then subject-agent direct assessment if present), up to three entries:

{
  "version": 1,
  "transaction_reference": "txn_9f3a2b1c",
  "tokens": [
    "atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Y",
    "atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Z"
  ]
}

Source AssessmentResult fragments (Link 4) from which the above was extracted:

{
  "typ": "atlas-assessment-result+jws",
  "iss": "https://assessor.example/agents/assessor-42",
  "sub": "https://merchant.example",
  "result": "compliant",
  "transaction_reference": "txn_9f3a2b1c",
  "link2_jti": "l2_01HZXK9Q4M2N8W3Y",
  "report_token": "atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Y",
  "redeem_nbf": 1752043200,
  "redeem_exp": 1752046800,
  "jti": "l4_01HZXK9Q4M2N8W3Y"
}

ISO 8583 example (informative)

A compact report_token (Link 5) may be carried on ISO 8583 authorisation messages (e.g. MTI 0100) in DE 48 or another scheme-defined private-use data element.

ISO 8583 compliance

Recommended ATLAS wire profile for 8583: a delimiter-separated list of one to three tokens inside one scheme-registered subelement, or one subelement per token when the network caps subelement length at 99 bytes. Order matches §8.7.1 (merchant assessment, CP assessment, subject-agent direct assessment if present). Scheme profiles SHOULD cap each report_token at 64 characters and ta_id at 32 characters so three tokens remain comfortably inside DE 48 even on strict networks.

MTI 0100 — Authorisation Request (acquirer → network)

DE 003  Processing Code     : 000000
DE 004  Amount, Transaction : 000000001250        (12.50 EUR)
DE 011  STAN                : 004821
DE 037  Retrieval Ref Nbr   : 923041004821
DE 041  Card Acceptor Term  : TERM0001
DE 042  Card Acceptor ID    : MERCHANT42
DE 048  Additional Data — Private (LLLVAR, max 999 bytes value):
        LLL = 097
        Value = [scheme subelement chain]
          SE/PDS ATLAS (scheme-assigned id, NOT EMV 9Fxx):
            Len = 097
            Data = atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Y|atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Z
DE 049  Currency Code       : 978

Alternative when subelement length is capped at 99 bytes (use one SE per token):
          SE ATLAS.01  Len = 048  Data = atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Y
          SE ATLAS.02  Len = 048  Data = atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Z

Notes:
- LLL is the 3-digit (or 2-byte BCD) length of the entire DE 048 value — not repeated per sub-tag.
- Inner Len encoding (1, 2, or 3 digits; BCD vs ASCII) is scheme-defined.
- Delimiter | is scheme-defined; forbidden if profile uses strict an-only — then use per-token subelements with no separator.
- version and transaction_reference stay in Link 4 / processor context unless another DE carries them.
- Networks on strict an-only DE 048 may use DE 062/063 (often ans ...999) or binary-encode the TLV value.

ISO 20022 example (informative)

For account-to-account and modern card-authorisation messages, schemes typically embed ATLAS tokens in SplmtryData (supplementary data) using a registered place-and-name and a scheme-defined envelope. Below: fragment of pacs.008.001.08 (FI to FI Customer Credit Transfer) with an ATLAS extension; the same pattern applies to auth.001 / camt authorisation profiles where the scheme carries checkout metadata.

<FIToFICstmrCdtTrf>
  ...
  <SplmtryData>
    <PlcAndNm>ATLAS.RedeemTokens</PlcAndNm>
    <Envlp>
      <Document xmlns="https://atlas.hyperlab.dev/rail/redeem/v1">
        <RedeemTokens version="1">
          <TransactionReference>txn_9f3a2b1c</TransactionReference>
          <Token>atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Y</Token>
          <Token>atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Z</Token>
        </RedeemTokens>
      </Document>
    </Envlp>
  </SplmtryData>
</FIToFICstmrCdtTrf>

Equivalent JSON-in-Envlp (when the scheme profile uses JSON supplementary payloads):

{
  "version": 1,
  "transaction_reference": "txn_9f3a2b1c",
  "tokens": [
    "atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Y",
    "atlas:1:ta.hyperlab.example:rpt_01HZXK9Q4M2N8W3Z"
  ]
}

9. Trust Chain Summary§

10. End-to-End Sequence§

The diagrams below show the complete message flows for each assessment initiation pattern, including Trust Registry API discovery and the downstream path from the payment network to the trust authority.

10.1 Pattern A — Holder Mode§

The subject agent delegates assessment authority to the merchant and CP (holders), who each independently select an eligible Assessor from the Trust Registry and issue Link 2. The payment network redeems the ReportToken from the trust authority and uses the resulting stored report as an additional trust signal in the authorisation decision.

sequenceDiagram
    autonumber
    participant U  as User
    participant SA as Subject Agent
    participant R  as Trust Registry API
    participant M  as Merchant / CP
    participant A  as Assessor Agent
    participant MP as Merchant Processor
    participant N  as Payment Network / Issuer
    participant TA as Trust Authority

    U->>SA: Natural-language intent (constraints, budget, preferences)

    SA->>R: GET /roster — discover eligible Assessors + TA trust anchors
    R-->>SA: Assessor entries (keys, TA, regions, assessment types)

    SA->>M: AssessmentDelegation L1 [assessment_mode:holder, cnf = M key]
    SA->>M: AssessmentDelegation L1 [assessment_mode:holder, cnf = CP key]

    M->>R: GET /roster — verify Assessor eligibility
    R-->>M: Eligible Assessor entries

    M->>A: AssessmentSubDelegation L2 [parent_jti=L1, cnf = A key, scope ⊆ L1]
    note over M,A: Merchant AND CP may each commission different Assessors

    A->>SA: AssessorAccessAssertion L3 [chain L1+L2 + authorization, nonce]
    SA->>A: AssessmentEvidenceResponse JWE [encrypted intent + reasoning — A only]

    A->>M: AssessmentResult L4 + ReportToken L5
    note over M: AssessmentResult MAY be used during negotiation
(e.g. UCP checkout offer, pricing, terms)
    M->>SA: convey AssessmentResult
    note over MP: MP performs risk analysis on AssessmentResult 
extracts report_token and assembles redeem_tokens
field carried within existing ISO 8583 / ISO 20022 rails
    M->>MP: convey AssessmentResult
    
    MP->>N: Payment authorisation + redeem_tokens [ISO 8583 / EMV 3DS / ISO 20022]
    N->>TA: Redeem ReportToken [GET /report/{token}]
    TA-->N: Certified trust-assurance report
    N-->>MP: Authorisation decision (+ ATLAS trust signal)
    

U   ──intent─────────────────────────────────────────────► SA
SA  ──GET /roster────────────────────────────────────────► Roster
SA  ──AssessmentDelegation L1 (holder, cnf=M)─────────────────► M
SA  ──AssessmentDelegation L1 (holder, cnf=CP)────────────────► CP
M   ──GET /roster (verify A eligibility)─────────────────► Roster
M   ──AssessmentSubDelegation L2 (cnf=A key)──────────────────► A
CP  ──AssessmentSubDelegation L2 (cnf=A key)──────────────────► A
A   ──AssessorAccessAssertion L3 (chain + authorization)────► SA
SA  ──AssessmentEvidenceResponse JWE (intent + reasoning)─────► A
A   ──AssessmentResult L4 + ReportToken L5──────────────────► M / CP
M   ──convey AssessmentResult─────────────────────────────────► SA, CP, MP
MP  ──payment auth + redeem_tokens (ISO 8583 / 3DS)──────► N
N   ──redeem ReportToken───────────────────────────────► TA
TA  ──stored trust-assurance report───────────────────► N
N   ──authorisation decision (+ ATLAS trust signal)───────► MP

10.2 Pattern B — Direct Mode§

The subject agent self-commissions the assessment — there is no merchant holder and no Link 2. The agent conveys the AssessmentResult directly to downstream parties. The payment network still redeems the ReportToken from the trust authority to obtain an independent stored report.

sequenceDiagram
    autonumber
    participant U  as User
    participant SA as Subject Agent
    participant R  as Trust Registry API
    participant A  as Assessor Agent
    participant MP as Merchant Processor
    participant N  as Payment Network / Issuer
    participant TA as Trust Authority

    U->>SA: Natural-language intent (constraints, budget, preferences)

    SA->>R: GET /roster — direct-mode eligible Assessors
    R-->>SA: Eligible Assessor entries (keys, TA, regions)

    SA->>A: AssessmentDelegation L1-D [assessment_mode:direct, cnf = A key]
    note over SA,A: No Link 2 — Assessor bound directly in L1-D cnf

    A->>SA: AssessorAccessAssertion L3 [L1-D only + authorization, nonce]
    SA->>A: AssessmentEvidenceResponse JWE [encrypted intent + reasoning — A only]

    A->>SA: AssessmentResult L4 + ReportToken L5
    SA->>MP: convey AssessmentResult [via M / CP]

    MP->>N: Payment authorisation + redeem_tokens [ISO 8583 / EMV 3DS / ISO 20022]
    N->>TA: Redeem ReportToken [GET /report/{token}]
    TA-->N: Certified trust-assurance report
    N-->>MP: Authorisation decision (+ ATLAS trust signal)
    

U   ──intent─────────────────────────────────────────────► SA
SA  ──GET /roster (direct-mode eligible Assessors)────────► Roster
SA  ──AssessmentDelegation L1-D (assessment_mode:direct, cnf=A)────► A
A   ──AssessorAccessAssertion L3 (L1-D only)────────────────► SA
SA  ──AssessmentEvidenceResponse JWE (intent + reasoning)─────► A
A   ──AssessmentResult L4 + ReportToken L5──────────────────► SA
SA  ──convey AssessmentResult─────────────────────────────────► M, CP, MP
MP  ──payment auth + redeem_tokens (ISO 8583 / 3DS)──────► N
N   ──redeem ReportToken───────────────────────────────► TA
TA  ──stored trust-assurance report───────────────────► N
N   ──authorisation decision (+ ATLAS trust signal)───────► MP

11. Security and Privacy Requirements§

11.1 Security Design Principles§

11.2 Normative Controls§

• All delegation and result artifacts MUST use asymmetric signatures (e.g. ES256, EdDSA). MUST prohibit none and deprecated HMAC-as-JWT.
• Every JWT MUST include exp, nbf, and unique jti. Verifiers MUST reject expired or reused jti.
• aud and iss MUST be validated on every presentation.
• Link 2 scope MUST be a subset of Link 1 scope.
• The SA MUST issue a fresh, single-use nonce for each AssessorAccessAssertion request.
• Any agent receiving a conveyed AssessmentResult MUST verify the Assessor signature, transaction_reference, assessment_id, and requester_id.
• The merchant processor MUST NOT mint tokens or accept results without the signed envelope.

11.3 Privacy§

• User intent and agent reasoning MUST use JWE to Link 2/1 cnf only.
• Merchants, CPs, and TAs MUST NOT receive AssessmentEvidenceResponse or decrypted evidence in the base profile.
• Do not log decrypted evidence in production; log assessment_id and hashes only.

11.4 Transport§

HTTPS with TLS 1.2+ (1.3 preferred); certificate validation enabled. Application trust does not rely on mTLS or DPoP in the base profile.

11.5 Downstream Redemption — Accepted Model and Risks§

11.6 Threat-Model Checklist (Implementers)§

• ☐ Compromised merchant issues L2 to colluding Assessor → contained by SA verification at §8.4 and permitted_* on L1.
• ☐ Compromised Assessor requests excessive scope → contained by scope ⊆ parent and SA filter before JWE.
• ☐ Compromised SA over-releases evidence → contained by scope; inner JWS + TA assessment trail.
• ☐ Replay of assertion or delegation → jti, nonce, short exp.
• ☐ Forged conveyed AssessmentResult → mandatory signature verification at processor and peers.
• ☐ Stale roster / revoked Assessor → authorization credential + optional revocation list.

12. Alignment with AP2, Verifiable Intent, and UCP§

ATLAS is complementary to AP2: AP2 defines mandate delegation, action authorisation, verifier checks, and receipts; ATLAS adds a standard path for assessing how the subject agent interpreted and operationalised the user's intent before and during those actions. In holder mode, the CP or merchant MAY attach holder_commissioned artifacts on Link 2 (requester_evidence, §8.3.1). In direct mode, the Subject Agent relays counterparty material as agent_observed artifacts in the JWE (§8.5.1). The Assessor cross-checks verified artifacts against Subject Agent narrative without exposing private reasoning to the requester.

ATLAS borrows the principles of Verifiable Intent — key-bound credentials, audience restriction, chained authority — but uses chained capability tokens (JWS/JWT with cnf per RFC 7800) rather than W3C VC/VP envelopes. There is no human verifier in the loop, so selective-disclosure cryptography and credential portability are not needed. Implementations that already deploy VI MAY wrap ATLAS tokens inside VI presentations at payment boundaries.

UCP defines the end-to-end commerce lifecycle — from offer negotiation through checkout completion. ATLAS attaches to that lifecycle at two points: during negotiation, where an AssessmentResult may influence offer terms, and at completion, where the ReportToken travels with the payment authorisation message. The FACT implementation has already demonstrated that merchant-to-Assessor invocation works within UCP's negotiation phase; ATLAS formalises that proven pattern into a portable, scheme-agnostic protocol.

13. Proposed Standard Text Seed§

ATLAS defines a chained-capability-token assessment framework for agentic commerce with two initiation patterns. A trust registry publishes an Assessor roster listing every authorized Assessor agent from all TAs under the registry, including Assessor and TA public keys (jkt), assessment types, regions, authorization dates, and TA association.

In holder mode, the subject agent issues AssessmentDelegation (assessment_mode: holder) to the merchant and CP; a holder commissions an assessment via AssessmentSubDelegation to an eligible Assessor. In direct mode, the subject agent issues AssessmentDelegation (assessment_mode: direct) straight to an Assessor — no merchant and no Link 2. In both modes the Assessor presents an AssessorAccessAssertion; the SA verifies the chain and returns AssessmentEvidenceResponse as JWE. the Assessor returns AssessmentResult with one report_token. Each result is conveyed peer-to-peer until the merchant processor collects them, extracts report_token values (up to three), and writes redeem_tokens on ISO 8583 and similar rails. Application trust is chained JWS/JWT plus JWE over HTTPS with standard TLS.

14. FAQ§

Common questions about ATLAS — what it is, why it is proposed as a FIDO standard, how it relates to KYA-OS / AP2 / VI, Assessor discovery and opt-in, multi-Assessor use, and benefits by market segment — are answered in the companion FAQ:

ATLAS — FAQ (https://github.com/HYPERLAB-FIME/ATLAS-PUBLIC/blob/main/FAQ.md)

References§

Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. URL: https://www.rfc-editor.org/rfc/rfc2119

[RFC7515]

Jones, M. et al., "JSON Web Signature (JWS)", RFC 7515, May 2015.

[RFC7516]

Jones, M. et al., "JSON Web Encryption (JWE)", RFC 7516, May 2015.

[RFC7519]

Jones, M. et al., "JSON Web Token (JWT)", RFC 7519, May 2015.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, September 2015.

[RFC7800]

Jones, M. et al., "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, April 2016.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

[RFC8693]

Jones, M. et al., "OAuth 2.0 Token Exchange", RFC 8693, January 2020.

Informative References

[AP2]

Agentic Payment Protocol v2. Fido.

[VI]

Verifiable Intent. Fido.

[UCP]

Universal Commerce Protocol. Google.

[ISO-8583]

ISO/IEC 8583, "Financial transaction card originated messages".

[EMV-3DS]

EMVCo, "EMV® 3-D Secure Protocol and Core Functions Specification".

[ISO-20022]

ISO 20022, "Universal financial industry message scheme", ISO/TC 68.

[ATLAS-FAQ]

ATLAS — FAQ. Hyperlab / Consult Hyperion. URL: https://github.com/HYPERLAB-FIME/ATLAS-PUBLIC/blob/main/FAQ.md