Supplementary technical note · 9 November 2026 · Luis Adolfo Soto Dorado
This source is a technical crosswalk and proposed interoperability mapping. It is not part of the frozen Govern 3.0 normative corpus; proposed claim types are not registered standards or deployed API integrations.

Legitimate Authority over the Pipes: How PAVREN Complements AP2 and OAuth-Based Agent Delegation

Nov 9, 2026 · Luis Adolfo Soto Dorado, creator and architect of PAVREN · Technical note

Summary

Agent protocols prove and carry an authorization. PAVREN, an open institutional infrastructure for governing AI, defines who holds the legitimate authority to grant it, how far it reaches, and what evidence must remain. The two are complementary layers, not competing ones.

The industry is converging fast on delegated authority for AI agents. Google's Agent Payments Protocol (AP2) uses cryptographically signed mandates to prove that a user authorized a specific purchase. The OpenID Foundation calls for moving from user impersonation to explicit on-behalf-of delegation, with an operational envelope enforced by policy. Both are essential, and both answer the same question well: is this authorization authentic and within its technical limits?

They leave a second question to someone else: was the person who signed entitled to authorize this at all? An employee can sign a valid mandate for a payment their role does not allow. A citizen can delegate a task that requires a power they do not hold. A valid signature from someone without authority is a well-formed mistake.

PAVREN supplies that second layer. Its Authorized Envelope is the verifiable representation of the authority currently applicable to a capability or an action: where that authority comes from, how far it was delegated, and what evidence it leaves. This note maps PAVREN to AP2 version 0.2 and to OAuth-based delegation, first concern by concern and then field by field, so that implementers can carry legitimate authority through the pipes they are already building.

The mapping also shows where PAVREN asks for more than the protocols do. An AP2 open mandate lets an agent complete a purchase on its own, within constraints the user approved in advance; under PAVREN, a payment to a third party still needs the prior approval of whoever holds the authority to make it. The two layers meet at that point: AP2 proves that a signature covers a checkout, and PAVREN establishes whose signature it must be.

The principle is short: being able to ask is not the same as being able to authorize.

PAVREN in brief

PAVREN is an open institutional infrastructure for governing the use of artificial intelligence. Its guiding principle is authority before autonomy: technical capability may give effect to an action only within authority that is explicit, bounded, current, verifiable and revocable. PAVREN was conceived and designed by Luis Adolfo Soto Dorado and is published by DAcorp S.R.L.

It applies to anyone who uses, acquires, configures or operates AI: a person delegating a task to a chat assistant or a personal agent, a company deploying agents, a bank, a university or a public institution. It rests on a distinction that agent systems tend to blur. Capability is what a system can technically do; authority is what it is institutionally legitimized to do; autonomy is how independently it may decide and act within that authority. Every capability that can produce a material effect follows the same sequence: authority, Authorized Envelope, bounded autonomy, evidence and revalidation.

Component What it provides
PAVREN Govern 3.0 The open specification: a Governing Core with 21 control domains (C01–C21), profiles and domain modules activated by the characteristics of each use (personal agents, financial services, public sector, health and others), and an Operational Kit of annexes A–S. Published in English and Spanish, both authoritative, under CC BY 4.0
Machine-readable layer The same rules as JSON-LD, JSON Schema, SHACL, OpenAPI and SQL artifacts, with a formal semantics of authority and a CF0–CF5 conformance corpus, under the Apache License 2.0
PAVREN Studio Prepares and records authority decisions: who is responsible, which sources apply, what is permitted and when it must be reviewed
PAVREN Enforce Checks the authority in force at the point where an action takes effect, on the execution paths where it is integrated
First Aid kit A free entry point that helps a person understand what their AI may do for them and who must decide

The rest of this note relies on five terms from PAVREN Govern 3.0:

