Signed Authorization Verdicts for Agent-Initiated Payments

1.1. Scope

In scope are the verdict format (Section 4), the publication of verification keys (Section 5), and the procedure a relying party follows before it relies on a verdict (Section 6).¶

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.¶

1.2. 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 [RFC2119] [RFC8174] 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 Section 4.3 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 (Section 6, steps 4 and 6). Section 5.5, Section 10.4, and Section 11 also address operators and others that carry or keep verdicts. The key words do not define requirements for other issuers or formats.¶

1.3. 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 (Section 10.12). 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 [AP2], 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 [AUTHZEN], a policy decision point.¶

Verdict:

The signed token defined in Section 4. "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 Section 6.¶

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 (Section 10.14) 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").¶

4.1. Serialization, Header, and Signature

A verdict is a JSON Web Token (JWT) [RFC7519] in JWS Compact Serialization [RFC7515]: 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, Section 3.4 of [RFC7518]); typ, with the value "JWT"; and kid, naming the signing key in the issuer's JWK Set (Section 5). 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 (Section 10.6).¶

The signature is the 64-byte concatenation of R and S, each 32 bytes, big-endian, as Section 3.4 of [RFC7518] requires, not an ASN.1 DER encoding. The issuer uses randomized ECDSA (Section 10.5) and does not normalize S (Section 10.8).¶

The payload is a JSON object [RFC8259] encoded in UTF-8 [RFC3629]. The issuer writes it without insignificant whitespace and in the member order of Table 2. Verifiers MUST NOT depend on member order, whitespace, or string escaping.¶

4.2. Claims

In Table 2 and in step 6 of Section 6, "integer" means a JSON number whose value is an integer; the issuer writes such values with no fraction or exponent part. This narrows NumericDate (Section 2 of [RFC7519]), 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 (Section 4.1 of [RFC7519]). The claim nonce is registered in the IANA "JSON Web Token Claims" registry by [OIDC-CORE]; Section 12.7.1 of [RFC9449] 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 [OIDC-CORE] and [RFC9449], 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 (Section 4.3 of [RFC7519]) and can collide with other uses of the same names (Appendix B).¶

Apart from the "sandbox-" prefix of kid (step 3 of Section 6) 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 (Section 8). Registered claims that verdicts do not carry are processed as [RFC7519] specifies: a verdict carrying "aud" is rejected unless the verifier identifies itself with one of its values (Section 4.1.3 of [RFC7519]), and one carrying "nbf" is rejected before that time (Section 4.1.5 of [RFC7519]).¶

4.3. The request Claim

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 [ACP]; 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 (Section 4.6; Section 6, step 8), before steps 9 and 10 of Section 6; 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 (Section 10.3).¶

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.¶

4.4. Presence by Verdict Code

4.5. Verdict Codes

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 (Section 10.3).¶

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 (Section 10.12). 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.¶

