Credential Metadata

The issuer and subject of a credential are identified using Decentralized Identifiers (DIDs), a W3C standard. A DID is a cryptographically verifiable identifier that is controlled by its owner, not a central registry.

• Example: did:ethr:0xabc123...
• Enables self-sovereign identity by removing reliance on centralized authorities.
• DIDs resolve to a DID Document containing public keys and service endpoints for verification.

The core structure is defined by the W3C Verifiable Credentials Data Model. This model standardizes the JSON-LD or JWT format for credentials, ensuring interoperability across different systems.

Key components include:

• @context: Defines the vocabulary and data types.
• type: Specifies the credential schema (e.g., VerifiableCredential, UniversityDegreeCredential).
• credentialSubject: The claims about the subject (e.g., "degree": "Bachelor of Science").
• issuanceDate & expirationDate: Timestamps for credential validity.

Credential metadata includes a cryptographic proof, typically a digital signature, that binds the credential data to the issuer's DID. This proof enables cryptographic verifiability.

• Common proof types include EdDSA, ES256K, and BBS+ signatures.
• The proof is verified against the public keys in the issuer's DID Document.
• This mechanism provides tamper-evidence and guarantees the credential's authenticity and integrity without contacting the issuer.

Advanced credential systems support selective disclosure, allowing a holder to prove specific claims from a credential without revealing the entire document. This is enabled by zero-knowledge proof (ZKP) cryptography.

• Example: Proving you are over 21 without revealing your exact birth date or name.
• Protocols like BBS+ signatures or zk-SNARKs enable this privacy-preserving feature.
• Critical for minimizing data exposure and complying with privacy regulations like GDPR.

Metadata can include mechanisms to check the status of a credential, such as whether it has been suspended or revoked by the issuer. This is essential for maintaining trust over the credential's lifecycle.

Common status mechanisms:

• Status List 2021: A W3C standard using bitstrings for compact revocation lists.
• Revocation Registries: Used in Hyperledger Indy and Aries frameworks.
• Smart Contract Registries: On-chain registries, often used by Ethereum Attestation Service (EAS) or Verax.

To ensure the semantic meaning of claims is universally understood, credential metadata references a schema. A schema defines the structure, data types, and allowed values for the claims in the credentialSubject.

• Schemas are often published on decentralized registries or public ledgers.
• Example: A DriversLicenseCredential schema defines fields for licenseNumber, issueState, and expiryDate.
• Using shared schemas enables semantic interoperability, allowing verifiers from different organizations to process credentials correctly.

Schemas define the structure of credential metadata, specifying required fields (e.g., issuanceDate, credentialSubject.id, credentialSchema). On-chain registries, like Ethereum Attestation Service (EAS) Schema Registry or Verax, store these schemas to ensure consistency and discoverability. Using a registered schema allows any verifier to interpret the attestation's data format correctly.

Credential validity is managed through explicit revocation or expiry.

• Revocation Registries: Maintain a list of revoked credential IDs (e.g., using a smart contract or a verifiable data registry).
• Timestamp Expiry: Credentials include a validUntil field in their metadata.
• Status List 2021: A W3C standard for compact, privacy-preserving revocation status lists. These mechanisms ensure issuers can invalidate credentials without compromising user privacy.

These privacy techniques allow users to prove specific claims from a credential without revealing the entire document.

• Selective Disclosure: Revealing only certain fields from a signed credential.
• Zero-Knowledge Proofs (ZKPs): Generating a cryptographic proof that a claim (e.g., 'age > 18') is true without revealing the underlying data. This is critical for privacy-preserving DeFi, voting, and access control.

Credential metadata enables trustless interactions across web3:

• Sybil Resistance: Prove unique humanity or reputation for airdrops and governance.
• Under-collateralized Lending: Use credit score or income attestations.
• Compliance: Share KYC/AML status with DeFi protocols.
• Skill Verification: Prove completion of courses or contribution history (e.g., Gitcoin Passport).
• Access Control: Gate NFT communities or events based on verified traits.

A trusted system, often a blockchain or decentralized network, that records the status of DIDs and credentials. It is a key piece of infrastructure for credential metadata, enabling:

• Status Checks: Verifying if a credential has been revoked or suspended.
• DID Resolution: Looking up the public keys of an issuer.
• Schema Anchoring: Publishing the structure of credentials (like CredentialSchema) for universal interpretation.

A formal definition of the data structure for a specific type of credential. It is a critical piece of metadata referenced by the credentialSchema property. A schema defines:

• Required and optional fields (e.g., birthDate, degreeType).
• Data types (string, integer, date).
• Format constraints (regex patterns, value ranges). Using schemas ensures credentials from different issuers are interoperable and can be processed automatically by verifiers.

A privacy-enhancing feature enabled by cryptographic proofs in certain credential formats (e.g., BBS+ Signatures). It allows a holder to prove specific claims from a credential without revealing the entire document or its metadata. For example, proving you are over 21 from a driver's license credential without revealing your name, address, or exact birth date. This technique relies on the integrity guarantees provided by the credential's underlying metadata and proofs.

The act of a credential holder sharing one or more Verifiable Credentials with a verifier. A Verifiable Presentation bundles credentials and includes:

• Holder's proof: A signature demonstrating control over the presented credentials.
• Presentation metadata: Context, challenge, and domain from the verifier.
• Selected credentials: The actual VCs, with their full metadata, which may be selectively disclosed. The presentation itself is a verifiable data object with its own metadata layer.