Term Meaning
Authorized Envelope The verifiable representation of the authority that currently applies to a capability or action: who acts, what may be done, where, within which limits, with which approvals and until when
Consequence level How severe the effect of a use can be: P0 for uses that cannot be approved at all, and N1 to N4, from low-impact productivity to decisions on rights, money or safety
Authority band The human approval an action needs to take effect: R0, none, for reading or responding only; R1, batch approval with a cap; R2, individual signed approval; R3, individual approval attested and bound to the specific action; R4, no autonomous action
Operating mode What the system does with its own output: read, respond, propose, execute with prior approval, execute within limits, or operate within an authorized domain
Decision outcome The result of checking an action against its envelope: authorized, denied, escalate or unresolved. Only an authorizing decision lets the action take effect

The full corpus is available at pavren.org/en/govern/3.0.

Two envelopes: operational and authorized

An operational envelope says how far an agent may go. An Authorized Envelope says whether anyone with the right to decide allowed it to go there. The first is a technical boundary; the second is a legitimacy boundary.

The OpenID Foundation describes the operational envelope well: rather than asking users to approve every action, an administrator or user defines a high-level policy with budget limits, data access tiers and call velocity, and the identity system enforces it programmatically. That is the right answer to consent fatigue.

PAVREN adds what that policy presupposes. Before a budget limit is set, someone must hold the power to set it. Before a mandate is signed, the signer must be entitled to commit the person or organization they represent. PAVREN models that chain of authority explicitly, so that the operational limits inherit their legitimacy from a verifiable source instead of assuming it.

four layers of agent authorization · where PAVREN and the protocols meet

four layers of agent authorization · where PAVREN and the protocols meet

Each layer answers a different question. Agent protocols already do the second and fourth layers well; PAVREN supplies the first and connects it to the third.

Crosswalk by concern: PAVREN, AP2 and OAuth-based delegation

For each concern, the protocols already provide the operational mechanism; PAVREN provides the authority that the mechanism carries. The last column is the contribution PAVREN makes to an implementation that already uses AP2 or OAuth.

Concern PAVREN AP2 OAuth and OpenID delegation What PAVREN adds
Source of authority Authority chain: who may authorize, by which power, delegated by whom The user's signature on the open and closed Checkout and Payment Mandates User or administrator consent; the delegating user in the sub claim Whether the signer was entitled to authorize at all
Limits Authorized Envelope: acting subject, action, destination, parameters, mode, approvals, limits and validity Constraints on open mandates, such as amount ranges, payees and execution dates Scopes and a policy-defined operational envelope Limits derived from authority, not only from configuration
Who acts Inventory of every AI and agent, each with an accountable owner The shopping agent, distinct from user and merchant signatures The agent in the act or azp claim, distinct from the user An accountable owner for each agent
Decision at the point of action A decision at the point of effect: authorized, denied, escalated or unresolved, applied by PAVREN Enforce where it is integrated The closed Checkout Mandate must match what the user approved Policy decision and enforcement points; AuthZEN standardizes their interface The escalation rule, tied to consequence levels and authority bands
Human intervention Authority bands R0 to R4 and operating modes, from read to execute with prior approval Human-present and human-not-present modalities Asynchronous approval through CIBA When human approval is mandatory, and whose
Delegation chains Authority bounded at each step and preserved as systems change Delegation from the user to one agent through open mandates; agent-to-agent delegation is outside version 0.2 Token exchange and scope attenuation across hops The legitimacy of each hop, not only a narrower scope
Revocation and stop Stop procedure, cascading revocation and a revocable personal mandate Mandate expiry; managing delegated mandates is outside version 0.2 Revocation, the Shared Signals Framework and de-provisioning An institutional stop with a named responsible person
Evidence Evidence registry that links each action to the authority and controls it relied on Checkout and Payment Mandates and their receipts, usable as dispute evidence Audit logs that distinguish principal and actor The normative meaning: which authority and which controls applied
Accessibility Personal mandate in the free first-aid kit and a WhatsApp interface The Trusted Surface on which the user approves mandates Consent screens, with the risk of consent fatigue Plain-language understanding for people who are not specialists

