Saifuro LLC

Sheridan WY United States of America ithelia.dias@saifuro.com https://saifuro.com

agent payment authorization JWT verdict When a software agent initiates a payment on behalf of an organization, the party that settles the payment usually cannot see the policy under which it was permitted. This document describes a signed authorization verdict: a JSON Web Token, signed with ES256, that records the outcome of evaluating one payment request, including its amount, currency, and recipient, against a spending policy that the organization configured. A party holding the issuer's published public key can verify a verdict without contacting the issuer. The document describes the claim set, key publication and rotation, and a verification procedure, and states what a verdict does not assert. It describes the format as one implementation issues it, including the points where it departs from JSON Web Token Best Current Practices (RFC 8725). It is offered as input to IETF discussion of authorization records for agent-initiated actions and is not a proposal for standardization. Discussion Venues Comments are welcome by email to the author. Whether signed authorization decisions are in scope for the work proposed for a potential AUDIT BoF can be discussed on the audit@ietf.org list .

Introduction Three properties of an agent-initiated payment can be checked separately: which agent initiated it, whether it was within the authority the agent was given, and whether value moved. The first and third are the subject of active protocol work (). The second is usually decided inside the operator's own systems or a provider's, and the decision does not travel with the payment. This document describes a verdict: a signed statement, valid for a short time, that names the request it was made about, the mandate it was checked against, if any, and the outcome of the check. A party asked to settle the payment can check a verdict without contacting the issuer, using the issuer's published keys, its own record of the payment, a record of the verdicts it has already accepted, and, where the payment draws on a particular operator's funds, the mandate identifiers and amount unit agreed with that operator (). Refusals produced by policy evaluation are signed in the same way as approvals; an operator's refusal of a request held for review produces no verdict (). This document is descriptive. It records the format that one implementation issues (), including the points where the format departs from and other properties the author considers weaknesses (, ). It is offered as input to IETF discussion of authorization records for agent actions, such as the discussion on the audit mailing list of a potential AUDIT BoF and working group charter; in particular, and state, for one deployed format, what a successful check establishes and what it does not. The author does not ask for this format to be adopted; a standard format in this area would need to resolve the issues in and might not be compatible with this one. The author is the founder of Saifuro LLC, which operates the implementation described here, and has a commercial interest in this area.

Scope In scope are the verdict format (), the publication of verification keys (), and the procedure a relying party follows before it relies on a verdict (). Out of scope are: the language in which spending policy is expressed; how an agent authenticates to the issuer; user consent; how a payment is executed or settled; how a verdict is carried inside a particular payment protocol; and the identity of an agent beyond an identifier assigned by its operator. The issuer described here does not hold or move funds, and a verdict is not a payment instrument.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here. In this document, BCP 14 key words state what a relying party has to do to rely safely on verdicts in this format. In Table 2, and where says that members are REQUIRED, they state what a verdict contains: a verifier rejects a token in which a required claim or member is absent (, steps 4 and 6). , , and also address operators and others that carry or keep verdicts. The key words do not define requirements for other issuers or formats.

Terminology

Operator:

The organization that runs an agent and configures the authority it has to spend.

Agent:

Software that proposes payments on an operator's behalf.

Mandate:

An operator-configured policy object at the issuer that limits what one agent may spend. In the deployed implementation it holds a per-transaction limit and an optional rolling 30-day limit in one currency, a list of allowed categories, an expiry date, an optional review threshold, and the name of the principal expected to approve reviews (). It does not restrict recipients. Mandates are not edited, only revoked and replaced. A mandate in this sense is not the same object as the mandates of , and it is not a credential signed by a user.

Environment:

One of the issuer's separately keyed instances, test ("sandbox") or production. Each operator has its own agents and mandates in each.

Issuer:

The service that evaluates a payment request against the operator's mandates and signs the result; in the terminology of , a policy decision point.

Verdict:

The signed token defined in . "Verdict code" means the value of its verdict claim.

Relying party:

The party that is about to settle, ship, or release funds on the strength of a verdict: for example a seller, a payment service provider, or an escrow release process.

Verifier:

The component of a relying party that performs .

Payment record:

The relying party's own record of the payment it is about to settle: amount, currency, and recipient. It comes from the relying party's systems, never from the token.

Names of claims, members of request, and header parameters that this format or its event tokens () use are written without quotation marks (iss, request.amount, kid); values, and names that the format does not use, are written in quotation marks ("ES256", "allow", "aud").

Related Work Several specifications address agent-initiated payments, or authorization decisions in general, at different points: when a user authorizes a purchase or delegates authority to an agent (), when a payment credential is handed to a merchant's payment service provider (), on individual requests (, , ), and when authorization is requested or decided (, ). Not all of them define a signed object. The descriptions below are based on the cited public specifications as accessed on 7 October 2026, and on 9 October 2026 for .

OAuth 2.0 Rich Authorization Requests :

A client requests fine-grained authorization, for example to initiate a single payment, from an authorization server, usually with the resource owner's consent, and presents the resulting access token to a resource server that trusts that authorization server. A verdict is not an access token: it records the outcome of a policy evaluation, including refusals, and is meant to be checked by a relying party whose only relationship with the issuer is holding its public keys.

Transaction Tokens :

Carry user identity, workload identity, and authorization context between workloads within a single trust domain. A verdict is meant to be verified outside the issuing organization, by a party that does not share its trust domain.

OpenID AuthZEN Authorization API 1.0 :

Defines how a policy enforcement point asks a policy decision point for a decision, which is returned as JSON. It permits a decision point to sign its response (Section 11.6 of ) but does not define a signed response format. A verdict can be read as a signed decision about a payment, meant to be verified further downstream than the enforcement point that requested it.

Agent Payments Protocol :

Carries the user's authorization as signed mandates that the merchant, the credential provider, and the payment network verify. A verdict instead carries the result of an evaluation performed by the issuer against the operator's policy, without disclosing the policy. It carries no user consent and can accompany such mandates without replacing them.

Agentic Commerce Protocol :

In its delegated payment specification, the agent platform sends a payment credential to the merchant's payment service provider with a single-use allowance (a maximum amount, a currency, a checkout session, a merchant, and an expiry), and the provider restricts the resulting token to that allowance. A verdict is a separate token that the relying party verifies itself before settlement.

x402 :

The client signs a scheme-specific payment authorization, and the resource server verifies and settles the payment, either itself or through a facilitator. That signature is the payer's authorization of the transfer. A verdict authorizes no transfer; it is a statement by a third party about a policy evaluation, signed by neither the payer nor the payee.

HTTP Message Signatures , Web Bot Auth , and Trusted Agent Protocol :

