Credential Formats

BaseID supports 6 credential formats, each designed for different privacy, interoperability, and regulatory requirements.

Format overview

Format	Standard	Privacy	Selective disclosure	Best for
JWT-VC	W3C VC 2.0	None — all claims visible	No	Organizational creds, certificates
SD-JWT VC	IETF SD-JWT + W3C	Per-claim	Yes — holder chooses	Government ID, GDPR, eIDAS
Data Integrity	W3C VC 2.0 + DI	None	No	Linked Data ecosystems, RDFC-1.0
mDL	ISO 18013-5	Per-namespace	Yes — by namespace	Driver licenses, national ID
BBS+	W3C VC + BBS	Unlinkable	Yes — ZK proofs	Maximum privacy, unlinkable presentations
AnonCreds	Hyperledger	Unlinkable	Yes — ZK predicates	Aries/Indy ecosystems

---

JWT-VC (W3C Verifiable Credential as JWT)

The most widely supported format. A W3C Verifiable Credential signed as a JSON Web Token.

Structure

Base64url(Header) . Base64url(Payload) . Base64url(Signature)

Payload anatomy

{
  "iss": "did:key:z6MkIssuer...",
  "sub": "did:key:z6MkHolder...",
  "iat": 1711459200,
  "exp": 1743081600,
  "vc": {
    "@context": ["https://www.w3.org/ns/credentials/v2"],
    "type": ["VerifiableCredential", "CanadianDigitalID"],
    "credentialSubject": {
      "id": "did:key:z6MkHolder...",
      "givenName": "Alice",
      "familyName": "Martin",
      "dateOfBirth": "1990-05-15",
      "province": "Ontario"
    }
  }
}

Characteristics

• Signing: EdDSA (Ed25519), ES256 (P-256), ES384 (P-384)
• Verification: Decode JWT, resolve issuer DID, check signature
• Size: Compact — typically 500-2000 bytes
• Privacy: None — all claims visible to every verifier
• Interop: Highest — supported by every VC implementation

When to use

• Employment credentials, professional certificates
• Organizational membership, academic degrees
• Any credential where the verifier always needs all fields
• Maximum compatibility with existing systems

---

SD-JWT VC (Selective Disclosure JWT)

Privacy-preserving credentials where the holder chooses which claims to reveal to each verifier.

Structure

IssuerJWT ~ Disclosure1 ~ Disclosure2 ~ ... ~

Each disclosure is: Base64url([salt, claim_name, claim_value])

How selective disclosure works

ISSUANCE                    PRESENTATION                VERIFICATION
─────────                   ────────────                ────────────
Issuer signs all claims     Holder selects claims       Verifier checks:
  ↓                           ↓                          ↓
JWT with _sd hashes    →    JWT + chosen disclosures →  Signature valid?
  + all disclosures         (omit private claims)       Disclosures match _sd?

Always-visible vs. disclosable claims

Claim type	Visibility	Examples
Plain (always visible)	Every verifier sees these	iss, sub, vct, iat
Selectively disclosable	Holder controls	All custom claims

When to use

• Government-issued ID (reveal only what’s needed)
• Health credentials (share diagnosis without full medical record)
• Age verification (prove age without revealing date of birth)
• GDPR/data minimization compliance
• eIDAS 2.0 / HAIP (SD-JWT VC is a required format)

---

Data Integrity (W3C VC with RDFC-1.0)

W3C Verifiable Credentials with Data Integrity proofs using RDF Dataset Canonicalization. The credential is a JSON-LD document with an embedded proof.

Structure

{
  "@context": ["https://www.w3.org/ns/credentials/v2", "https://w3id.org/security/data-integrity/v2"],
  "type": ["VerifiableCredential"],
  "issuer": "did:key:z6Mk...",
  "credentialSubject": { ... },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "verificationMethod": "did:key:z6Mk...#key-0",
    "proofValue": "z..."
  }
}

When to use

• Linked Data / semantic web ecosystems
• When credential structure must be self-describing (JSON-LD contexts)
• Government systems requiring RDF-based data models

---

mDL (ISO 18013-5 Mobile Driver License)

The international standard for mobile driver licenses.

• Encoding: CBOR (binary, compact)
• Signing: MSO with COSE signatures
• Privacy: Namespace-based selective disclosure
• Interop: Apple Wallet, Google Wallet, 40+ US states

---

BBS+ (BBS Signatures)

Zero-knowledge credentials with unlinkable selective disclosure.

Feature	SD-JWT	BBS+
Selective disclosure	Yes	Yes
Unlinkability	No — same JWT reused	Yes — each presentation is unique
ZK predicates	No	Yes — prove “age > 18” without revealing age
Performance	Fast	Slower (pairing operations)

---

AnonCreds (CL Signatures)

Hyperledger AnonCreds using Camenisch-Lysyanskaya signatures. Full ZK proof system with predicate proofs and cryptographic accumulator revocation.

---

Decision tree

Need selective disclosure?
├─ No → JWT-VC (simplest, widest support)
└─ Yes
   ├─ Need unlinkability?
   │  ├─ No → SD-JWT VC
   │  └─ Yes → BBS+
   ├─ Targeting eIDAS / HAIP? → SD-JWT VC
   ├─ Mobile driver license? → mDL
   └─ Aries / Indy ecosystem? → AnonCreds

---

See also

• Cloud: Credentials API — issue and verify via REST
• Cloud: Verification API — verify any format
• Protocols — how formats are exchanged
• DIDs — how formats are signed