VXP specification

1Introduction#

VXP is an open standard for work that personal agents do for people inside companies. Any company or developer can implement it without hiring SOVRAS and without using Poppy or PACT. It has its own profile (§8, experimental) and interoperates with Poppy and PACT through adapters.

VXP has two public components, each a contract with a format on the wire:

VXP also states operation requirements (§9): the behaviour every conforming implementation shows where an external request becomes an operation, such as executing only the exact revision that was approved, and only once. They are requirements, not a third component: VXP defines no interface for them, VXP Proof is how anyone outside can check they were met, and how an implementation enforces them inside is its own decision.

Prior art#

These techniques have precedents in Poppy operations, in payments and in 2026 IETF drafts: Schrock outcome-binding, Dogru Cedulon, and the AUDIT group being formed. VXP combines them in its contracts, with its own profile and adapters to Poppy and PACT.

Conventions#

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in capitals.

• Normative text is the contract. Each requirement carries an identifier: I1 to I5, ID1 to ID3, E1 to E3, R1 to R17, P1 to P8 and O1 to O7.
• Informative blocks describe the reference implementation by SOVRAS: its paths, storage and internal controls. They show one way to meet the contract and add no requirement.
• Experimental marks parts that pass their tests and that no third-party agent uses yet.
• Pending marks parts that are specified or announced and not yet done.

VXP Proof inherits its statement format, canonicalization, chain, levels, log and anchoring from §9 of the normative annex, the VXP design draft 0.1. That annex passed five rounds of critical review, each with its corrections. Identifiers the annex names with “sovras” are used as listed in Renamed identifiers.

2Why VXP exists#

Every day, companies sell, book, change deliveries and handle incidents inside their own systems. VXP comes from that work at SOVRAS, which builds agents that change orders, deliveries and reservations inside companies' systems. After each of those operations, the same questions come back:

1. Who asked, and on whose behalf?
2. Which exact terms did the person approve, and through which channel?
3. What ran, and how many times?
4. What did the company's system record afterwards?

When the request comes from a person's own agent, the company did not build that agent and cannot see its conversation. The answers have to travel with the operation. VXP writes them into contracts that any company and any agent can implement.

3Principles and scope#

The table says what kind of part each one is. Only the first four bind an implementation; adapters are optional, and implementation decisions bind no one.

Principles#

• An external protocol is spoken as it is written (I1).
• Whatever the entry, one enterprise execution per resource (I2).
• A channel identifier, a customer account and a delegation stay separate (§5).
• What is not known is signed as unknown (P3).
• The verifier derives the level of evidence; the issuer never declares it (P7).

Out of scope#

• Payments: referenced (AP2, x402, Pix), not defined.
• Agent identity and user sign-in: they belong to Poppy, PACT and OAuth.
• Disputes and their resolution: each company's policy.
• Proof that the person read something: the most that is proven is that they answered from the linked channel.

4Architecture#

Several entries end in one normalized request, the operation requirements and one enterprise execution. VXP Proof and VXP Relationship come out of it. Diagrams of each part are in Architecture.

Personal agent (VXP native, experimental · Poppy · PACT · traditional channel)
        │
                ├── VXP native (EXPERIMENTAL): /.well-known/vxp.json + /v1
        ├── Poppy ── optional adapter (Poppy draft 0.2 contract, literal)
        ├── PACT ─── optional A2A adapter (PACT 1.0 contract, literal)
        └── WhatsApp · web chat · voice ── channels of one implementation, outside VXP
        │
   Normalized operational request
   (identity · authority · company · operation · correlation)
        │
      Operation requirements (§9), enforced by the implementation's own controls
        │
   one enterprise execution → read of the system
        │
   VXP Proof (signed chain)     VXP Relationship (agreements, signed outbound)

Interoperability rules#

States: one internal model, each protocol's own enum outside#

Legal transitions

Any other transition MUST be rejected.

Projection