Let a server authenticate an automated client's HTTP requests. profiles HTTP Message Signatures so that a merchant can recognize an agent's requests using public keys that the payment network publishes, and adds signed objects that identify the consumer and carry payment data. A verdict identifies neither the agent's software nor the consumer; it states the outcome of a policy evaluation.

Auditing and transparency:

describes an architecture for auditing agent delegation and interactions; a verdict is one kind of record such an architecture could carry or reference. describes registering signed statements with a transparency service that issues receipts, using COSE rather than JOSE. It addresses long-term verification, which this format leaves to each party that stores its own copy of the JWK Set (, ).

PACT :

Uses the term "Verdict" for a different object: a signed record in which an evaluator judges whether work an agent delivered under a task contract passes or fails. PACT does not address payments or their authorization, and the two formats are unrelated apart from the term.

Overview

Issuing and checking a verdict Agent Issuer Relying Party | | | | (1) request | | |------------------>| | | | (2) evaluate against | | | the mandates | | (3) verdict (JWS) | | |<------------------| | | | | | (4) payment, verdict attached | |------------------------------------------->| | | (5) JWK Set (cached) | | |<-----------------------| | |----------------------->| | | | (6) verify, | | | compare with | | | payment record

1. The agent sends a payment request, stating amount, currency, recipient, and category, to the issuer.
2. The issuer evaluates the request against the agent's mandates and records the decision.
3. The issuer returns the decision, including a verdict. A verdict is issued for every evaluated request, whatever the outcome.
4. The agent, or a component acting for the operator, presents the verdict to the relying party together with the payment.
5. The relying party obtains the issuer's JWK Set, normally from its cache.
6. The relying party verifies the verdict and compares it with its payment record ().

The relying party needs no account with the issuer and sends it no request about individual verdicts: from the issuer it needs only the published JWK Set. It also needs its own payment record, its store of accepted nonces, and, for step 8 of , the mandate identifiers and the amount unit it has agreed with the operator. collects the values that this document refers to: those of the deployed implementation, and those this document sets for verifiers. Values referred to in this document

Value	Setting
Verdict lifetime (exp - iat)	300 seconds
Clock skew allowed to verifiers	at most 60 seconds
Review expiry	24 hours
Frequency rule	10 decisions per agent in 60 seconds
Window of the rolling limit	30 days
JWK Set cache lifetime (max-age)	300 seconds
Refetches on unknown kid	at most one per 30 seconds (recommended)
Pre-publication of a new key	at least 1 hour
Retention of a retired key	at least 25 hours after its last token
Redelivery of event tokens	last retry due 24 hours after creation
Identifier prefixes	"dec_", "mnd_", "n_", "agt_", "evt_"
Nonce	64 random bits
Amount	greater than 0, less than 10^15, at most 6 fractional digits
Idempotency-Key retention	24 hours
API request body limit	64 KB
Length of recipient; of category and currency	at most 1,024 characters; at most 128 characters each

Verdict Format

Serialization, Header, and Signature A verdict is a JSON Web Token (JWT) in JWS Compact Serialization : three base64url segments without padding, separated by periods. The issuer emits exactly three header parameters: alg, with the value "ES256" (ECDSA using P-256 and SHA-256, ); typ, with the value "JWT"; and kid, naming the signing key in the issuer's JWK Set (). It does not emit "crit", "jku", "jwk", "x5u", "x5c", "x5t", "cty", or any other header parameter. The typ value does not distinguish a verdict from other tokens signed with the same key (). The signature is the 64-byte concatenation of R and S, each 32 bytes, big-endian, as requires, not an ASN.1 DER encoding. The issuer uses randomized ECDSA () and does not normalize S (). The payload is a JSON object encoded in UTF-8 . The issuer writes it without insignificant whitespace and in the member order of . Verifiers MUST NOT depend on member order, whitespace, or string escaping.

Claims Verdict claims

Claim	Type	Presence	Meaning
iss	string	REQUIRED	Issuer identifier.
jti	string	REQUIRED	Identifier the issuer assigns to the decision. Unique per verdict.
iat	integer	REQUIRED	Time of the decision; for an "allow" that approves a review, the time of the approval.
exp	integer	REQUIRED	Expiry, on every verdict whatever its code.
verdict	string	REQUIRED	Verdict code ().
mandate	string	see	Identifier of the mandate whose evaluation produced the verdict.
policy_version	string	REQUIRED	Per-operator label; opaque to verifiers.
nonce	string	REQUIRED	Random value generated for each verdict; the replay key (, step 12).
request	object	REQUIRED	The payment request that was evaluated ().
supersedes	string	see	The jti of the "review" verdict that this "allow" resolves.

In Table 2 and in step 6 of , "integer" means a JSON number whose value is an integer; the issuer writes such values with no fraction or exponent part. This narrows NumericDate (), which also allows non-integer values. In the deployed implementation, policy_version is assigned once per operator and is not updated when mandates change; despite its name, it does not identify the rules that were applied. Because mandates are not edited, the mandate claim identifies the limits that were evaluated. Verifiers MUST treat policy_version as an opaque string. The nonce is 64 random bits in the deployed implementation; jti is enforced unique by the issuer. The claims iss, jti, iat, and exp are used with their registered meanings (). The claim nonce is registered in the IANA "JSON Web Token Claims" registry by ; updated the registration to state that it may also be used for nonce values in other applications of JWTs, and it is used here in that sense, as a non-repeating value used to detect replay. Unlike the nonce of and , which is supplied by the party that later checks the token, this nonce is chosen by the issuer, so it gives the relying party no assurance of freshness beyond exp. The claims verdict, mandate, policy_version, request, and supersedes are Private Claim Names () and can collide with other uses of the same names (). Apart from the "sandbox-" prefix of kid (step 3 of ) and the "evt_" prefix of jti (step 6), verifiers SHOULD treat identifiers as opaque strings. Verifiers MUST ignore private claims, and members of request, that they do not understand (). Registered claims that verdicts do not carry are processed as specifies: a verdict carrying "aud" is rejected unless the verifier identifies itself with one of its values (), and one carrying "nbf" is rejected before that time ().

The request Claim Members of the request claim

Member	Type	Meaning
agent	string	Identifier of the agent, unique among one operator's agents in one environment.
amount	number	Amount evaluated ().
currency	string	Currency or asset code, exactly as the request stated it. When the mandate claim is present, it equals that mandate's currency.
recipient	string	Payee identifier, exactly as sent in the request.
category	string	Spending category, exactly as sent in the request.

