Decision
Grantex issues three mandate types as plain signed JWTs (RFC 7519 compact JWS, RFC 7515), signed ES256 on P-256 (RFC 7518 §3.4) with the same DB-backed OACP issuer keys that sign OACP artifacts (oacp- kid, published in /.well-known/jwks.json):
The claims use AP2 v0.2 member names where AP2 has one. Each mandate is on the OACP Token Status List (
status.status_list, draft-ietf-oauth-status-list §6.1); revoking sets the entry INVALID and revokes every mandate issued under it.
Key family. Mandates reuse the OACP issuer keys rather than a separate mandate- key family. There is one key store, one rotation runbook and one JWKS rule. A retired key stays published while any artifact or mandate it signed is unexpired; a revoked key is withdrawn and every mandate it signed stops verifying (issuer_key_untrusted). The explicit typ keeps a mandate from being accepted as an artifact, and an artifact from being accepted as a mandate (RFC 8725 §3.11).
Alternatives not chosen
SD-JWT VC mandates, as in AP2 v0.2. AP2 v0.2 replaces v0.1’s Intent, Cart and Payment mandates with Checkout and Payment Mandates as SD-JWT VCs (vct mandate.checkout.1, mandate.payment.1, and the .open.1 forms). A user or agent provider signs them on a non-agentic Trusted Surface. Selective disclosure hides members from some verifiers. Holder binding comes from a KB-JWT signed with the cnf key, which closes an open mandate in autonomous mode. We did not choose it now because:
- In this deployment Grantex is the issuer and AgenticOrg is the only relying party. Selective disclosure would hide nothing from anyone.
- No AgenticOrg verifier for Delegate SD-JWT chains exists yet. A plain JWT reuses the ES256 verification every OACP relying party already runs.
- The buyer’s signature on a Trusted Surface needs a wallet or credential provider, which is not part of this deployment. Grantex attests consent (
amr) and, forhuman_present, a passkey assertion over the cart (below).
vct values, and have the buyer agent close open mandates with a KB-JWT signed by its cnf key.
W3C VC 2.0 (VC-JWT). This was rejected for the same reasons. It also adds a credentialSubject wrapper that AP2 does not use.
Mapping to AP2
Amounts are integer minor units (ISO 4217), as in the v0.2 closed mandates.
Passkey anchoring of the cart (G45): a Grantex extension
Ahuman_present cart mandate is issued only with a WebAuthn assertion that meets three conditions:
- it was made by a passkey the buyer registered with Grantex;
- its
challengeequals the cart’scheckout_hash; - it has user verification.
lib/webauthn-evidence.ts, a GrantexWebAuthnAssertion) and moves the credential counter forward once. It keeps the evidence and names it in the mandate’s webauthn claim (digest, rp_id, origin, challenge, user_verified, asserted_at, credential_ref). One assertion backs one mandate.
This is not part of AP2 or Verifiable Intent. Verifiable Intent states that its credentials are not WebAuthn credentials: a WebAuthn assertion authenticates the user to a wallet, and a separate key signs the intent. AP2 mentions passkeys only as a possible future trust model. W3C Secure Payment Confirmation is the standard WebAuthn extension for transaction binding, but none of these protocols reference it. The binding here gives a relying party a user-verified ceremony over exactly this cart. No human step is added to a human_not_present purchase.
Verification profile
The order and refusal codes are inapps/auth-service/src/lib/commerce/oacp-mandate-jwt.ts, and the shared vectors in spec/examples/oacp/oacp-mandates-v1.json pin them for every verifier (auth service, @grantex/sdk verifyOacpMandate, AgenticOrg).