{
 "slug": "mastercard-verifiable-intent-vs-manav-deconstructing-sd-jwt",
 "topic_id": "TOPIC-018",
 "cluster": "Agentic Commerce & MCP Tool-Call Gating",
 "tier": "Tier A",
 "title": "Payment envelopes versus rendered statements: two models of agent intent",
 "summary": "Selective-disclosure JWTs bound what an agent may spend. They are well designed for that and they do not generalise to actions that are not payments — which is most of what agents do.",
 "lede": "A payment mandate answers a bounded question well: may this agent spend this much, here, within this window. The question enterprises actually face is broader, and the envelope model does not stretch to cover it.",
 "date": "2025-12-28",
 "category": "Comparison",
 "author_id": "desmond-okafor-hale",
 "tags": [
  "SD-JWT",
  "payment mandates",
  "selective disclosure",
  "agent payments",
  "comparison",
  "verifiable credentials"
 ],
 "image_title": "Payment Envelopes Versus Rendered Statements",
 "schema": "Article",
 "key_takeaways": [
  "Selective disclosure solves a genuine privacy problem in payments: proving a constraint without revealing the underlying value.",
  "The envelope model binds payment parameters. Actions that are not payments — recipient changes, permission grants, data exports — fall outside it.",
  "Rendering the whole effect covers the general case at the cost of privacy properties selective disclosure provides. Neither is strictly better."
 ],
 "body": [
  {
   "type": "h2",
   "text": "What SD-JWT actually provides"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "An agent adds a beneficiary, changes bank details, schedules a payment and grants access; only the payment is inside the mandate",
   "caption": "Four steps. The mandate covers one of them, and it is not the one that causes the loss.",
   "nodes": [
    {
     "label": "Add a beneficiary record",
     "note": "outside the envelope",
     "bad": true
    },
    {
     "label": "Change its bank details",
     "note": "outside the envelope",
     "bad": true
    },
    {
     "label": "Schedule a payment",
     "note": "inside the mandate",
     "good": true
    },
    {
     "label": "Grant a second agent access",
     "note": "outside the envelope",
     "bad": true
    }
   ]
  },
  {
   "type": "p",
   "html": "Selective disclosure lets a holder present a credential while revealing only some of its claims, and lets a verifier check a predicate without learning the value behind it. In payments this is genuinely useful: a merchant can confirm an agent is authorised up to a limit without learning the limit."
  },
  {
   "type": "p",
   "html": "The mechanism is sound and the privacy benefit is real. Nothing below disputes that."
  },
  {
   "type": "h2",
   "text": "The two models side by side"
  },
  {
   "type": "table",
   "caption": "Design comparison, not a scorecard",
   "head": [
    "Property",
    "Payment envelope (SD-JWT)",
    "Rendered statement"
   ],
   "rows": [
    [
     "Signed content",
     "Payment constraints: amount ceiling, merchant scope, validity window",
     "The canonical form of the action as shown to the human"
    ],
    [
     "Scope",
     "Payments",
     "Any action expressible as structured data"
    ],
    [
     "Privacy",
     "Strong — claims disclosed selectively",
     "Weaker — the verifier sees the whole statement"
    ],
    [
     "Granularity",
     "A bounded class of payments",
     "One specific effect"
    ],
    [
     "Verifier needs",
     "Issuer trust anchor, disclosure handling",
     "Issuer JWKS, canonicalisation"
    ],
    [
     "Fits existing rails",
     "Well — designed into payment flows",
     "Requires an approval step in the application"
    ]
   ]
  },
  {
   "type": "p",
   "html": "Read the privacy row carefully. The rendered-statement model is worse on privacy, and that is a real cost rather than a rhetorical concession. Where selective disclosure fits the problem, it is the better tool."
  },
  {
   "type": "h2",
   "text": "Where the envelope stops"
  },
  {
   "type": "p",
   "html": "Consider a sequence an agent might perform in an accounts-payable system."
  },
  {
   "type": "ol",
   "items": [
    "Add a new beneficiary record.",
    "Update the bank details on that record.",
    "Schedule a payment to it.",
    "Grant a second agent access to the payment queue."
   ]
  },
  {
   "type": "p",
   "html": "Step three is a payment and sits inside the envelope. Steps one, two and four are not payments and sit outside it entirely — and steps one and two are where the loss originates. A mandate that bounds the payment perfectly does nothing about the beneficiary that should never have existed."
  },
  {
   "type": "p",
   "html": "This is not a flaw in the specification. It is a scope boundary, and it is stated in the specification. The problem is deployment: enterprises adopt a payment mandate and believe they have covered agent authorisation."
  },
  {
   "type": "h2",
   "text": "What the rendered model does differently"
  },
  {
   "type": "code",
   "text": "# The envelope binds parameters of a payment\n{ \"max_amount\": 5000, \"currency\": \"USD\",\n  \"merchant\": \"acme-supplies\", \"not_after\": \"2026-07-31\" }\n\n# The statement binds an effect, whatever kind it is\n{ \"action\": \"beneficiary.bank_details.update\",\n  \"beneficiary\": \"Acme Supplies Ltd\",\n  \"account_from\": \"****4417\", \"account_to\": \"****9023\",\n  \"routing\": \"021000021\", \"effective\": \"immediate\" }\n# digest = SHA-256(JCS(statement)) — signed by the human who saw it"
  },
  {
   "type": "p",
   "html": "The second object is not a payment and has no natural home in a payment mandate. It is also the object that matters most, because a changed bank detail redirects every future payment regardless of how well each individual payment was authorised."
  },
  {
   "type": "h2",
   "text": "How they compose"
  },
  {
   "type": "p",
   "html": "The honest answer is that these are complementary rather than competing, and the sensible architecture uses both."
  },
  {
   "type": "table",
   "head": [
    "Action type",
    "Appropriate mechanism"
   ],
   "rows": [
    [
     "Routine agent purchase within a budget",
     "Payment mandate — bounded, private, low friction"
    ],
    [
     "Change to payment instructions",
     "Rendered statement — the effect is what matters and privacy is not the constraint"
    ],
    [
     "Permission grant to another agent",
     "Rendered statement — outside any payment envelope"
    ],
    [
     "High-value one-off transfer",
     "Rendered statement, with the mandate as an outer bound"
    ]
   ]
  },
  {
   "type": "p",
   "html": "An organisation that treats the mandate as its whole agent-authorisation story has covered one row of that table."
  },
  {
   "type": "h2",
   "text": "Questions worth asking a vendor"
  },
  {
   "type": "ol",
   "items": [
    "Which actions does this cover, and which does it explicitly not cover?",
    "What was displayed to the human at authorisation, and is it derived from the signed object or written separately?",
    "Can a third party verify a presented credential without calling your service?",
    "What happens to actions taken in the same session that fall outside the envelope?"
   ]
  },
  {
   "type": "p",
   "html": "The fourth question is the one that surfaces the gap, and it is rarely on a vendor's slide."
  },
  {
   "type": "h2",
   "text": "Where we are wrong"
  },
  {
   "type": "p",
   "html": "The rendered-statement model trades privacy for generality, and in retail payment contexts that trade is often the wrong way round. A consumer buying from a merchant has a legitimate interest in the merchant not learning their spending limits, and selective disclosure serves that interest in a way rendering does not."
  },
  {
   "type": "p",
   "html": "The argument here is about scope, not about superiority. Use the envelope where the action is a payment and privacy matters. Use the statement where the action is an effect that a human must be accountable for."
  },
  {
   "type": "h2",
   "text": "The privacy property, stated fairly"
  },
  {
   "type": "p",
   "html": "Selective disclosure lets a holder prove a constraint without revealing the value behind it. A merchant can confirm an agent is authorised up to a limit without learning the limit. That is a genuine benefit, it is the right tool for retail payments, and the rendered-statement model is worse on exactly this axis."
  },
  {
   "type": "table",
   "caption": "Where each model is the better fit",
   "head": [
    "Action",
    "Better mechanism",
    "Why"
   ],
   "rows": [
    [
     "Routine agent purchase inside a budget",
     "Payment mandate",
     "Bounded, private, low friction"
    ],
    [
     "Change to payment instructions",
     "Rendered statement",
     "The effect is the point; privacy is not the constraint"
    ],
    [
     "Permission grant to another agent",
     "Rendered statement",
     "No payment envelope contains it"
    ],
    [
     "High-value one-off transfer",
     "Rendered statement, mandate as outer bound",
     "Both properties wanted"
    ]
   ]
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“The mandate can be extended to cover other actions.”</strong> In principle any structured constraint can be signed. In practice these specifications are scoped to payments, and extending one to the general case means rebuilding it as a general case."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Rendering leaks data.”</strong> It does. The verifier sees the statement. Where that is unacceptable, selective disclosure is the better fit — this is a real trade, not a rhetorical concession."
  },
  {
   "type": "p",
   "html": "The question that surfaces the gap, and rarely appears on a vendor slide: what happens to actions taken in the same session that fall outside the envelope?"
  }
 ],
 "faq": [
  {
   "q": "Is SD-JWT the wrong technology?",
   "a": "No. Selective disclosure solves a real privacy problem well. The limitation is that payment envelopes bind payment parameters, and most consequential agent actions are not payments."
  },
  {
   "q": "Can a mandate be extended to cover non-payment actions?",
   "a": "In principle any structured constraint can be signed. In practice payment mandate specifications are scoped to payments, and extending them means rebuilding the general case."
  },
  {
   "q": "Which should we deploy?",
   "a": "Both, for different action classes. Mandates for bounded agent spending, rendered statements for changes to payment instructions, permissions and other irreversible effects."
  },
  {
   "q": "Does the rendered model leak data?",
   "a": "The verifier sees the statement. Where that is unacceptable, selective disclosure is the better fit — this is a genuine trade-off rather than a concession."
  },
  {
   "q": "Where does the loss usually start?",
   "a": "With the beneficiary record and its bank details — created or changed before any payment is scheduled, and outside every payment envelope."
  }
 ],
 "sources": [
  {
   "t": "IETF SD-JWT — Selective Disclosure for JWTs",
   "u": "https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/"
  },
  {
   "t": "Visa — security and trust perspectives on agentic commerce",
   "u": "https://corporate.visa.com/en/sites/visa-perspectives/security-trust.html"
  },
  {
   "t": "RFC 8785 — JSON Canonicalization Scheme",
   "u": "https://www.rfc-editor.org/rfc/rfc8785"
  },
  {
   "t": "W3C Verifiable Credentials Data Model 2.0",
   "u": "https://www.w3.org/TR/vc-data-model-2.0/"
  }
 ],
 "related": [
  {
   "slug": "fido-alliance-agentic-authentication-inside-race-standardize-verifiabl",
   "title": "Standardising verifiable user instructions",
   "category": "Future of Work"
  },
  {
   "slug": "consumer-mandate-receipt",
   "title": "Visa made cardholders responsible for their agents",
   "category": "Vertical"
  },
  {
   "slug": "account-masking-ap-systems-directly-enables-wire",
   "title": "Account masking in AP systems",
   "category": "Vertical"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Payment%20Envelopes%20Versus%20Rendered%20Statements/1500_900/blog.jpg",
 "wordcount": 1070,
 "url": "/blog/mastercard-verifiable-intent-vs-manav-deconstructing-sd-jwt.html",
 "reading_time": "5 min read",
 "seo_title": "Payment envelopes versus rendered statements",
 "meta_description": "Selective-disclosure JWTs bound what an agent may spend. They do not generalise to actions that are not payments, which is most agent activity.",
 "hub": {
  "slug": "topics/agent-tool-call-gating",
  "title": "Agent tool-call gating"
 },
 "answer": "No. Selective-disclosure JWTs, as used in card-network agentic payment mandates, bind payment parameters: a ceiling, a merchant scope, a validity window. Adding a beneficiary, changing bank details or granting another agent access are not payments, sit outside the envelope, and are usually where the loss originates.",
 "answer_q": "Do payment mandates cover everything an AI agent does?",
 "entities": [
  {
   "name": "Mastercard",
   "type": "Organization",
   "url": "https://www.mastercard.com/",
   "primary": true
  },
  {
   "name": "SD-JWT",
   "type": "Thing",
   "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/"
  }
 ],
 "glossary": [
  {
   "term": "Selective disclosure",
   "def": "Presenting a credential while revealing only some claims, so a verifier can check a predicate without learning the underlying value."
  },
  {
   "term": "Payment mandate",
   "def": "A signed envelope bounding what an agent may spend: ceiling, merchant scope, validity window."
  },
  {
   "term": "Rendered statement",
   "def": "The canonical form of a specific action as it was displayed to the human, hashed and signed, so the effect rather than the class is what was authorised."
  }
 ],
 "checklist": {
  "title": "Questions for an agentic payment vendor",
  "id": "vendor",
  "desc": "Four questions that map the boundary of what a mandate covers.",
  "steps": [
   {
    "name": "Which actions does this cover, explicitly?",
    "text": "And which does it explicitly not cover. Get the second list too."
   },
   {
    "name": "What was displayed at authorisation?",
    "text": "And is that display derived from the signed object, or written separately?"
   },
   {
    "name": "Can a third party verify without calling you?",
    "text": "If not, the mandate is evidence only while you are a customer."
   },
   {
    "name": "What covers the non-payment actions?",
    "text": "Beneficiary creation, bank detail changes and permission grants are where the loss starts."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav signs the rendered effect, whatever kind of action it is, and the executing service recomputes the digest before acting. It sits under a payment mandate rather than replacing it: the mandate bounds the spend, the receipt covers the change that redirects it.",
  "href": "../docs.html",
  "label": "See statement binding"
 }
}