All five members are REQUIRED. The issuer matches currency against the mandate's currency by exact, case-sensitive comparison, and does not normalize the value or restrict it to a list of codes. The issuer's documentation uses uppercase ISO 4217 codes such as "USD", and "USDC" for an asset that has no ISO 4217 code. Other specifications use other forms, for example lowercase codes and integer minor units in ; a relying party that holds its payment record in another form converts the currency code to this form, and the amount to the unit agreed with the operator (; , step 8), before steps 9 and 10 of ; that conversion is part of its own code. The format of recipient is agreed between the operator and the relying party; examples are "vendor:acme_saas" and a wallet address. The issuer does not check it against the identity of any party (). In the deployed implementation's test environment, creating an escrow is also evaluated. Such a verdict carries the escrow's seller as recipient and the fixed category "escrow", and the evaluation skips the category check.

Presence by Verdict Code Conditional claims

Verdict code	mandate	supersedes
allow, from an evaluation	present	absent
allow, from approving a review	present	present
review	present	absent
deny_limit, deny_velocity, deny_category, deny_expired, deny_revoked	present	absent
deny_no_mandate	absent	absent

Verdict Codes Verdict codes

Code	Meaning
allow	The request passed every check in this table, or it was held for review and the operator approved it (). The only code on which a relying party may settle.
review	The amount is above the mandate's review threshold, and the operator must approve or deny the request. Not an approval.
deny_limit	The amount exceeds the per-transaction limit, or, together with the amounts allowed under the same mandate in the previous 30 days, the rolling 30-day limit.
deny_velocity	The agent already had 10 or more decisions in the previous 60 seconds.
deny_category	The category is not one of the mandate's allowed categories.
deny_expired	The mandate is past its expiry date.
deny_revoked	The mandate has been revoked.
deny_no_mandate	The agent is not active, holds no mandate, or holds no mandate in the requested currency.

For each of the agent's mandates in the requested currency, the checks run in this order: revoked, expired, category, per-transaction limit, rolling 30-day limit, frequency rule, review threshold. When the agent holds several such mandates, they are evaluated in order of creation, and the verdict is the first "allow", otherwise the first "review", otherwise the result for the oldest mandate. These checks are the whole of the evaluation; in particular, a mandate does not restrict the recipient (). A relying party MUST treat every code other than "allow", including codes this document does not define, as "do not settle". When the operator approves a review, the issuer issues a new verdict with the code "allow", its own nonce and expiry, and a supersedes claim naming the "review" verdict (). The "review" verdict is not modified. A review that the operator denies, or that expires, produces no verdict. An operator records, per environment, a mode of "observe" or "enforce", which tells its own systems whether to block payments that are not allowed; the issuer blocks nothing in either mode. In the deployed implementation, a production environment is in observe mode until the operator changes it. The issuer evaluates, records, and signs the same verdicts in either mode, and the mode is not in the token, so a signed refusal does not show that a payment was blocked.

Amounts request.amount is a JSON number in the same units as the mandate's limits. The issuer does not interpret or convert units; its documentation uses major units, so that 340 with currency "USD" means 340 US dollars, not 340 cents. The amount is greater than zero and less than 10^15, and has at most six fractional digits. The issuer writes it in minimal fixed-point form: an integral amount has no decimal point (340, never 340.00), other amounts have no trailing zeros (340.5, never 340.50), and the issuer never uses exponent notation or leading zeros other than the single 0 before the decimal point of an amount below 1 (0.5). Amounts can therefore carry up to 21 significant digits, more than an IEEE 754 binary64 number holds. This departs from , which says that I-JSON messages should not include such numbers and recommends JSON strings for them. Many JSON parsers, including those inside common JWT libraries, read every number as binary64, and from 2^33 (about 8.6 x 10^9) upward two amounts that differ in the sixth fractional digit can map to the same binary64 value; 8589934592.000001 and 8589934592.000002 do. A verifier therefore compares amounts by decimal value (, step 9). Nothing in the token states the unit. An operator that configures a mandate in minor units obtains verdicts whose amounts are in minor units, and a relying party that compares them with a payment record in major units (, step 9) would match a verdict evaluated for 340 cents against a payment of 340 US dollars. Step 8 of therefore includes agreeing the unit with the operator.

What the Token Does Not Contain The issuer keeps information about each decision that is not in the token and is therefore not signed. The decision record it returns to the operator contains the enforcement mode (), a human-readable reason, operator metadata such as order references, and, for a "review" verdict, the review identifier and the principal it waits for. The issuer also stores, but neither signs nor returns in the decision record, the payment protocol named in the request. A verdict is therefore not bound to an order, and a verdict evaluated for one payment protocol can be presented on another. The token has no "aud", "sub", "nbf", or "cnf" claim, and no claim that identifies the operator (, , ).

Key Publication

JWK Set The issuer publishes its public keys as a JWK Set (). Each key has "kty" "EC", "crv" "P-256", "x", "y", "use" "sig", "alg" "ES256", and a "kid". The deployed implementation serves the set over HTTPS with "Cache-Control: public, max-age=300" and "Access-Control-Allow-Origin: *", with the media type "application/json" rather than "application/jwk-set+json" ().

Locating the JWK Set The deployed implementation publishes its JWK Set at the path "/.well-known/jwks.json" under its issuer identifier, https://verdicts.saifuro.com (), and keeps an older location that permanently redirects to it. The suffix "jwks.json" is widely used but is not registered in the Well-Known URIs registry; serving the set under it departs from , which requires registration, and this document does not register it (). A relying party MUST take the list of issuers it accepts, and the JWK Set location for each, from its own configuration, and MUST fetch each set over HTTPS with certificate validation. It MUST NOT fetch keys from a location derived from a token. Otherwise any party can mint verdicts that verify against keys it publishes itself. A verifier SHOULD NOT follow HTTP redirects when fetching a JWK Set, since a redirect moves the source of its keys to a location that is not in its configuration, and SHOULD bound the size of the response and the time it waits for it.

Test and Production Keys The deployed implementation operates a test environment and a production environment. Each has its own signing key, and both keys are published in the same JWK Set. The kid of a test key begins with "sandbox-"; the kid of a production key does not. The issuer identifier, the claim set, and the token shape are otherwise identical. Anyone with access to the test environment can obtain a correctly signed test "allow" for any recipient and amount, so a verifier rejects tokens whose kid begins with "sandbox-" unless it is used only for testing (, step 3; ).

Caching and Unknown Key Identifiers Verifiers SHOULD cache each JWK Set and refresh it when it is older than the max-age it was served with. If a refresh fails, a verifier MAY keep using the last copy it fetched successfully, SHOULD raise an alert, and SHOULD stop accepting verdicts once that copy is older than a bound it chooses: the longer it uses a stale copy, the longer a key the issuer has removed stays trusted (). The kid is untrusted input, used only as a lookup key, never in a file path, query, or URL (). On a kid that is absent from the cached set, a verifier fetches the set again once and looks again. Because anyone can send a token with any kid, these refetches MUST be rate-limited; an interval of at least 30 seconds between refetches triggered by unknown kids is RECOMMENDED, and scheduled refreshes SHOULD NOT count against that limit. Because the refetch is rate-limited, a stream of tokens with made-up kids can delay acceptance of a verdict signed with a key the verifier has not yet fetched; pre-publication () avoids that for verifiers that refresh on schedule. Pinning a single key in code is NOT RECOMMENDED: an integration that does so rejects valid verdicts after the next rotation.