The mapping is deliberately conservative: it describes AP2 and OAuth-based delegation as their public documentation presents them, and it proposes no change to either. The additions in the sections that follow use extension points that both already define.

Worked example: a valid signature without authority

Without the authority layer, every signature in this example is valid and the payment goes through. The protocols work perfectly; the organization's rules do not. The scenario is illustrative.

Ana is an accounts assistant at a mid-size company. She asks a payments agent to pay a supplier invoice for USD 18,000. Company policy allows assistants to approve payments up to USD 5,000; anything above requires the finance manager.

  1. Ana instructs the agent and signs. The agent prepares the payment and Ana approves it. The result is a cryptographically valid mandate and an on-behalf-of token with Ana as the delegating user and the agent as the actor.

  2. Before the action takes effect, PAVREN Enforce checks Ana's Authorized Envelope. Her authority, recorded in the institution's authority chain, covers payments up to USD 5,000.

  3. The action does not fit, so it escalates instead of failing silently. Enforce routes an approval request to the person who holds the authority, the finance manager, through an asynchronous channel such as CIBA.

  4. The manager approves, and the payment proceeds. The evidence records the full chain: Ana proposed, the manager authorized, the agent executed, within a stated envelope and validity window.

  5. If no one with authority approves in time, the action stops. Ana is told why, and the request remains on record.

The same pattern applies outside payments: a nurse's agent requesting a prescription change, a civil servant's agent signing a procurement notice, or a citizen's personal agent accepting a contract. In each case the question is not only whether the request is authentic, but whether the person behind it holds the power to authorize it.

Field-level crosswalk: Authorized Envelope, AP2 and OAuth delegation

Most limits of an Authorized Envelope have a carrier in AP2 or in OAuth, though in different places: AP2 carries limits as constraints on a mandate, and OAuth carries identities as claims on a delegated token. The person on whose behalf the agent acts is the token's sub, the agent is the current actor in act, and the envelope travels as a reference beside them, never inside act.

This section maps AP2 version 0.2. That version no longer defines a separate Intent Mandate: the user's intent is expressed as constraints on open Checkout and Payment Mandates (vct values mandate.checkout.open.1 and mandate.payment.open.1), which the agent later closes against one specific checkout. PAVREN field names are those of the PAVREN Govern 3.0 machine-readable schemas.

Who is who

Party PAVREN AP2 v0.2 OAuth delegation token
Person on whose behalf the agent acts Grantee or delegator at the root of the chain, reached through the envelope's grant_id and delegation_id The user who approves mandate content on a Trusted Surface, vouched for by a User Credential issuer or a trusted Agent Provider sub
Agent that acts Delegatee of the delegation, named in the envelope's subject_id The Shopping Agent, identified by the public key in the open mandate's cnf claim act.sub, the current actor; its key in cnf.jkt when the token is sender-constrained (RFC 9449)
Earlier agents in the chain Delegations linked by parent_delegation_id and bounded by max_depth Agent-to-agent delegation is outside the scope of version 0.2 Nested act claims, which are informational only for access control
Approver, when not the requester An approval record bound to the action digest No separate role: whoever signs the closed mandate on the Trusted Surface is treated as the user No claim; approval travels out of band, for example through CIBA
Party that verifies before giving effect The counterparty, which verifies that the mandate is current and covers the action and that the actor chain is verifiable (PRF-PERS, PA-R15) Merchant, Credential Provider and Merchant Payment Processor, each verifying the mandates it receives The resource server, or a decision point it consults through AuthZEN
Source of authority source_id of the Authority Grant: law, regulation, contract, policy or mandate Not represented Not represented; iss names the token issuer, not the authority

One naming trap deserves its own sentence. The envelope's subject_id names the party that holds the delegated authority, which in an agent delegation is the agent; it maps to act.sub, not to the token's sub. The agent's identity is joined across the two protocols by its key: the JWK thumbprint of the key in the AP2 mandate's cnf should equal the token's cnf.jkt.

