Verifiable Credentials

AgentMarque issues every registered agent a W3C Verifiable Credential (VC) 2.0. A VC is a tamper-evident, cryptographically signed document that binds an agent's public key to its name, organization, capabilities, and trust metadata. Once issued, the credential is portable — the agent can present it to any verifier without calling back to the AgentMarque registry.

What are Verifiable Credentials?

A Verifiable Credential is a W3C standard for expressing claims about a subject in a way that is:

• Portable — the holder carries the credential and can present it anywhere.
• Independently verifiable — any party can check the cryptographic proof without contacting the issuer.
• Tamper-evident — any modification to the credential invalidates the proof.

In the AgentMarque system, the issuer is whoever signs the credential (an organization, the agent itself, or the hosted registry), the holder is the agent, and the verifier is any agent or service that wants to validate the holder's identity.

The AgentMarqueCredential

Every agent credential uses the AgentMarqueCredential type. Here is a full example in JSON-LD:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://agentmarque.com/ns/agent/v1"
  ],
  "type": ["VerifiableCredential", "AgentMarqueCredential"],
  "issuer": "did:key:z6MkIssuer...",
  "validFrom": "2026-04-02T00:00:00Z",
  "validUntil": "2026-07-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6Mkf5rG...",
    "type": "AIAgent",
    "agentName": "translate-agent",
    "organization": {
      "id": "https://acme.co",
      "name": "Acme Corp"
    },
    "capabilities": ["translate", "detect_language"],
    "verificationTier": 2,
    "reputationScore": 87.5,
    "settlement": {
      "methods": ["x402"],
      "x402_address": "0xabc"
    }
  },
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "..."
    }
  },
  "credentialStatus": {
    "type": "BitstringStatusListEntry",
    "statusListIndex": "4567",
    "statusListCredential": "https://api.agentmarque.com/status/list/1"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "proofValue": "z3FXQ..."
  }
}

Key fields:

Holder Binding

The cnf (confirmation) claim binds the credential to the agent's Ed25519 public key. At issuance time, the registry embeds the agent's public key as a JWK:

"cnf": {"jwk": {"kty": "OKP", "crv": "Ed25519", "x": "..."}}

When the agent presents its credential, it appends a KB-JWT (key-binding JWT) signed with the corresponding private key. The verifier checks two signatures:

1. Issuer signature on the SD-JWT — proves the credential was issued by a trusted authority.
2. Holder signature on the KB-JWT — proves the presenter controls the private key matching the cnf public key.

This two-signature scheme prevents credential theft: even if an attacker obtains a copy of the SD-JWT, they cannot produce a valid KB-JWT without the holder's private key.

Data Integrity Proofs

AgentMarque signs every credential using Data Integrity Proofs with the eddsa-jcs-2022 cryptosuite. This means:

1. Ed25519 signatures — fast, compact, and well-supported across languages.
2. JCS (JSON Canonicalization Scheme) — the credential is canonicalized before signing, so field ordering doesn't matter. Two semantically identical documents always produce the same canonical form and the same signature.

The proof block in the credential contains the signature. Any verifier with the issuer's public key can re-canonicalize the document and check the signature without any network call.

Selective Disclosure with SD-JWT

A full credential contains every claim — capabilities, organization, trust scores, settlement. Agents don't always need to reveal all of that. SD-JWT (Selective Disclosure JSON Web Token) lets an agent present only the claims a verifier needs.

For example, during a handshake an agent might disclose only:

• agentName
• capabilities
• verificationTier

While keeping settlement and organization hidden.

Credential Lifecycle

1. Issuance — The registry signs the credential with its Ed25519 key via issue_credential(), embedding the agent's public key in the cnf claim.
2. Storage — The agent stores the credential locally. The credential is portable and self-contained.
3. Presentation — The agent creates a holder-bound SD-JWT presentation via credential.present(), appending a KB-JWT signed with its holder key. The agent can selectively disclose only the claims the verifier needs.
4. Verification — The verifier checks both signatures (issuer and holder), expiration, revocation status, nonce, audience, and policy constraints via AgentMarqueVerifier.verify().
5. Revocation — If a credential is compromised, the issuer flips a bit in the status list. Verifiers see the revocation on their next check.

BitstringStatusList Revocation

AgentMarque uses the BitstringStatusList specification for credential revocation. Each credential is assigned an index in a bitstring. When a credential is revoked, the corresponding bit is flipped.

Properties of the status list:

• Sub-second revocation — flipping a bit and publishing the updated list is near-instant.
• Compact — each list holds 131,072 entries in a single compressed bitstring.
• CDN-cacheable — status lists are served as static resources with a short TTL (10 seconds). Verifiers fetch the list, check the bit at the credential's statusListIndex, and cache locally.
• Privacy-preserving — the list doesn't reveal which credentials exist, only which indices are revoked.

The SDK can verify against any status list URL via the built-in StatusListVerifier. AgentMarque publishes status lists at api.agentmarque.com/status/list/*. If you run your own registry, you publish your own.