Rotation The issuer's rotation procedure extends the approach of Section 10.1.1 of , in which a verifier refetches the set on an unfamiliar kid, with a period of pre-publication:

1. The issuer publishes the new key in the set at least one hour before it signs anything with it, so that every verifier that refreshes on schedule holds the key before the first token signed with it.
2. It switches signing to the new kid.
3. It keeps the previous key in the set for at least 360 seconds after the last verdict that key signed (the 300-second lifetime of a verdict plus the 60-second maximum clock skew allowed in ), and for as long as any event token it signed can still be delivered (). The deployed implementation's procedure keeps it for at least 25 hours after the last token of either kind.
4. It removes the previous key.

The deployed implementation has not yet rotated a key (), so this procedure has not been exercised. The set carries only keys that are about to be used, in use, or recently retired. A party that keeps verdicts as records, for audit or disputes, SHOULD store a copy of the JWK Set with them, so that the signatures can be checked after the key has been removed ().

Verification Procedure The inputs to verification are the token; the configured list of accepted issuers with the JWK Set of each; the current time from a synchronized clock; the payment record; a store of nonces from verdicts already accepted; whether the verifier is used only for testing; where step 8 requires them, the mandate identifiers agreed with the operator and the unit its mandates use; and, for the check of , a store of the supersedes values of verdicts already accepted. A relying party MUST apply every step below before it relies on a verdict, and MUST reject the token if any step fails. It MAY perform the steps in a different order, provided that it verifies the signature (step 5) before it relies on any claim, and records the nonce (step 12) only after every other step has passed. Every check MUST use values taken from the payload bytes whose signature step 5 verified. A verifier that parses those bytes more than once, for example with a JWT library for steps 4 and 7 and with a decimal-preserving parser for step 9, MUST reject a header or payload that contains duplicate member names at any depth, so that the parses cannot disagree about which member they read.

1. Parse. Bound the size of the token before decoding it (verdicts that the deployed implementation issues are shorter than 11,000 characters; ), and bound the nesting depth of JSON that is parsed before the signature is verified. Split the token into exactly three segments. Decode each as base64url without padding (), rejecting padding, whitespace, any character outside the base64url alphabet, and a segment whose length is 1 modulo 4; many base64 decoders accept these, so a verifier that uses one checks the segments itself. A verifier MAY reject a segment whose unused trailing bits are not zero. Decode the header and payload as UTF-8, rejecting invalid UTF-8 (). Each MUST parse as a JSON object. Header parameter and claim names MUST be unique: a verifier MUST either reject a header or payload with duplicate member names or use a parser that keeps only the lexically last one (, ), and SHOULD reject duplicates at any depth.
2. Header. The alg value MUST be exactly "ES256", compared case-sensitively (). The accepted algorithms MUST come from the verifier's configuration for the issuer, never from the token, and the key selected in step 4 MUST be one the verifier uses only with ES256 (). Reject a token that has a "crit" parameter (). The kid value MUST be a non-empty string. Keys MUST NOT be taken from "jku", "jwk", "x5u", or "x5c", and verifiers SHOULD reject tokens that carry them. Verifiers do not use typ to identify a verdict ().
3. Environment. Unless the verifier is used only for testing, reject a token whose kid begins with "sandbox-" ().
4. Issuer and key. The iss claim MUST equal, exactly, the identifier of an issuer in the verifier's configuration, compared as a case-sensitive string with no transformations or canonicalizations (). Find the key with the token's kid in that issuer's JWK Set, and only there: a verifier that accepts more than one issuer MUST NOT look up the kid in the union of their key sets. This is the binding of keys to an issuer that requires; iss is read before the signature is verified and is authenticated by step 5. The key MUST have "kty" "EC" and "crv" "P-256"; if it has "alg", the value MUST be "ES256"; if it has "use", the value MUST be "sig". If the kid is absent, refetch the set once under the rate limit of ; reject the token if the rate limit does not permit a refetch, if the kid is still absent, or if it appears more than once.
5. Signature. Verify the signature as ES256 (). The signature MUST be exactly 64 bytes. The verifier MUST reject a signature in which R or S is not an integer in the interval [1, n-1], where n is the order of the P-256 group (Section 4.1.4 of ); an implementation that omitted this check accepted an all-zero signature for any message (CVE-2022-21449; ). Verifiers MUST NOT require S to be in the lower half of the group order: the issuer does not normalize S, and such a check rejects about half of genuine verdicts. Use an implementation that validates that the public key is a point on P-256 ().
6. Token kind and structure. Reject a token whose payload has a type claim or whose jti begins with "evt_": it is an event token signed with the same key (). The jti claim MUST be a non-empty string. The iat and exp claims MUST be integers with exp greater than iat; a verifier MAY reject a token whose exp minus iat exceeds 300. The verdict claim, policy_version, and nonce MUST be non-empty strings. The request claim MUST be an object whose agent, currency, recipient, and category are non-empty strings and whose amount is a number greater than zero. The mandate and supersedes claims, when present, MUST be non-empty strings. If the verdict claim is "allow", mandate MUST be present. If supersedes is present, the verdict claim MUST be "allow". Reject a token that carries an "aud" claim unless the verifier identifies itself with one of its values ().
7. Time. With a clock skew allowance L of at most 60 seconds, reject the token if the current time is at or after exp + L (), or if iat is later than the current time + L. If the token carries an "nbf" claim, reject it while the current time + L is before the time in "nbf". Expiry does not change a verdict's code: an expired verdict is rejected whatever its code.
8. Decision and operator. Reject the token unless the verdict claim is "allow". If the payment draws on funds, credit, or an account of a particular operator, also reject it unless mandate is one of the identifiers that operator has agreed with the relying party (). Without this check, a verdict that passes every other step shows only that some operator configured a mandate that allows the payment, and any operator can do that for any recipient and amount. The relying party also agrees with that operator the unit in which its mandates state amounts (); where no particular operator is involved, nothing establishes the unit ().
9. Amount. Compare request.amount with the amount in the payment record, expressed in the unit agreed in step 8, if any, by decimal value: 340 equals 340.00, and 340 does not equal 340.5. Read the amount from the verified payload bytes with a JSON parser that preserves the literal number or yields a decimal type; most JWT libraries return claims in which numbers are already binary64. The issuer never writes an amount with an exponent, more than 15 digits before the decimal point, or more than 6 after it; a verifier SHOULD reject such an amount before converting it to a decimal type, wherever it first converts it (step 6 compares it with zero), since some decimal implementations take time or memory proportional to the exponent. Verifiers MUST NOT compare amounts as binary floating-point numbers, except that a verifier MAY compare binary64 values when both amounts are below 2^30 (about 1.07 x 10^9) and both have at most six fractional digits: in that range, distinct amounts with at most six fractional digits map to distinct binary64 values.
10. Currency. The member request.currency MUST equal the currency code in the payment record exactly, compared case-sensitively.
11. Recipient. The member request.recipient MUST equal the payee identifier in the payment record, compared code point for code point, with no Unicode normalization, case folding, or trimming. It names the payee, not the verifier, and binds the verdict to the relying party only when the relying party is the payee ().
12. Replay. Reject the token if the pair of iss and nonce is in the store of accepted nonces. Otherwise record the pair in the same atomic operation that accepts the token, and keep it at least until exp + L. All verifier instances that could accept the same token MUST share the store, and a verifier that cannot read or write the store MUST reject the token. The replay key is a claim value, never the token string (); jti is also unique per verdict, so recording jti instead of nonce gives the same protection. A relying party that applies checks and records the pair of iss and supersedes in the same atomic operation.