Delegation chains need the same care. PAVREN requires the chain of actors to remain verifiable where the action takes effect (C10). Nested act claims keep that chain visible, but RFC 8693 bars using prior actors in access-control decisions. The chain is therefore verified at each token exchange, where the authorization server can check containment against the envelope. For a material action, the destination does not rely on that check alone: it resolves the envelope reference itself and, if the chain cannot be verified, denies or escalates the action (C10).

Envelope fields

Most envelope fields have a partial carrier in at least one protocol; the reference to the envelope itself has none, and is the one addition this crosswalk proposes. Each row reads left to right: the PAVREN field, where AP2 can enforce it, where an OAuth delegated token can carry it, and the rule an implementer needs to keep the three consistent.

Authorized Envelope field AP2 v0.2 OAuth delegated token Rule for implementers
id, version (the envelope itself) No carrier today; a constraint type defined through AP2's Mandate Constraints extension point, or an additional claim on a closed mandate, can carry the envelope reference and digest An authorization_details entry (RFC 9396) of type https://pavren.org/ns/authorized-envelope, at top level; an authorization server that does not know the type rejects it (RFC 9396, section 5) Never inside act, whose members identify the actor only (RFC 8693, section 4.1)
subject_id The agent's public key in the open mandate's cnf act.sub, with the same key in cnf.jkt Join the agent across protocols by key thumbprint, not by name
allowed_actions The mandate type itself, through vct: checkout or payment scope, or actions in authorization_details AP2 covers two actions; any other action rests on the OAuth side alone
targets checkout.allowed_merchants, payment.allowed_payees, payment.allowed_pisps aud or resource; locations in authorization_details Match merchants and payees by id, not by display name
max_amount payment.amount_range (max, currency) A type-specific field in authorization_details; no registered claim PAVREN money is an exact decimal string and AP2 amounts are minor units: convert with exact arithmetic and the ISO 4217 exponent of each currency, never with floating point, and treat a currency mismatch as out of bounds
escalation_above No carrier No carrier Set amount_range.max at or below this threshold; above it, the person who holds the authority signs the closed mandates directly
limits.budget, limits.max_iterations payment.budget with payment.agent_recurrence (max_occurrences, frequency) No registered claim AP2's frequency has no PAVREN field; a budget bounds the series, and each material payment still needs its approval
parameter_limits (EQ, NEQ, GT, GTE, LT, LTE, IN) checkout.line_items for items and quantities; other parameters need a new constraint type with a schema and an evaluation algorithm Type-specific fields in authorization_details AP2 treats an unknown constraint as failing, so a verifier unaware of a PAVREN type fails closed and can hand the decision back to the user
purpose No field in version 0.2 mandates No registered claim Resolve it from the envelope reference; a checkout does not reveal purpose
data_constraints, tool_constraints No carrier; AP2 governs checkout and payment only datatypes and locations in authorization_details, partially Enforce at the data or tool boundary, not at the merchant
valid_from, valid_to, limits.max_duration_seconds iat and exp of the mandate; payment.execution_date (not_before, not_after) nbf, exp No mandate or token may outlive valid_to; AP2 recommends the shortest exp that completes the task
status, invalidation_conditions exp; a new open mandate may not be presented until the previous one is rejected, and the agent narrows an open mandate after each receipt; managing delegated mandates is outside version 0.2 exp; revocation and introspection; an exchanged token does not inherit later revocation of its input token Check envelope status at decision time, and cascade a revoked delegation to every mandate and token derived from it
consequence_level, authority_band, operating_modes Only the mode: direct (human present) or autonomous (human not present) No carrier See the mode rule below
limits.max_delegation_depth Agent-to-agent delegation is outside the scope of version 0.2 The depth of nested act claims is not limited by the token Check depth and containment at every token exchange; a resource server cannot, because prior actors are informational only
evidence_refs Mandate, Checkout and Payment Receipts, each with a reference hash of the closed mandate No standard carrier Record AP2 receipt references as envelope evidence; PAVREN digests (hex SHA-256 over RFC 8785 canonical JSON) and AP2 hashes (base64url) are recorded side by side, never compared
within_limits_conditions No carrier No carrier Applies only to execute within limits; see below