In each profile the visible state MUST be the projection of the internal one, and a value outside that profile's enum MUST NOT be used. Under A2A and PACT, the internal state MUST travel in metadata["https://vxpprotocol.org/ext/native/v0.1"] as {"state", "a2a_state"}; under Poppy it MUST NOT go in the operation's state.

• The state MUST NOT move to failed while it is not known whether the effect happened. That is pending_verification.
• A read by the agent MUST NOT change the state by itself. It MAY trigger reconciliation against the system of record, and reconciliation MUST NOT repeat the action.

5Identity model#

Three different things that MUST NOT be merged:

6VXP Proof#

Each operation produces a chain of signed statements. Each statement names the previous one by its digest, and is signed by the role that observed it: the company signs what it offers and what it asserts as the result; the operator signs what it received, what it executed and what it read back. A verifier therefore knows who said what at each link.

Format#

• Serialization: one SD-JWT per statement (RFC 9901 §4), signed with ES256, without a Key Binding JWT in 0.1. Header {"alg":"ES256","kid":"<RFC 7638 thumbprint>","typ":"vxp-stmt+sd-jwt"}.
• Canonical bytes: the payload MUST be exactly its JCS form (RFC 8785, integers only, amounts as strings), and every base64url segment MUST be canonical.
• Common members: v, kind, iss, company, op, seq, prev, iat, aud (the agent's client_id), user (a per-company pseudonym) and body.
• Digest of a statement: SHA-256 over the JWS signing input, header and payload, without the signature and without disclosures.
• Digest of terms: the digest of {company, operation_id, revision, summary, terms, expires_at, user_approval_required}. terms MUST carry a fresh vxp_salt of at least 128 bits in each revision.
• Personal data travels as selective disclosures, never in clear.

Statement kinds#

Chain rules#

A verifier MUST check these in order, for each seq; the first failure decides the error code and its seq. Two conforming verifiers MUST return the same verdict on any chain.

1. SD-JWT format, canonical base64url, header, known kid for the iss, valid signature.
2. Canonical payload.
3. kind allowed for the signer's role.
4. SD-JWT processing as in RFC 9901 §7.1.
5. v, company, op, aud and user equal across the chain.
6. seq without gaps and prev equal to the digest of the previous statement.
7. After a final statement, only read_back, correction and revocation.
8. Semantic order by kind: one approval of the latest revision, one execution after it, succeeded only after a matching system read-back.
9. There is an outcome; a package without one is treated as unknown.

Rules P1 to P8#

Approval through the company's channel#

A user_approval records one of two methods:

• The outgoing message MUST name the company and the requesting agent, and carry the revision's summary and its display_code.
• The channel is whichever one the company has linked to the user: a messaging line, email, its own app. display_code is the first four bytes of SHA-256 over the UTF-8 terms_digest, read as an unsigned big-endian integer, modulo 1 000 000, padded to six digits. It is not a secret: it ties an answer to one revision.
• The answer MUST come from the identifier linked to the user at the company, contain the display_code, be single-use and arrive before expires_at. The operator MUST limit attempts.
• A message that could not be delivered approves nothing: the operation MUST stay proposed and MUST NOT run.
• Under PACT every write MUST require company_channel.

Corrections and revocations#

A final state never changes. Later facts live in the chain and never rewrite it. A statement is never edited or deleted.

• correction: {corrects, state, reason, note_digest?, read_back?}. corrects always points to the latest final statement, and its state becomes the current state for the verifier.
• revocation: {revokes, reason}, when the referred statement was wrong. The verifier reports final_state: "revoked".

7VXP Relationship#

A relationship lets a company start a request toward the person's agent, within an agreement the person approved first. It always starts from a prior authorization by the user.

Birth#

The agent asks for the relationship in the Device Authorization (RFC 8628), with an authorization_details entry (RFC 9396) of this type:

{ "type": "https://vxpprotocol.org/rar/relationship",
  "actions": ["despacho.proponer_cambio", "incidencia.avisar"],
  "identifier": "relationship",
  "limits": { "max_per_day": 2, "duration_seconds": 2592000 } }

Company-initiated requests#

Revocation, expiry and HTTP answers#

Relationship over a Poppy conversation#

A Poppy agent today declares no inbox_uri and asks for no authorization_details, so under R2 it could not have a relationship. For such an agent, the relationship is asked for, received and answered inside its Poppy conversation (Poppy §7), without touching the Poppy contract: these are messages with data, and the agent reads them like any other event. This path was run once, on 21 October 2026, with a live personal agent through the Poppy adapter; no agent outside SOVRAS's own runs has used it yet.

Closed-question actions in 0.1, each offered only in its industry: alerta.confirmar_o_bloquear (commerce: “block” holds the dispatch) and alerta.mantener_o_liberar (hotels: “release” lets the booking go).

8Native profile and adapters Experimental#

/.well-known/vxp.json and the endpoints /v1/requests, /v1/proposals/{id}/accept|counter, /v1/requests/{id}/cancel|events|proof and /v1/relationships/{id} are experimental, and the document says so with "status": "experimental". They are VXP's own form: an agent that speaks neither Poppy nor PACT goes through the whole cycle with them. It discovers the company, identifies with private_key_jwt and DPoP, receives per-request authority with authorization_details, asks, receives a proposal, accepts, follows events, cancels, obtains the proof and keeps the relationship.

• The native profile needs neither adapter (Native-only gateway).
• The company MAY publish vxp.json, poppy.json and the PACT Agent Card at the same time.
• The issuer, the authorization server and the metadata are the same for the three entries.
• An agent that speaks Poppy or PACT does not need the native profile.

Pending Adoption of the native profile by a third-party agent.

Discovery#

https://<domain>/.well-known/vxp.json on the company's domain.

• organization.domain MUST be the host that served the document, and that domain MUST be listed in vxp_proof.domains of the issuer's RFC 8414 metadata.
• If poppy.json exists, its auth.issuer MUST be the same.
• vxp.json MUST NOT carry the proof's trust members; the verifier MUST take them only from the issuer metadata.
• capabilities lists only what the company decided to offer to external agents. access is public or delegated; admission is static (the grant is enough) or dynamic (the company decides per request: owner, precondition, policy).

{
  "protocol": "vxp",
  "version": "0.1",
  "organization": {
    "name": "Ferretería Demo",
    "domain": "store.example"
  },
  "issuer": "https://store.example/e/ferreteria-demo",
  "endpoint": "https://store.example/e/ferreteria-demo/v1",
  "capabilities": [
    {
      "id": "pedido.consultar",
      "effect": "read",
      "access": "delegated",
      "admission": "static",
      "authorization_details_type": "https://vxpprotocol.org/rar/capability"
    },
    {
      "id": "pedido.reprogramar_despacho",
      "effect": "write",
      "access": "delegated",
      "admission": "dynamic",
      "authorization_details_type": "https://vxpprotocol.org/rar/capability",
      "commitment_modes": [
        "firm",
        "conditional"
      ],
      "outcome_proof": true
    }
  ],
  "limits": {
    "max_revisions": 3,
    "proposal_ttl_seconds": 900,
    "max_accept_attempts": 3
  },
  "outcome_proof": {
    "version": "0.1",
    "trust": "issuer_metadata"
  },
  "status": "experimental",
  "vxp": {
    "version": "0.1",
    "relationship": {
      "authorization_details_type": "https://vxpprotocol.org/rar/relationship",
      "company_initiated_actions": [
        "despacho.proponer_cambio",
        "incidencia.avisar",
        "alerta.confirmar_o_bloquear"
      ]
    },
    "proof": {
      "trust": "issuer_metadata"
    }
  }
}

Authorization#

• The authorization server is the issuer's (RFC 8414). When the company also offers the Poppy adapter, it is the same one.
• Native requests MUST carry resource = endpoint (RFC 8707).
• The client authenticates with private_key_jwt over its Client ID Metadata Document, and the token MUST be bound with DPoP (RFC 9449, ES256). The agent's User ID for the company travels as an RFC 7523 assertion.
• To operate on a resource, the grant MUST carry authorization_details (RFC 9396) of type https://vxpprotocol.org/rar/capability. The consent screen MUST show each identifier in business language; the authorization server MUST check that each identifier belongs to the linked account, or answer invalid_authorization_details; the token response MUST return the details granted.
• The type vxpprotocol.org/operation is the grant of one revision. The two are complementary: the first authorizes asking, the second approving one exact revision.

{ "type": "https://vxpprotocol.org/rar/capability",
  "actions": ["pedido.reprogramar_despacho"],
  "identifier": "P-1042" }

Endpoints#

All with Authorization: DPoP and a DPoP proof.

Idempotency and re-verification#

• The key is scoped to (issuer, client_id, User ID, Idempotency-Key). Same key and same body (the JCS digest of {operation, target, parameters}) return the same request. A request waiting in authorization_required MUST be re-evaluated with the current token, without creating another.
• Same key with another body: 409 idempotency_key_reused.
• The key's digest MUST go in request.body.idempotency_key_digest.
• accept and cancel are idempotent by revision and by state, without a key.
• Before executing, the operator MUST re-evaluate, with the token of the accept call, the resource grant, the policy and the precondition. If anything fails, it does not execute.

Native-only gateway#

A company can implement VXP with the native profile alone. Nothing in VXP Proof, VXP Relationship or the operation requirements depends on Poppy or PACT:

• Discovery is vxp.json; the issuer and its keys come from the issuer's RFC 8414 metadata, which then carries no Poppy member (poppy_domains) and an empty vxp_proof.pact.
• A verifier anchors the proof by the issuer it knows (§10), with no adapter document in between.
• A token request without resource = the native endpoint has no other profile to go to, and gets invalid_target (RFC 8707).
• Agent authentication uses OAuth building blocks only: a Client ID Metadata Document, private_key_jwt, DPoP and RFC 8628.

Commitment of a revision#

Every revision issued MUST declare its commitment: {"mode": "firm" | "conditional", "requires": [...]}.

• firm: if accepted and executed, the company expects to fulfil the terms without depending on a third party. requires MUST be empty.
• conditional: the result depends on each condition in requires, which MUST NOT be empty. Each condition is the name of a term, and the read-back MUST observe it.
• The mode MUST come from what the capability can execute and verify, never from what the agent asks. A capability whose effect depends on a system the company does not control MUST be proposed conditional.

Negotiation limits#

The limits MUST NOT allow more than one automatic execution attempt per accepted revision.

Cancellation#

Cancelling is asking to stop.

• In received, authorization_required or proposed: cancelled, without effect.
• In accepted or waiting_human, before execution starts: cancelled, without effect.
• In executing or pending_verification: a request to stop. The state MUST NOT change because of it. The response MUST be 202 with cancellation: {requested_at, status: "requested", reversal_promised: false} and the known effects.
• In a final state: returned as it is.

The company and the operator MUST NOT claim that an effect was reverted unless it was reverted and read back. A request that ends failed or cancelled after execution started MUST carry effects[] with {system, change, applied, reverted?, status?}.

Adapters#

In both, the proof's trust members are published in the issuer's RFC 8414 metadata as vxp_proof, and any copy in poppy.json or the Agent Card MUST be identical in those members.

Renamed identifiers#

VXP is independent of SOVRAS. The protocol identifiers that the annex names with “sovras” are used as follows, from 22 October 2026.

vxpprotocol.org was registered on 22 October 2026 and is under SOVRAS's control, so these identifiers use a domain the publisher controls, as Poppy requires. Pending Publishing the site and these documents on that domain.

Implementation paths#

VXP fixes the well-known locations (/.well-known/vxp.json and the issuer's RFC 8414 metadata) and the native endpoints under the endpoint that vxp.json declares. Every other location is discovered: the key sets, the log's checkpoint and the proof bundle are read from vxp_proof in the metadata. Those paths are an implementation's own choice and carry no meaning.

9Operation requirements, security and privacy#

Where an external request becomes an operation on a company's system, every conforming implementation MUST show the behaviour below. A valid identity is a starting point: what passes is the intersection of what the person delegated, what the company allows and what the resource admits. VXP defines no interface for these rules and does not prescribe how they are built. Each one is written elsewhere in this specification and gathered here.

Rules O1 to O7#

Requirement, evidence and control#

Three different things that MUST NOT be confused:

A rule that the evidence cannot show (for example O3, the owner of a resource) is still required; the verifier only reports what the chain carries.

Security#

Threats covered by the proof and how, with what remains open.

Privacy#

• The log keeps no personal data: only blinded leaves and unlinkable tags.
• The user member is a pseudonym per company. A pseudonym is still personal data while the extra information exists.
• Everything personal travels as a selective disclosure; the agent reveals to a third party only what its user decides.
• The read-back keeps the values that are compared, not the body of the system's response.
• Keys, issuers, pseudonyms and tags are per company. A statement of one company MUST NOT validate with another company's key, and a statement of another operation MUST NOT be inserted into a chain.

Errors#

10Independent verification#

Anyone can check a proof package: the agent, a bank, an arbitrator, an auditor. The verifier receives the package, an anchor it knows on its own account (the company's domain or issuer, never a document handed over by whoever presents the package), and its own policy.

Anchoring the issuer and its keys#

1. Start from the anchor, with what each protocol gives the agent: the company's domain under Poppy, the brand's domain or the PACT authorization server under PACT, or the issuer the verifier already knows.
2. Fetch the issuer's RFC 8414 metadata and require its issuer to be identical, character by character.
3. Take the trust members from that metadata (vxp_proof), with the keys under the issuer.
4. Require any copy in poppy.json or the Agent Card to be identical in those members.
5. On any failure, including a missing or malformed document, answer issuer_not_anchored and keep running.

This anchors keys to whoever controls the issuer, not to the company as a legal person.

Algorithm and output#

1. Anchor the issuer.
2. Apply the chain rules to the whole chain; reject on the first failure with its code.
3. Derive the levels from the chain, not from claimed_assurance.
4. With the operation the agent saw: recompute terms_digest, require the salt, compare state and summary digest, and check observed values against the terms of the same name (P8).
5. With a log: verify inclusion and consistency, and at least one cosignature by a witness that is not the operator. Only then grant logged.
6. Report single_root: "operator" unless there is verifiable evidence of another root.

Output: {valid, company, anchor, key_source, final_state, revision, approval, derived_assurance[], single_root, custody_declared, logged}, plus pact_interface and pact_receipt with a PACT anchor or a receipt citation.

Assurance levels#

Each level is named by its real root: who asserts it with their signature. No field says verified: true; a verifier states its policy in these terms.

What a verifier can conclude today#

The repository includes three verifiers with no code shared with the issuer: two in Python and one in JavaScript that runs in the browser (Verify). The same team wrote them and the issuer, so they show that the rules are implementable and agree on every vector, not that someone outside checked them. Their results are in Conformance.

Reading a verdict#

A valid signature, the operator's testimony and an independent confirmation of a fact are three different things. A verdict keeps them apart:

Key rotation and historical verification#

• Statements name their key by kid (RFC 7638). An issuer that rotates a proof key SHOULD keep the earlier public key in its JWKS for as long as proofs signed with it are expected to be verified, and MUST NOT reuse a retired key.
• A key removed from the JWKS no longer verifies against live material: the verifier answers unknown_key. Against material saved while the key was published, the same proof still verifies. A verifier that uses saved material SHOULD say so, with the date the material was obtained.
• Keys generated in memory and lost when a process stops make every proof they signed unverifiable unless their public keys were saved. Implementations SHOULD keep proof keys persistent.

11Examples#

Every object in this section was captured from the reference implementation in the evening run of 22 October 2026: a native-only gateway (no Poppy, no PACT) with persistent keys, against a test company. The run is reproducible with reference/scripts/recorrido-nativo.test.ts, and its signed files and public material are in the downloads. Hosts are shown as store.example and agent.example, and long tokens are shortened. Operations run with live agents on 21 October 2026, during SOVRAS's production runs with test companies, are documented in Examples: personal agents through the Poppy adapter, among them SOVRAS's beta agent Nova AI, and a web agent identified as Grok.

Asking without authority#

POST /v1/requests without a grant for the order returns authorization_required with exactly what is missing.

{
  "request_id": "req_eSTKa7J-MERu",
  "operation": "pedido.reprogramar_despacho",
  "target": {
    "order_ref": "P-1042"
  },
  "state": "authorization_required",
  "projections": {
    "poppy": null,
    "a2a": "TASK_STATE_AUTH_REQUIRED"
  },
  "authorization": {
    "error": "authorization_required",
    "authorization_details": [
      {
        "type": "https://vxpprotocol.org/rar/capability",
        "actions": [
          "pedido.reprogramar_despacho"
        ],
        "identifier": "P-1042"
      }
    ],
    "device_authorization_endpoint": "https://store.example/e/ferreteria-demo/oauth/device",
    "resource": "https://store.example/e/ferreteria-demo/v1"
  }
}

{
  "access_token": "nt_pt_q…",
  "token_type": "DPoP",
  "expires_in": 3600,
  "authorization_details": [
    {
      "type": "https://vxpprotocol.org/rar/capability",
      "actions": [
        "pedido.reprogramar_despacho"
      ],
      "identifier": "P-1042"
    }
  ],
  "relationships": [
    {
      "relationship_id": "rel_X9sUhyHhjsLp",
      "state": "active",
      "actions": [
        "despacho.proponer_cambio"
      ],
      "limits": {
        "max_per_day": 2
      },
      "expires_at": "2026-10-22T23:30:29.000Z",
      "agreement": "eyJhbGciO…"
    }
  ]
}

A signed proposal#

{
  "id": "prop_op_XzdILOmlgiae_r1",
  "revision": 1,
  "state": "proposed",
  "summary": "Cambiar el despacho del pedido P-1042 (Taladro percutor 800 W) del 2026-10-24 al 2026-10-28, a Calle Ejemplo 100, Santiago, sin costo.",
  "terms": {
    "pedido": "P-1042",
    "producto": "Taladro percutor 800 W",
    "despacho_actual": "2026-10-24",
    "despacho_nuevo": "2026-10-28",
    "direccion": "Calle Ejemplo 100, Santiago",
    "costo": {
      "amount": "0",
      "currency": "CLP"
    },
    "vxp_salt": "hRQxNKbVg-MdR_aCsFbHYQ"
  },
  "commitment": {
    "mode": "firm",
    "requires": []
  },
  "expires_at": "2026-10-22T22:45:29.356Z",
  "user_approval_required": true,
  "limits": {
    "max_revisions": 3,
    "revisions_left": 2,
    "max_accept_attempts": 3,
    "accept_attempts_left": 3
  }
}

The chain and the verdict#

Six statements, shown as processed payload bodies. Statements signed by the company and by the operator alternate as in Statement kinds.

[
  {
    "seq": 0,
    "kind": "request",
    "signer": "operator",
    "prev": null,
    "body": {
      "channel": "vxp",
      "client_id": "https://agent.example/agent.json",
      "request_digest": "sha-256:mfJleoso5oEyt_pqJS3OtbmYam7cyncRBrAcqbKfIrI"
    }
  },
  {
    "seq": 1,
    "kind": "terms",
    "signer": "company",
    "prev": "sha-256:kAO5f-JoCSonqCQnG_1vki1T01wmqh4wDS5YK74U0v4",
    "body": {
      "capability": "pedido.reprogramar_despacho",
      "commitment": {
        "mode": "firm",
        "requires": []
      },
      "company_review_required": false,
      "expires_at": "2026-10-22T22:45:29.356Z",
      "read_back_terms": [
        "pedido",
        "despacho_nuevo"
      ],
      "revision": 1,
      "terms_digest": "sha-256:LexccQ2IrXTwkx-zM3KJ3m2Sf5-YHsqzs-po_QCxAC0",
      "user_approval_required": true
    }
  },
  {
    "seq": 2,
    "kind": "user_approval",
    "signer": "operator",
    "prev": "sha-256:lCNrubnR6MLwUhwhcNUCWaqAKxFGOVWIlx3Rafs8v08",
    "body": {
      "method": "agent_asserted",
      "revision": 1,
      "terms_digest": "sha-256:LexccQ2IrXTwkx-zM3KJ3m2Sf5-YHsqzs-po_QCxAC0"
    }
  },
  {
    "seq": 3,
    "kind": "execution",
    "signer": "operator",
    "prev": "sha-256:wk4J9m_VE1zzlLhc1QEZ7l3m7USokQiF9gtICMNft5U",
    "body": {
      "attempt": 1,
      "capability": "pedido.reprogramar_despacho",
      "release": "sha-256:u1TBBxJXTKta36K5UI_j_myhQaHzbPP2HcF4rBKGxPA",
      "revision": 1,
      "terms_digest": "sha-256:LexccQ2IrXTwkx-zM3KJ3m2Sf5-YHsqzs-po_QCxAC0"
    }
  },
  {
    "seq": 4,
    "kind": "read_back",
    "signer": "operator",
    "prev": "sha-256:Gs2GOu4azZ6aE1VaKjm2Edj91Zya-VP4zP9Fbc71VJw",
    "body": {
      "matches_terms": true,
      "method": "system_read_back",
      "observed": {
        "_sd": [
          "g1MZFKspn_fcTPBy5COpYIVc6rPjeQYv9bF7QBCrv5g"
        ],
        "despacho_nuevo": "2026-10-28",
        "pedido": "P-1042"
      },
      "source": "company_system"
    }
  },
  {
    "seq": 5,
    "kind": "outcome",
    "signer": "company",
    "prev": "sha-256:jfSCFRNR4QjvnD9VjmaNWdhfAg4ftVxMWy5xLrrT6Jo",
    "body": {
      "claimed_assurance": [
        "issuer_key_attested",
        "operator_observed",
        "operator_reported_read_back",
        "operator_reported_agent_approval"
      ],
      "result_summary_digest": "sha-256:aKs3uy77c1osgD7qSgTqNJ0_YITroc5iwoYHqFmSl6s",
      "revision": 1,
      "state": "succeeded",
      "terms_digest": "sha-256:LexccQ2IrXTwkx-zM3KJ3m2Sf5-YHsqzs-po_QCxAC0",
      "third_party": []
    }
  }
]

{
  "valid": true,
  "final_state": "succeeded",
  "revision": 1,
  "approval": "agent_asserted",
  "derived_assurance": [
    "issuer_key_attested",
    "operator_observed",
    "operator_reported_read_back",
    "operator_reported_agent_approval"
  ],
  "single_root": "operator",
  "custody_declared": "operator_hosted",
  "logged": false,
  "company": "https://store.example/e/ferreteria-demo",
  "anchor": "issuer",
  "key_source": "issuer_metadata_live",
  "profile": "issuer",
  "statements": 6,
  "log_inclusion": "ok",
  "tree_size": 6,
  "live_tree_size": 6,
  "consistency": "ok",
  "witnesses": 0,
  "operation": "matches"
}

A company-initiated request#

The relationship as granted in the token, and the company's request delivered to the agent's HTTP inbox (Experimental). The delivery value is the reference implementation's own outbox label.

{
  "relationship": {
    "relationship_id": "rel_X9sUhyHhjsLp",
    "state": "active",
    "actions": [
      "despacho.proponer_cambio"
    ],
    "limits": {
      "max_per_day": 2
    },
    "expires_at": "2026-10-22T23:30:29.000Z",
    "agreement": "eyJhbGciO…"
  },
  "delivery": {
    "outbox_id": "out_c_bdRdvaL42s",
    "delivery": "entregado",
    "http": 202,
    "content": {
      "request_id": "req_1tEWlrG-_6eq",
      "request_url": "https://store.example/e/ferreteria-demo/v1/requests/req_1tEWlrG-_6eq",
      "proposal_id": "prop_op_wHbfb8mjcZI7_r1",
      "operation_id": "op_wHbfb8mjcZI7",
      "summary": "Cambiar el despacho del pedido P-1043 (Escalera de aluminio 6 peldaños) del 2026-10-27 al 2026-10-30, a Calle Ejemplo 100, Santiago, sin costo.",
      "terms_digest": "sha-256:u-oBOmfP_-UahdQqZhwaNaeQAq1ro4hzhaDCy69JhG8"
    }
  }
}

12Tests and conformance#

Conformance by role#

• Conforming issuer (company and operator): meets O1 to O7; emits the chain with the chain rules; publishes the trust members with a truthful custody; never emits succeeded without a matching read-back; puts no personal data in clear; and, if it offers the Poppy or PACT adapter, keeps that protocol's official tools passing with the extension active.
• Conforming verifier: implements SD-JWT processing (RFC 9901 §7.1), the chain rules and the verification algorithm with anchoring, and obtains exactly the results of the test vectors, including the codes and the seq of the negative cases.
• Conforming agent (SHOULD): lists the extension, verifies each package, keeps it with its inclusion proofs, and shows the user the derived level, not the claimed one.

Three kinds of tests, never added together:

How to run the checks#

From reference/ in the repository, which also holds the verifiers and the test vectors. Results, with their logs, are in Conformance.

npm test
npm run test:network
node scripts/mutar-vxp.mjs
node scripts/mutar-nativo.mjs
node scripts/mutar-exigencia.mjs
PYTHONIOENCODING=utf-8 python scripts/mutar-prueba.py
python ../verifier/verificar.py ../vectors/vectores-0.1.json
python ../verifier/verificar_paquete.py vectores ../vectors/vectores-0.1.json
python ../verifier/verificar_paquete.py pact ../vectors/vectores-pact-0.1.json
python scripts/cruce-verificadores.py
python scripts/fuzz-diferencial.py 20000

A third party checks its own implementation of the native profile with the conformance validator: it acts as a personal agent against any company endpoint, cites the rule behind each check and reports each one as passed, failed, optional or manual (conformance/validate.ts, conformance/CHECKLIST.md, conformance/MATRIX.md). Against the reference implementation: 51 passed, 0 failed, 3 manual.

JSON Schemas#

Informative Every object of this draft has a JSON Schema (2020-12) at https://vxpprotocol.org/schemas/0.1/: the discovery document, the members of the issuer metadata and of the agent's Client ID Metadata Document, the token response, the native requests, proposals, events and errors, the proof package and each statement by kind, the log checkpoint, and the relationship, its agreement, the company's requests, the answers and their receipts. They restate §6 to §8; where they differ, this text governs. A schema checks shape; signatures, digests and the order of a chain are checked by a verifier (§10). The conformance validator checks every object an implementation returns against them (check S1).

13Specification and versions#

Draft 0.1, 21 October 2026. Revised 22 October 2026, first for names vxp, rule I1 and Poppy §4.4 conformance, and again that evening for two public components and operation requirements O1 to O7; native-only gateway; implementation paths; key rotation and historical verification. Revised 23 October 2026: read capabilities and standing_permission in the native endpoints, and the JSON Schemas (§12).

• Poppy draft 0.2, official kit at commit 39b35bd. Poppy can break compatibility before its 1.0.
• PACT 1.0 over A2A 1.0.1, official suite at commit 838c6bd.

Versioning#

The extension has one version, and it MUST be the same in three places: version of the trust block, the A2A extension URI (https://vxpprotocol.org/ext/proof/v0.1) and v of each statement and package. While VXP is a 0.x draft, every new draft is treated as incompatible with the previous one. A verifier MUST reject a v it does not know.

Status of each part#

Open items#

Taking part#

The specification, the reference implementation, the verifiers and the vectors live in one repository under Apache 2.0. Proposals and errata are issues or pull requests there; a change to a normative rule cites the rule's identifier and comes with a test or a vector. See CONTRIBUTING.md in the repository.