JWT libraries perform most of steps 1, 2, 4, and 5, and the exp and "nbf" checks of step 7, when they are configured with the algorithm list ["ES256"], the accepted issuer, and a clock tolerance of at most 60 seconds. Some libraries, such as jose, check "aud" only when an audience is configured. Implementers need to check what their library leaves out: a library that is handed a key object cannot check that key's "alg" and "use" members or whether its kid appears twice in the set, and some libraries accept padded or whitespace-broken segments. Steps 3, 6, 8, 9, 10, 11, and 12 are the relying party's own code, and so is the iat check of step 7 where the library does not perform it.

Matched, Contradicted, and Unsupported For each property of the payment record that the relying party relies on, verification has one of three outcomes:

Matched:

a signed claim covers the property and agrees with the payment record.

Contradicted:

a signed claim covers the property and disagrees with the payment record.

Unsupported:

no signed claim covers the property.

A contradicted property causes rejection, by steps 9 to 11. An unsupported property is neither evidence of a problem nor evidence of correctness: the relying party has to establish it independently. In this format, amount, currency, and recipient can be matched or contradicted. The members request.agent and request.category are signed, but the payment record has no corresponding property, so they can be neither matched nor contradicted. The operator behind the verdict is unsupported unless the relying party maps the mandate claim to an operator through identifiers agreed out of band (); the order, the payment protocol, and the identity of an intermediary relying party are always unsupported. A relying party SHOULD record which properties it took from its own records rather than from the signature, so that a later audit can tell the two apart.

Checking a Stored Verdict A party that checks a verdict as a record rather than to settle a payment, such as an auditor examining a refusal, applies steps 1, 2, 4, 5, and 6 using a copy of the JWK Set that contains the key (), and step 3 if it needs to distinguish test verdicts. It evaluates step 7 against the time at which the verdict was received if that time was recorded, and otherwise does not apply step 7; it does not apply steps 8 to 12. It does not refetch a key set for a stored verdict: a kid missing from the stored copy is a failure. Verdicts that the deployed implementation issued before 09:12 UTC on 9 October 2026 may lack request.currency, may contain Unicode noncharacters, and may be up to about 94,000 characters long; a party checking one of them as a record applies step 6 without the currency requirement, and step 1 with a size bound that admits them. Unless the party obtained the copy of the JWK Set itself, a successful check shows only that the verdict matches the key set that the record keeper stored ().

What a Verdict Asserts A verdict that passes steps 1 to 6 of is a statement, signed by the holder of the signing key, that it evaluated a payment request with the stated agent, amount, currency, recipient, and category against the named mandate (none, for "deny_no_mandate") and reached the stated verdict code. For a verdict without supersedes, iat is the time of that evaluation; for an "allow" that carries supersedes, the evaluation took place when the superseded "review" verdict was issued, some of its checks were repeated at approval, and iat is the time of the operator's approval (). The signature shows that the statement was made, not that it is correct (). In the terms used on the audit mailing list , a verdict is an attestation, not a record that a relying party can recompute: neither the mandate's limits nor the history behind the rolling 30-day limit is in it. A verdict does not show:

• that an end user consented: no user key is involved;
• that the operator or the agent authorized the payment: neither signs the token, so it is not evidence of either's authorization;
• that the operator approved the recipient ();
• that the category describes what is being bought: it is a label supplied with the request, and the relying party has nothing to compare it with;
• the unit of request.amount: the issuer does not interpret it, and an operator's mandates can use a different unit from the relying party's payment record ();
• that the named agent made the request: in the deployed implementation, a request made with an operator-wide credential names the agent in its body;
• which operator requested it, or that the operator is the party paying the relying party ();
• that the payment was made, settled, or delivered, or that funds exist;
• which payment protocol or order it was evaluated for ();
• whether the operator's systems block payments that are not allowed ();
• that the mandate is still in force when the verdict is verified: an "allow" remains valid until exp even if the mandate is revoked after it was issued, and the relying party has no way to learn of the revocation from the issuer;
• that the payment is not one of several, each within the per-transaction limit and below the review threshold, that together make up a larger purchase;
• that a collection of verdicts is complete: verdicts are returned only to the operator that requested them, through its API keys and webhook endpoints, and an operator's denial of a review produces no verdict.

Versioning and Extensibility The token carries no version number, and the format has no mechanism for signalling a change. Verifiers detect features by the presence of claims. An issuer can add private claims and members of request, which verifiers ignore if they do not understand them (), and verdict codes, which verifiers treat as "do not settle" (). Because verifiers ignore private claims they do not understand, a new private claim that narrows when a verdict may be relied on constrains only verifiers updated to check it; until every relying party checks it, a verdict carrying it is accepted where it was not meant to be. Adding "aud" is incompatible in the other direction: verifiers that apply without a configured audience reject every verdict that carries it. Adding either kind of claim is therefore an incompatible change, as are removing a claim and changing a claim's type or meaning. Explicit typing alone would not make such a version fail at verifiers built to this document, which do not check typ (, step 2); a new issuer identifier would (step 4). The deployed implementation announces changes that verifiers have to act on in its documentation , with the date from which they apply.

Implementation Status This section records the status of known implementations of the format described in this document at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". Note to the RFC Editor: please also remove the reference to .

Saifuro

Organization:

Saifuro LLC. The author is its founder and chief executive.

Description:

An authorization service for agent-initiated payments. It issues a verdict in the format of for every evaluated request, in a test environment and a production environment.