Two rows have no carrier in either protocol: escalation_above and within_limits_conditions. Both decide whether a human must act, which is exactly where a valid signature and legitimate authority part ways.

Which AP2 mode PAVREN admits

Under PAVREN, an AP2 open mandate is a mandate, not an approval. It bounds what the agent may prepare. Whether the agent may also execute depends on the operating mode the envelope grants, and for payments to third parties that mode is execute with prior approval.

Both specifications start from the same premise. AP2 assumes that prompt injection cannot be prevented and treats every language model and agent as a potential attacker; PAVREN holds that capability is not authority. They part ways on what that premise requires when an agent pays a third party.

PAVREN operating mode AP2 v0.2 OAuth delegation
READ, RESPOND, PROPOSE No mandate is signed; the agent may assemble a checkout and present it Read access only; no payment scope
EXECUTE_WITH_PRIOR_APPROVAL Direct mode: the person who holds the authority signs the closed Checkout and Payment Mandates on a Trusted Surface, bound to checkout_hash; several closed mandates delegated in one request can serve as a batch approval where the consequence level allows it Delegated token for the agent; the approval is obtained in session or asynchronously, for example through CIBA
EXECUTE_WITHIN_LIMITS Autonomous mode: the agent signs closed mandates within the open mandate's constraints Delegated token within the envelope
Authority band R4, or consequence level P0 No mandate No token for execution

Execute within limits is admissible only at consequence N1 or N2, and only when six cumulative conditions hold (Core, section 9.4). Two of them rule out payments to third parties: the action must produce no effect outside the organization, and it must not touch rights, money, safety or official records. PAVREN's Personal Agents Profile states the consequence directly: a general instruction such as buying when a price drops below a given value is a mandate and not an approval, and a payment executed from it alone is denied (PRF-PERS, PA-R05).

At consequence level N4, PAVREN requires authority band R3: an individual, attested approval, inseparably bound to the specific action, which cannot be reused, expires, and cannot be altered by the agent once given. A Trusted Surface signature over checkout_hash already binds the approval to one checkout; PAVREN adds whose signature it must be and how strongly it must be attested.

Direct mode has a consequence of its own: it carries no constraints. The signature on the closed mandate is the whole authorization, so AP2 alone cannot stop a person from signing a payment above their authority. The envelope must therefore be checked before the Trusted Surface asks for a signature.

AP2 already anticipates where such a check can live. Its implementation guidance suggests deterministic code that verifies each closed mandate before the agent's key signs it. The same position, in front of the agent's key and in front of the Trusted Surface, is where PAVREN Enforce belongs when it is integrated.

Decisions at the point of action

PAVREN distinguishes four outcomes where AuthZEN returns two. Escalate and unresolved both travel as a denial with a reason, so an enforcement point that ignores the reason still cannot let the action through. AuthZEN 1.0 defines a boolean decision and an optional context object: a false decision must not go forward, and an enforcement point may reject a true decision whose context it does not understand. Within PAVREN, an established denial prevails over any other outcome (Core, section 2.2).

PAVREN decision AuthZEN 1.0 response AP2 v0.2 What follows
AUTHORIZED "decision": true The verifier returns a success receipt The action takes effect within the envelope, and the receipt joins the envelope's evidence
DENIED "decision": false, with the reason in context invalid_mandate, a terminal error The action stops and the denial is recorded
ESCALATE "decision": false, with the escalation route in context unresolved_constraint, which AP2 uses to bring the user back to approve the closed mandates directly The person who holds the authority is asked, for example through CIBA; nothing takes effect in the meantime
UNRESOLVED "decision": false, with the missing fact in context unresolved_constraint, or invalid_mandate when no approval could settle it The action is treated as not authorized until the missing fact is established

