Trustworxs ยท verifiable credentials
BITCred
SD-JWT credential demo
How an AI agent could prove who it works for and what it may do, without handing over a password.
In plain terms
The problem
AI assistants are starting to act for us: booking travel, buying supplies, checking records. A website needs to know two things before it lets an agent in: who it works for, and what it is allowed to do. Today that usually means handing over a password or API key, which can be copied and opens everything.
The idea
A digital credential works like a tamper-proof ID card. The organization that issues it signs it, so anyone can check it is genuine without calling the issuer. The holder shows only what a site needs, such as membership tier and not a full name. It also only works with a secret key that never leaves the holder, so a stolen copy is useless. The attacks below test exactly that.
Where it’s heading
Picture an assistant carrying a credential that says “may spend up to $50 on travel for Alex until Friday.” Any service can check it in milliseconds, it expires on its own, and Alex can revoke it at any time. The same pattern could let a nurse prove a license, or a patient share consent, without exposing anything else.
Where blockchain fits. Credentials like this come out of the same movement as blockchain: trust that rests on cryptographic signatures anyone can check, not on one company’s database. Shared ledgers can add a public record of which issuers to trust and which credentials were revoked, and stablecoin payments could let an agent pay within its limit. This demo covers the signature and privacy layer and does not use a blockchain yet.
For developers
Each run issues a membership credential (synthetic data) bound to a holder key, presents two of its five claims to a verifier, and then tries five attacks. Everything runs in this Worker; nothing is stored.
@sd-jwt/sd-jwt-vc, verify() skips the holder check unless you pass keyBindingNonce and expectedKeyBindingAudience. A stolen credential with no key-binding JWT is then accepted. The strict verifier used below sets both and requires the key-binding JWT.