The issuer key (a public JWK, or the public keys of an AERE identity) is checked first: one that cannot be read, is private, or is not
a key for the algorithm asked exits 2 with the reason, instead of reporting the token INVALID. --json prints compact JSON (indented
output grew with the square of the claims' nesting depth). --at judges at a given time, as for verify. Test on the RFC 9901 example
presentation: valid at its own time, invalid now, a private key refused. Tests: SD-JWT 23/23, negative control 28/28; identity 44/44,
negative control 49/49.
sdjwt.mjs: an issuer-signed JWT with the digests of the disclosable claims (_sd, list elements as {"...": digest}, _sd_alg sha-256),
the holder's key in cnf.jwk and exp, followed by the disclosures; the holder keeps the ones it picks and adds a Key Binding JWT
(kb+jwt, aud, nonce, iat, sd_hash); the verifier follows RFC 9901 sections 7.1 and 7.3 with the issuer key it chose, and requires its
audience and nonce, exp, and an explicitly typed token. Algorithms: ES256, EdDSA (Ed25519, the key every AERE identity has) and
ML-DSA-65 (JWK type AKP, names from the IETF draft draft-ietf-cose-dilithium, not yet a published standard).
Checked against the standard's own vectors (fixturi-rfc9901.json, from RFC 9901 Section 5 and Appendix A.5): the ten example
disclosure digests, the example SD-JWT signed by someone else with the A.5 key, and the example presentation with key binding, which
gives exactly the processed payload printed in the RFC. Not checked against another SD-JWT library.
An adversarial review before publication found ten defects, all fixed with a test and a planted negative control each (among them:
the issuer signed SD-JWT structure coming in claim values; the holder revealed an element with the same value from any list; audience
and nonce were not required). Tests: SD-JWT 22/22, negative control 28/28; identity 44/44.
Before, it was the digest of the whole presentation object, so an unsigned top-level field added by anyone changed it without
changing anything signed, and the digest did not name one presentation. The binding names, by hash, the whole credential, the
disclosures, the delegation chain, the audience, the nonce and the time; the signature is left out (ML-DSA signs with randomness,
so one binding can carry many valid signatures).
Tests: compliance 15/15, negative control 14/14.
A credential issued on a machine whose clock was one second ahead was "not yet valid" at a verifier synchronized by NTP: measured on
2026-09-30 through the Aere Cloud identity route, the first time a credential was issued on one machine and judged on another.
Starts (a credential's and a status list's validFrom, a delegation's notBefore) are now accepted up to 60 s in the verifier's future
(verifyPresentation clockSkewS, 0..600); a revocation dated up to 60 s ahead already applies; ends (validUntil, notAfter) get no
allowance, since that would extend a validity.
Tests: identity 44/44, negative control 49/49.
- verify: --at <RFC 3339 UTC> judges on that clock (the verifier's clock in any case), so a verdict given at one moment can be checked
again later with the same result; a broken --trust-issuer or --max-age exits 2 with the reason instead of failing without a verdict;
the JSON result names the subject (type, credential, issuer, holder, presenter, delegations) when no check failed
- comply: --json [--with-record] prints the result and the record in one object; with --at the record's time is the same, so the same
command gives the same record byte for byte; a refused policy exits 2 with its reason
- Aere Cloud runs this command line unmodified behind POST /v1/identity/verify and POST /v1/compliance/check
Tests: identity 43/43, negative control 46/46.
- verify-consistency without --signer now says whether each head is signed and by which key, and that no expected signer was
checked (verify-inclusion already did; the README said the output does)
- openMessage opens nothing without a replay store (seen: an object with has/add that keeps the ids for at least maxAgeS);
before, the same signed and sealed message could be opened any number of times when no store was given
Tests: verify-layer tree 20/20, negative control 14/14; sidecar 44/44, 9/9; travel rule 19/19, negative control 19/19.
AereAgentWallet2of2 holds the agent's tokens and accepts only the agent's signature followed by the policy
service's, over the same digest. In the new cosign mode the wallet service signs only its half, after every
check it already made, and the agent adds its half only after it recomputes the payment itself (payer,
recipient, amount, the nonce of its own ledger entry, validity, digest, declared policy signer).
verifica-plati.mjs requires the wallet's code on chain to be exactly the compiled contract with the two
signers; recompileaza-contract.mjs recompiles the published artifact byte for byte with solc 0.8.23.
Tests: co-signing 16/16, payment verifier 14/14, negative control 30/30, wallet 25/25. On the public
testnet 28001 on 2026-09-29: 13/13 with the 2-of-2 wallet (the agent alone and the policy signer alone
refused by the facilitator and by the token asked on chain) and 9/9 with the wallet key. Evidence in
dovezi-28001/. Nothing here has been run on the Aere Network mainnet.
The agent does not hold the payment key: the wallet holds it for the owner and signs an EIP-3009 authorization only for a payment the
agent wrote into its signed ledger, verified without trusting the agent under the policy the owner pinned and against the ledger heads
the wallet itself saw (a branch is refused with a proof of equivocation, a backdated entry is refused), naming exactly this purchase,
written now, and within the limit judged also against what the wallet itself has signed. The authorization nonce is sha256(entry hash),
so the on-chain payment names the ledger entry. The policy gains an optional `wallet` field. Also: an x402 v2 client, a minimal resource
server, a local facilitator for tests, and verifica-plati.mjs, which proves from outside that a wallet's on-chain payments were allowed
by the agent's policy (with --all-transfers, that no payment left the wallet without a ledger entry).
Tests: wallet 25/25 and payment verifier 10/10 without a network (the verifier on chain responses recorded on testnet 28001), negative
control 21/21; policy 27/27, agents control 26/26. On the public testnet 28001 through its x402 facilitator: 9/9, with the evidence in
agents/x402/dovezi-28001/. Needs ethers (npm install in agents/x402).
An agent gets an ML-DSA-65 identity and a policy (spending per time window, allowed tools and recipients, which actions need human
approval, who may revoke it). Every action it proposes is judged against the policy, signed by the agent and chained; a verifier that
does not trust the agent re-runs the policy over the whole ledger. Approvals and revocations are signed by people with their own
ML-DSA-65 keys. The ledger of an agent under a policy is one ledger: a second history is a branch, and two branches are a proof of
equivocation anyone can check with the public key alone. The README says what the verifier cannot see: entry times are bounded from
below only with a witness (anchors or a start time), and someone who sees one branch cannot know of another.
Tests: policy 23/23 with the AIP-23 reference verifier (21 run without it), ledger 51/51, approval and revocation 39/39, command line
23/23; negative control 25/25.