Issuer and keys:

Issuer identifier https://verdicts.saifuro.com; JWK Set at https://verdicts.saifuro.com/.well-known/jwks.json, served through a content delivery network and holding one production key and one test key.

Coverage:

and , with the departures from , , and stated in this document.

Version compatibility:

This document (-00). Verdicts issued since 09:12 UTC on 9 October 2026 carry request.currency; verdicts issued before then may lack it, and all of them have expired.

Implementation experience:

Limits are enforced atomically (). Approving a review repeats the checks described in . No key rotation has taken place yet. The event tokens of resemble Security Event Tokens but do not follow that specification.

Level of maturity:

Early deployment; in service since September 2026. Issuing verdicts requires an account with Saifuro. Verifying them requires no account.

Licensing:

Proprietary service. Verification uses unmodified open-source JOSE libraries. The public documentation gives starting examples for jose (JavaScript), PyJWT (Python), and jwx (Go); they do not implement every step of , and the documentation lists the main checks they leave to the relying party.

Documentation:

, .

Test vectors:

: 138 tokens with their expected results, covering each step of and , signed with the example key of and further published test keys.

Contact:

Ithelia Dias, ithelia.dias@saifuro.com.

Last updated:

9 October 2026.

Security Considerations The security considerations of , , and apply. , which would obsolete , states that a typ value of "JWT" is not effective explicit typing () and extends the audience requirement to issuers that may issue JWTs for more than one relying party in the future (); both widen the departures described in and .

Trust in the Issuer and Its Key Set A verdict proves that the issuer made a statement, not that the statement is correct. An issuer that is compromised, misconfigured, or acting in bad faith can sign approvals for requests outside any mandate. How a relying party decides to accept an issuer is outside the scope of this document. The JWK Set is not signed. Whoever can change what is served at its configured location, including through control of the domain, its DNS, certificate issuance, or a TLS-terminating intermediary such as a content delivery network in front of the server, can add a key and mint verdicts that every verifier accepts. Protecting that endpoint is equivalent to protecting the signing keys. A copy of the JWK Set kept with stored verdicts () is the relying party's own record; it is not evidence to a third party that a key belonged to the issuer, because the deployed implementation neither signs its JWK Set nor publishes a history of retired keys.

Who Stands Behind a Verdict A verdict is evidence about one operator's policy, not about the payer. The token names no operator, and any operator that the issuer serves can configure a mandate that allows any recipient and amount, and then obtain a valid "allow" under it. A relying party that needs to know which operator stands behind a payment agrees the mandate identifiers with that operator out of band and accepts only verdicts whose mandate claim is one of them (, step 8). In the deployed implementation, mandate identifiers are assigned by the issuer and are not reused. The policy_version claim is the same on every verdict of one operator and is shared only with operators whose accounts were created on the same day. It links verdicts to an operator without reliably identifying one, and relying parties MUST NOT use it as an operator identifier. The member request.agent is unique only among one operator's agents in one environment, and in the deployed implementation it is "agt_" followed by a name the operator chooses, so any operator can obtain verdicts that name the same agent identifier as another operator. Relying parties MUST NOT use request.agent to identify an operator or a payer; step 8 of uses the mandate claim for that.

Payee Substitution Mandates in the deployed implementation do not restrict recipients. An agent that is compromised or misled, or anyone holding its credentials, can obtain an "allow" for a recipient of its choosing within the mandate's limits, and a relying party controlled by that recipient finds that every step of passes. Verdicts therefore do not defend against payee substitution; an operator that needs that defence applies its own controls to the recipients its agents request. Restricting recipients in mandates is an open issue (). The issuer accepts as recipient (up to 1,024 characters) or category (up to 128) any non-empty string of Unicode characters other than noncharacters, including characters that render invisibly, reorder text, or resemble other characters, and an operator approving a review is shown the strings as the agent supplied them. An approval can therefore be obtained for a recipient that looks like another. Step 11 of does not help: it compares exactly, and the recipient that benefits is the one the token names.

Bearer Tokens A verdict is a bearer token. It is not bound to a key held by the agent or the operator, it has no "cnf" claim , and nothing in it identifies the party presenting it, the payer, or the order. Anyone who obtains an unused "allow" before it expires, such as the agent's runtime, an intermediary between the agent and the relying party, anyone who can read a log that recorded it, or a receiver of an event token that carries it (), can present it first, with a payment of the same amount and currency to the same recipient; the legitimate presentation then fails step 12 of . A relying party that releases goods, services, or funds on a verdict has to bind the order to the payer by its own means. Verdicts SHOULD be carried only over authenticated, confidential channels. Agents, operators, and relying parties SHOULD NOT log unexpired "allow" verdicts in full; jti or nonce identifies a verdict in a log without making it presentable. Proof of possession is an open issue ().

Algorithms and Signatures Only ES256 is used and accepted. Verifiers pin it in configuration and reject "none", every HMAC algorithm, including when a public key is offered as the HMAC secret, and any spelling that differs in case (, , ). Every key in the set is published with "alg" "ES256". says that JWT libraries should implement ECDSA using the deterministic approach of . The deployed issuer does not: it signs through OpenSSL 3.0, which derives the per-signature value from fresh random bytes mixed with the private key and the message digest. Its signatures are therefore not deterministic and do not reproduce the test vectors of ; the mixing is intended to keep a failure of the random number generator from exposing the key. Verifiers are unaffected: deterministic and randomized signatures verify identically.

Cross-JWT Confusion and Explicit Typing Verdicts and event tokens share the key, the issuer identifier, and the typ value "JWT", so requires a mitigation. This format uses the second strategy listed in , different required claims: a verdict requires exp, verdict, nonce, and request, which event tokens lack, and step 6 of rejects tokens that carry a type claim or an "evt_" jti. That step is the mutually exclusive validation rule that requires for verdict verifiers; it rests on claims rather than on the header. Event receivers that require type and data, which verdicts lack, complete the mutual exclusion. The format does not use explicit typing, which recommends for new kinds of JWT. With explicit typing, the distinction would rest on the header rather than on each verifier implementing step 6. Adopting it is an open issue (). Test and production verdicts are the same kind of JWT from different environments, and differ only in the signing key. The only rule that excludes test verdicts is step 3 of , which reads a prefix of kid. JOSE leaves the structure of kid unspecified (), so no generic JWT library applies this rule, and a relying party that omits step 3 accepts test verdicts. A verifier used only for testing does not reject production verdicts. A separate issuer identifier and JWK Set for test verdicts is an open issue ().