4.6. 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 Section 2.2 of [RFC7493], 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 (Section 6, 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 (Section 6, step 9) would match a verdict evaluated for 340 cents against a payment of 340 US dollars. Step 8 of Section 6 therefore includes agreeing the unit with the operator.¶

4.7. 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 (Section 4.5), 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 (Section 10.2, Section 10.4, Section 10.7).¶

5.1. JWK Set

The issuer publishes its public keys as a JWK Set (Section 5 of [RFC7517]). 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" [RFC9111] and "Access-Control-Allow-Origin: *", with the media type "application/json" rather than "application/jwk-set+json" (Section 8.5 of [RFC7517]).¶

5.2. 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 (Section 9), 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 Section 3 of [RFC8615], which requires registration, and this document does not register it (Appendix B).¶

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.¶

5.3. 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 (Section 6, step 3; Section 10.6).¶

5.4. 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 (Section 10.10).¶

The kid is untrusted input, used only as a lookup key, never in a file path, query, or URL (Section 3.10 of [RFC8725]). 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 (Section 5.5) 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.¶

5.5. Rotation

The issuer's rotation procedure extends the approach of Section 10.1.1 of [OIDC-CORE], 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 Section 6), and for as long as any event token it signed can still be delivered (Section 10.14). 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 (Section 9), 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 (Section 6.2).¶

6.1. 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 (Section 10.2); 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.¶

6.2. 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 (Section 5.5), 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 (Section 10.1).¶

9.1. 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 Section 4 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:

Section 4 and Section 5, with the departures from [RFC8725], [RFC7493], and [RFC8615] 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 (Section 10.13). Approving a review repeats the checks described in Section 10.12. No key rotation has taken place yet. The event tokens of Section 10.14 resemble Security Event Tokens [RFC8417] 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 [SAIFURO-VERIFY] gives starting examples for jose (JavaScript), PyJWT (Python), and jwx (Go); they do not implement every step of Section 6, and the documentation lists the main checks they leave to the relying party.¶

Documentation:

[SAIFURO-VERIFY], [SAIFURO-LIMITS].¶

Test vectors:

[SAIFURO-VECTORS]: 138 tokens with their expected results, covering each step of Section 6 and Section 6.2, signed with the example key of Appendix A and further published test keys.¶

Contact:

Ithelia Dias, ithelia.dias@saifuro.com.¶

Last updated:

9 October 2026.¶

10.1. 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 (Section 5.5) 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.¶

10.2. 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 (Section 6, 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 Section 6 uses the mandate claim for that.¶

10.3. 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 Section 6 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 (Appendix B).¶

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 Section 6 does not help: it compares exactly, and the recipient that benefits is the one the token names.¶

10.4. 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 [RFC7800], 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 (Section 10.14), 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 Section 6. 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 (Appendix B).¶

10.5. 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 (Section 4.1.1 of [RFC7515], Section 2.1 of [RFC8725], Section 3.1 of [RFC8725]). Every key in the set is published with "alg" "ES256".¶

Section 3.2 of [RFC8725] says that JWT libraries should implement ECDSA using the deterministic approach of [RFC6979]. 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 [RFC6979]; 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.¶

10.6. Cross-JWT Confusion and Explicit Typing

Verdicts and event tokens share the key, the issuer identifier, and the typ value "JWT", so Section 2.8 of [RFC8725] requires a mitigation. This format uses the second strategy listed in Section 3.12 of [RFC8725], different required claims: a verdict requires exp, verdict, nonce, and request, which event tokens lack, and step 6 of Section 6 rejects tokens that carry a type claim or an "evt_" jti. That step is the mutually exclusive validation rule that Section 3.12 of [RFC8725] 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 Section 3.11 of [RFC8725] 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 (Appendix B).¶

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 Section 6, which reads a prefix of kid. JOSE leaves the structure of kid unspecified (Section 4.1.4 of [RFC7515]), 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 (Appendix B).¶

10.7. Audience

Verdicts have no "aud" claim. Section 3.9 of [RFC8725] 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 Section 6 accepts verdicts without one, and so departs from that requirement as well. The member request.recipient is not an audience in the sense of Section 4.1.3 of [RFC7519]: it names the payee, which the agent chooses and the issuer does not check. When the relying party is the payee, step 11 of Section 6 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 (Appendix B).¶

10.8. Replay and Signature Malleability

A verdict is valid for 300 seconds, and a relying party accepts its nonce only once (Section 6, step 12); relying parties that do not share a nonce store can each accept it (Section 10.7).¶

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.¶

10.9. 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 Section 6 assumes a synchronized clock.¶

10.10. 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.¶

10.11. Amounts and Parsing

JSON leaves numeric range and precision to implementations, and Section 6 of [RFC8259] 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 (Section 4.6; Section 6, step 9). Step 1 of Section 6 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 (Section 10.14) are not bounded in this way: an event token that carries a decision also carries that decision's verdict and is longer than it.¶

10.12. 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 Section 6 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.¶

10.13. 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.¶

10.14. 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 Section 6 and MUST NOT accept one as a verdict.¶

A.1. Example Key

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

A.2. Verdict

The token, with line breaks for display purposes only:¶

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImV4YW1wbGUtMSJ9.eyJ
pc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlIiwianRpIjoiZGVjXzViMmU5YzQ
xIiwiaWF0IjoxNzkxMzc0NDAwLCJleHAiOjE3OTEzNzQ3MDAsInZlcmRpY3QiOiJ
hbGxvdyIsIm1hbmRhdGUiOiJtbmRfN2YzYTBkMTIiLCJwb2xpY3lfdmVyc2lvbiI
6InBvbF8yMDI2LTA5LTAyLjEiLCJub25jZSI6Im5fOWQwMmM2ZTQxYTdmM2I4NSI
sInJlcXVlc3QiOnsiYWdlbnQiOiJhZ3RfcHJvY3VyZW1lbnRfMDEiLCJhbW91bnQ
iOjM0MCwiY3VycmVuY3kiOiJVU0QiLCJyZWNpcGllbnQiOiJ2ZW5kb3I6YWNtZV9
zYWFzIiwiY2F0ZWdvcnkiOiJzYWFzIn19.5NLM85wfRPdBIBaW_fY_gmgfml5w-0
KZlVbDj0YUVxa03wiYmqXamfLynH_S_DUkk2j_HTAlorcS3tHdtNvwYA

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"
  }
}

A.3. 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 Section 6, 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.¶