A CIBA request can carry the same authorization_details as the delegated token (RFC 9396, section 3), so the person asked to approve sees the specific action, amount and payee rather than a generic consent screen.

Ana's envelope on the wire

On the wire, the worked example becomes three artifacts: an Authorized Envelope capped at her USD 5,000 authority, a delegated token that names her as sub and the agent as act, and a closed AP2 Payment Mandate signed by the person who actually holds authority over USD 18,000. Identifiers and values are illustrative; the authorization_details type and the authority claim are proposals, not registered values.

  1. The envelope bounds the agent. It derives from Ana's grant, names the agent as its subject, and admits execution only with prior approval.

{
"type": "AuthorizedEnvelope",
"id": "env-ana-supplier-payments",
"grant_id": "grant-ap-assistants",
"delegation_id": "del-ana-payments-agent",
"subject_id": "agent:payments-7f3c",
"purpose": "Pay approved supplier invoices",
"consequence_level": "N3",
"authority_band": "R2",
"operating_modes": ["PROPOSE", "EXECUTE_WITH_PRIOR_APPROVAL"],
"allowed_actions": ["PAYMENT.EXECUTE"],
"targets": ["supplier:andes-001"],
"max_amount": { "value": "5000.00", "currency": "USD" },
"escalation_above": { "value": "5000.00", "currency": "USD" },
"valid_from": "2026-11-01T00:00:00Z",
"valid_to": "2026-11-30T23:59:59Z",
"status": "ACTIVE",
"evidence_refs": ["ev-del-ana-signed"]
}

  1. The delegated token names both parties and points to the envelope. The reference sits at top level, beside act; the agent's key thumbprint in cnf.jkt is the key the agent uses with AP2.

{
"iss": "https://as.company.example",
"sub": "ana@company.example",
"act": { "sub": "agent:payments-7f3c" },
"aud": "https://payments.company.example",
"iat": 1794319200,
"exp": 1794322800,
"cnf": { "jkt": "<thumbprint of the agent key>" },
"authorization_details": [
{
"type": "https://pavren.org/ns/authorized-envelope",
"envelope_id": "env-ana-supplier-payments",
"envelope_digest": "<hex SHA-256 of the envelope, RFC 8785>",
"actions": ["PAYMENT.EXECUTE"],
"locations": ["https://payments.company.example"]
}
]
}

  1. The USD 18,000 payment is signed by the finance manager, not by Ana. PAVREN Enforce checks the envelope before the payment takes effect, and ideally before the Trusted Surface asks for any signature. It finds the amount above escalation_above, and routes the approval to the finance manager, for example through a CIBA request that carries the same authorization details. She signs the closed mandates in direct mode, under her own envelope and on a Trusted Surface that states that authority in plain terms, and the closed Payment Mandate carries a reference to that authority as an additional claim.

{
"vct": "mandate.payment.1",
"transaction_id": "<base64url hash of the merchant-signed checkout JWT>",
"payee": { "id": "supplier:andes-001", "name": "Andes Supplies" },
"payment_amount": { "amount": 1800000, "currency": "USD" },
"payment_instrument": { "id": "acct-ops-01", "type": "bank_transfer" },
"https://pavren.org/ns/authority": {
"envelope_id": "env-finance-manager-payments",
"decision": "AUTHORIZED",
"approval_ref": "appr-inv-4471"
}
}

The amount travels as 1,800,000 minor units in AP2 and as "18000.00" in PAVREN. A verifier that does not know the authority claim simply ignores it and verifies the mandate as AP2 defines; the claim exists so that a dispute can show both what was signed and who had the right to sign it.

Security considerations

The crosswalk carries authority across three systems, and every crossing is a place where it can be lost. Six crossings call for explicit requirements. Each follows from the mapping above, and none changes AP2 or OAuth. All of them assume, as AP2 does, that the agent itself may be manipulated.