Audience Verdicts have no "aud" claim. requires one when an issuer issues JWTs intended for more than one relying party, which is the case here; this format does not meet that requirement. The same section requires a relying party to reject a JWT that has no audience value; a relying party that follows accepts verdicts without one, and so departs from that requirement as well. The member request.recipient is not an audience in the sense of : it names the payee, which the agent chooses and the issuer does not check. When the relying party is the payee, step 11 of rejects a verdict presented for any other payee. When the relying party is an intermediary acting for the payee, such as a payment service provider or an escrow release process, nothing in the token names it, and two intermediaries settling for the same payee run separate nonce stores and could each accept the same verdict within its lifetime. A relying party SHOULD make sure that the identifier it compares against is specific to it and not shared with other parties. Adding an audience claim is an open issue ().

Replay and Signature Malleability A verdict is valid for 300 seconds, and a relying party accepts its nonce only once (, step 12); relying parties that do not share a nonce store can each accept it (). ECDSA signatures are malleable: if (R, S) is a valid signature, so is (R, n - S), where n is the order of the P-256 group. A verifier whose base64url decoder ignores unused trailing bits also accepts several spellings of the same signature segment. The same signed claims can therefore appear in more than one token string, and verifiers MUST NOT use the token string, or a hash of it, as the replay key. A verifier that recorded the nonce before comparing the verdict with its payment record would let anyone with a copy of a verdict burn it by presenting a mismatched payment; this is why step 12 comes last. The deployed implementation supports idempotent retries: an operator that retries an authorization request with the same Idempotency-Key, the same request body, and the same API credential within 24 hours receives the stored response, with the identical token and nonce, so a retry does not produce a second approval. A retry after 24 hours is a new evaluation with a new nonce, and each "allow" counts toward the mandate's rolling 30-day limit.

Clock Skew With a 300-second lifetime and a 60-second skew allowance, a verifier accepts a verdict until its own clock reads iat + 360, and rejects an iat more than 60 seconds ahead of its clock. Step 7 of assumes a synchronized clock.

Key Compromise There is no per-token revocation. The short lifetime of a verdict bounds the use of a stolen verdict, and removal from the JWK Set is the response to a stolen key. A verifier that refreshes on schedule stops trusting a removed key within the max-age of the set; one that pinned the key, or that keeps using a stale copy, keeps trusting it for as long as it does so. A party holding a compromised signing key can mint verdicts with current timestamps until the key is removed, and after a compromise, verdicts signed with that key, including those kept as records, can no longer be told apart from forgeries. How the issuer protects its signing keys is outside the scope of this document. A verifier that cannot obtain a key for a verdict MUST reject the verdict rather than accept it unverified.

Amounts and Parsing JSON leaves numeric range and precision to implementations, and notes that good interoperability can be achieved by implementations that expect no more precision or range than binary64 provides; this is why amounts are compared by decimal value (; , step 9). Step 1 of bounds the size of tokens; the deployed implementation limits recipient to 1,024 characters and category and currency to 128 characters each, so the verdicts it has issued since 09:12 UTC on 9 October 2026 are shorter than 11,000 characters. Its earlier verdicts could reach about 94,000 characters. Event tokens () are not bounded in this way: an event token that carries a decision also carries that decision's verdict and is longer than it.

Approval of Held Requests An "allow" that carries supersedes records an operator's approval of a request held for review. The format does not state whether the mandate was evaluated again at approval time, and nothing in the token prevents an issuer from issuing more than one "allow" that supersedes the same "review" verdict; such verdicts have different nonces, so the replay check in does not detect them. A relying party that must not settle against a revoked or expired mandate needs to learn of revocations from the operator. A relying party SHOULD record the supersedes value of each "allow" it accepts, keep it at least for the review expiry plus the verdict lifetime and skew allowance (24 hours and 360 seconds in the deployed implementation), and reject a second "allow" that supersedes the same verdict. In the deployed implementation, approving a review repeats three checks whose outcome can have changed since the review: that the agent is active, that the mandate is neither revoked nor expired, and that the amount, added to every "allow" issued under the mandate in the 30 days before the approval, is within the rolling 30-day limit. It does not repeat the frequency rule; the category and the per-transaction limit cannot have changed, because mandates are not edited. An approval that fails these checks is refused and issues no verdict, and a review yields at most one "allow". Any holder of an operator-wide credential can approve a review; the principal named on the mandate is recorded but not authenticated.

Aggregate Limits A verdict records the outcome of one evaluation. Whether an issuer enforces aggregate limits, such as the rolling 30-day limit and the frequency rule, across concurrent evaluations is a property of the issuer and is not visible in the token. The deployed implementation reads the limits and records each decision in a single database transaction.

Event Tokens The deployed implementation notifies operators of events, such as a pending or resolved review, by webhook. Each event is a JWT with the same header, signed with the same key as the verdicts of its environment, under the same iss. Its claims are iss, jti (beginning "evt_"), iat, type, and data; it has no exp and no audience, and the issuer adds no claim that names the operator; only a "ping" event names the endpoint, by the webhook identifier in its data. A "decision.resolved" event carries, inside data, either the decision that approves a review, whose verdict member is "allow", together with that decision's verdict token, or the review object of a review that was denied or expired. A failed delivery is retried with the identical token; the last retry falls due 24 hours after the event is created. Because all operators' events in one environment are signed with the same key under the same iss, a genuine event issued to one operator also verifies at another operator's endpoint, at any later time: any operator served by the issuer can forward a "decision.resolved" event from its own endpoint, carrying an "allow" for a recipient it chose, to another operator's endpoint. Signature checks and deduplication on jti do not stop this. A receiver therefore confirms, through its own authenticated access to the issuer or against identifiers from its own responses, that an object named in an event is its own before acting on it, and bounds how old an event it accepts. A verdict verifier rejects event tokens by step 6 of and MUST NOT accept one as a verdict.

Privacy Considerations Verdicts are signed, not encrypted. Anyone who sees a token can read the agent identifier, which in the deployed implementation contains a name the operator chose for the agent; the amount, currency, recipient, and category; the mandate identifier; the time of the decision; and policy_version, which in the deployed implementation contains the date on which the operator's account was created. A token does not contain the operator's name or identifier, the end user's identity, payment credentials, the operator's metadata, or the reason text. The agent and mandate identifiers are stable across verdicts, and policy_version is the same for all of an operator's agents, so relying parties that compare the tokens they received can link payments made by the same agent, under the same mandate, or by different agents of the same operator. The token travels through the agent and any intermediary between the agent and the relying party. Operators SHOULD NOT put personal data in category, or in recipient beyond what identifies the payee; when the payee is a natural person, the recipient identifier is personal data and is visible to every party that handles the token. Relying parties SHOULD protect retained verdicts as they protect the payment records to which the verdicts relate.

IANA Considerations This document has no IANA actions. A later version might request registration of the private claim names in , of a media type for explicit typing, and of a well-known URI suffix for the JWK Set ().

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. Certicom Research Standards for Efficient Cryptography, Version 2.0 Informative References To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Independent Self-Issued Consulting JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices (BCP) specification updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This BCP specification furthermore obsoletes RFC 8725 to provide additional actionable guidance covering threats and attacks that have been discovered since RFC 8725 was published. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Cloudflare Google This document describes a protocol for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. It defines the Signature-Agent header field for in-band key discovery, a key directory format based on JWKS, and a well-known URI at which that directory is served. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. Independent Autonomous agents can already prove who they are, show whose authority they act under, find and call one another, and pay. What no existing specification lets them do is agree on a task in a form a third party can check, deliver against it, have the delivery judged by someone other than the performer, and carry away a record of the outcome that a stranger can verify. This document specifies PACT, a set of signed JSON records that closes that gap. PACT defines four things: a co-signed task contract whose digest covers its signature set; a Verdict record bound by digest to the Delivery it judges; a Facilitator-signed event trace and Outcome Record for every contract, recorded once, in one order, by a party other than the performer; and a Merkle commitment from a parent's Outcome Record to its subcontracts' Outcome Records. Settlement terms are carried by reference to a profile defined outside this document. This document specifies no escrow, custody or release of value, and takes no position on the legal effect of any record it defines. OpenID Foundation OpenID Foundation Final Specification Google accessed 7 October 2026 OpenAI Stripe x402 Foundation accessed 7 October 2026 Visa accessed 7 October 2026 IETF Saifuro LLC accessed 9 October 2026 Saifuro LLC accessed 9 October 2026 Saifuro LLC accessed 9 October 2026

Example This appendix contains a verdict signed with an example key. The private key is published here so that anyone can reproduce and extend the example. It is not a key of any issuer, a token signed with it proves nothing, and it MUST NOT be added to a verifier that protects real payments. The issuer identifier is a reserved example domain .

Example Key { "kty": "EC", "crv": "P-256", "x": "50tYIab3ytEcPnb_fuZCPc4cM87aNhpYhOYb9LmSseA", "y": "iZho4NBfqRZnM7AgedlHkvEMRU030NPOYGoTv7s2Ls0", "d": "34KI9Rx04_gEp_Ljm4-dGFq7O75vEFednnvRwcDdvUc", "use": "sig", "alg": "ES256", "kid": "example-1" }

Verdict The token, with line breaks for display purposes only: Decoded JOSE Header: {"alg":"ES256","typ":"JWT","kid":"example-1"} Decoded claims, with whitespace added: { "iss": "https://issuer.example", "jti": "dec_5b2e9c41", "iat": 1791374400, "exp": 1791374700, "verdict": "allow", "mandate": "mnd_7f3a0d12", "policy_version": "pol_2026-09-02.1", "nonce": "n_9d02c6e41a7f3b85", "request": { "agent": "agt_procurement_01", "amount": 340, "currency": "USD", "recipient": "vendor:acme_saas", "category": "saas" } }

Checking the Example The verdict was issued at 2026-10-07T12:00:00Z and expired at 12:05:00Z. A verifier configured with the example key, the issuer identifier https://issuer.example, and a payment record of 340.00 USD to "vendor:acme_saas", with its clock pinned to 2026-10-07T12:02:00Z (Unix time 1791374520), accepts it; for step 8, the mandate identifier agreed with the operator is "mnd_7f3a0d12" and the agreed unit is major units (US dollars). With the clock unpinned, it rejects the token at step 7 of , as intended. A production verifier never pins its clock. The S component of the example signature is in the upper half of the group order, so a verifier that enforces low-S signatures, contrary to step 5, rejects this example.

Open Issues

1. Explicit typing. Use a dedicated typ value for verdicts, such as "verdict+jwt", as recommends, and register the corresponding media type.
2. Audience. Add an "aud" claim naming the relying party or the settlement endpoint, so that the format meets , and define how the agent learns the value before evaluation.
3. Proof of possession. Bind a verdict to a key held by the agent, for example with a confirmation claim , so that a copy cannot be used by another presenter.
4. Environment separation. Use a separate issuer identifier and JWK Set for test verdicts, instead of a kid prefix.
5. Operator binding. Decide whether a verdict should identify the operator, and how a relying party would use that identifier.
6. Recipient restrictions. Let a mandate restrict the recipients for which an "allow" can be issued.
7. Policy identification. Remove policy_version, or make it, or a new claim such as a digest of the mandate as evaluated, identify the rules that were applied.
8. Claim names. Register the private claims in the "JSON Web Token Claims" registry, or use collision-resistant names.
9. Replay identifier. jti is the unique token identifier of , which notes that it can be used to prevent replay; the separate nonce claim could be removed.
10. Amount representation. Choose between JSON numbers in a constrained decimal form, decimal strings as recommends, and integers in minor units.
11. Asset codes. Define identifiers for assets that have no ISO 4217 code.
12. Enforcement mode. Decide whether a verdict should state whether the issuing environment was enforcing.
13. Event tokens. Profile event tokens as Security Event Tokens , with typ "secevent+jwt", an "events" claim, and an "aud" naming the operator's endpoint. recommends against exp in such tokens, and the absence of exp is one of the properties that makes an event token fail step 6 of .
14. Deterministic signatures. Sign with .
15. Key set integrity. Sign the JWK Set or publish a history of retired keys, for example through a transparency service , so that stored verdicts remain verifiable to third parties.
16. Amount unit. State the unit of request.amount in the token, or fix it, so that a relying party does not need to agree it out of band ().
17. JWK Set location. Register a well-known URI suffix for the JWK Set (), or let relying parties take the location from issuer metadata, instead of the unregistered "jwks.json".
18. Revocation status. Decide whether relying parties need a way to learn that a mandate was revoked after an "allow" was issued ().
19. Transport. Define how a verdict accompanies a payment in HTTP and in agent payment protocols such as , , and .
20. Related formats. Determine whether a verdict can be expressed as a signed form of an evaluation response, or its request claim as an "authorization_details" object (, which registers that claim in Section 14.2) of a payment type.

Acknowledgments The author thanks Nicholas Templeman, whose messages on the audit mailing list set out the distinction between an unsupported association and a contradicted one, which adopts, and the binding problem that describes. The author also thanks Nancy Sahu and Gareth Wong, whose proposal on the same list, that the charter state, for each verification mechanism, what a successful check establishes, under what assumptions, and whether an omitted record would be detectable, poses the question that answers for this format. The text of this document was drafted with an AI system (Claude, by Anthropic) from the implementation's source code and documentation and from the cited specifications, and was checked against them in further AI-assisted reviews. The author has reviewed the whole document and is responsible for its content.