Threat How it arises What this crosswalk requires
Escalation flooding A manipulated agent repeats out-of-envelope requests until the approver, tired of prompts, approves one by mistake or stops answering Bound escalations per agent and per envelope, collapse repeated requests for the same action into one, and treat a run of denied or escalated attempts as grounds to suspend the agent rather than to keep asking. Every approval request shows the specific action, amount and payee, never a generic prompt
Amount conversion errors A gateway converts between PAVREN decimal strings and AP2 minor units with floating-point arithmetic or the wrong ISO 4217 exponent, so that USD 50,000 is checked as USD 5,000 Convert with exact integer or decimal arithmetic and the exponent ISO 4217 assigns to each currency (zero for JPY, four for CLF); reject amounts more precise than their currency allows; compare in a single representation at a single point, and record the original values as evidence
Actor chain laundering An intermediate agent obtains a fresh token in its own name, so that a multi-hop delegation reaches the destination looking like a single hop Authority comes from the envelope, not from the shape of the token. A token without an envelope reference carries no authority for a material action, and the destination verifies that act.sub is the subject of the referenced envelope and that its delegation chain is current; if the chain cannot be verified, the action is denied or escalated (C10)
Revocation lag An envelope is revoked or suspended, but tokens and open mandates derived from it remain valid until they expire For material actions, check envelope status at the point of effect instead of trusting a cached token or a local signature check; keep token and open-mandate lifetimes short; and retire derived open mandates at every verifier that could still accept them
Blind signing The Trusted Surface shows the checkout but not the authority under which the person signs Before the signature, the Trusted Surface states the authority in human terms: in whose name the person signs, which limit applies and why approval was requested. The authority claim is signed as part of the closed mandate and is not selectively disclosable; digests are for verifiers, not for people
Unenforced paths The agent reaches the same system of record through a connector that PAVREN Enforce does not sit in front of A path without enforcement is a path without authority. PAVREN Enforce protects only the paths where it is integrated, so the agent holds no credential that works anywhere else: tokens are audience-restricted to enforced endpoints and bound to the agent's key, and every connector in the agent register is either behind Enforce or unable to produce a material effect

The last row sets the limit of any claim made on the basis of this crosswalk. An organization can state that an agent acts within its authority only for the paths where that authority is actually checked.

Interoperability path

PAVREN does not ask anyone to adopt a new pipe. It proposes to carry legitimate authority through the pipes the industry is already standardizing. Its machine-readable layer, with JSON-LD, JSON Schema, SHACL, OpenAPI and SQL artifacts and a CF0–CF5 conformance corpus published under the Apache License 2.0, makes that practical.

PAVREN proposes four concrete steps:

  1. An envelope-to-mandate profile. Express the limits of an Authorized Envelope as constraints on AP2 open mandates and as an authority reference on closed mandates, so that a mandate can only be signed within the signer's authority.

  2. An authority reference next to the actor claim. Carry a stable reference to the applicable Authorized Envelope, as an RFC 9396 authorization details entry, alongside the act claim of an on-behalf-of token, so that any relying party can verify the authority behind the delegation.

  3. An authority check at the decision point. Offer PAVREN's authority-chain validation as a policy input to decision points that follow the AuthZEN interface, without changing how they enforce; PAVREN's four outcomes travel as AuthZEN decisions, with their reasons in the decision context.

  4. Shared evidence. Map PAVREN's evidence records to protocol audit trails, so that a single action can be traced from the authority that allowed it to the mandate that carried it.

These are proposals open for discussion. PAVREN invites the OpenID Foundation's AI identity community, the Loyal Agents initiative, AP2 contributors, payment-network implementers and public institutions to test them together, starting with pilots where authority, not only authenticity, decides the outcome.

The specification, the machine-readable layer and the free first-aid kit are available at pavren.org.

References