Credential Schema

The schema specifies the exact attributes (or claims) a credential can contain, their data types (e.g., string, integer, date), and their cardinality (required vs. optional). This creates a predictable format for issuers and verifiers.

• Example: A UniversityDegree schema defines attributes like degreeType, awardingInstitution, and awardDate.
• Purpose: Prevents arbitrary data, enabling automated processing and validation.

The @context field links the schema to shared vocabularies and ontologies, defining the precise meaning of each attribute term to avoid ambiguity.

• Function: Maps terms like alumniOf to a specific, public definition (e.g., from schema.org).
• Importance: Ensures a birthDate in one system is interpreted the same way in another, enabling true semantic interoperability.

Schemas are versioned (e.g., UniversityDegree-v1.2) and, once published to a registry, are immutable. This allows credentials issued against a specific schema version to be validated indefinitely.

• Mechanism: The schema is referenced by a unique, persistent Schema ID, often a URI or a decentralized identifier (DID).
• Benefit: Provides long-term data integrity; verifiers can always fetch the exact schema used at issuance.

Beyond structure, schemas can encode validation logic using standards like JSON Schema. This allows for automatic checks on data format, ranges, and patterns.

• Examples: Enforcing an email attribute matches a regex pattern, or a graduationYear is an integer between 1900 and the current year.
• Outcome: Reduces the need for custom verification code, streamlining trust.

A public schema decouples the trust in the data structure from trust in a specific issuer. Any entity can issue credentials conforming to a well-known schema.

• Analogy: Like a standard PDF form; anyone can fill it out, and the recognisable format aids in processing.
• Ecosystem Effect: Enables a marketplace of issuers for the same credential type (e.g., KYC credentials) without vendor lock-in.

A Credential Schema is a core component in the W3C Verifiable Credentials Data Model. It works in conjunction with other key concepts:

• Credential Definition (in Indy-based systems): A cryptographic commitment to a specific schema on a ledger.
• Presentation Definition: A request for credentials that often specifies accepted schemas.
• Status Registry: Where revocation status is checked, separate from the schema itself.

Schemas used by regulated DeFi and financial institutions to issue credentials proving identity verification status. These schemas include attested attributes while preserving user privacy.

• Common Attributes: legalName, residencyStatus, sanctionsScreenPassed, issuerAccreditation.
• Privacy: Often uses zero-knowledge proofs to reveal only that a check passed, not the underlying data.
• Examples: Schemas used by projects like Verite or Ontology's ONT ID framework.

Schemas designed to attest that a credential subject is a unique, living human. Used in sybil-resistant governance and universal basic income (UBI) systems.

• Attributes: May include a cryptographic hash of a biometric or video submission, a timestamped attestation from verifiers.
• Verification Method: Often uses social verification or trusted oracle networks.
• Implementation: Used by projects like BrightID and Proof of Humanity.

Schemas for verifiable professional credentials issued by licensing bodies, employers, or guilds (e.g., DAOs). These credentials are used for gated access and proving qualifications.

• Example Fields: licenseNumber, issuingAuthority, expirationDate, scopeOfPractice, memberSince.
• Revocation: Often includes a revocation registry index for status checks.
• Use Case: A developer DAO issuing a "Solidity Auditor" credential or a state bar issuing a digital law license.

A Credential Schema is a machine-readable document, often expressed in JSON Schema, that defines the properties, data types, and validation rules for the claims within a Verifiable Credential. Its primary purpose is to ensure that credentials from different issuers have a consistent, predictable structure, enabling automated verification and processing by relying parties. For example, a university diploma schema would define required fields like degreeName, issuanceDate, and recipient.

While a DID provides a unique, self-sovereign identifier for a subject, issuer, or verifier, a Credential Schema defines the data format for the credential itself. They are complementary components: the DID anchors the credential to a decentralized identity, and the schema ensures the credential's contents are understood. Schemas are typically referenced by a unique URI (e.g., on a blockchain, IPFS, or a trusted web server) within the credential's metadata.

To be useful, schemas must be discoverable and trusted. Schema Registries are decentralized or curated repositories where schemas are published and resolved via their URI. Governance models vary:

• Public Registries: Open for anyone to publish (e.g., on IPFS or GitHub).
• Curated Registries: Managed by consortia or standards bodies for specific industries (e.g., healthcare, education).
• On-Chain Registries: Store schema hashes or URIs on a blockchain like Ethereum or Sovereign for immutability and provenance.

A practical schema for a university degree would specify:

• @context: References to the W3C VC context.
• type: Includes VerifiableCredential and UniversityDegreeCredential.
• credentialSchema: The URI pointing to this JSON Schema.
• credentialSubject: Defines required properties:
  • degree.name (type: string)
  • degree.type (e.g., "Bachelor", enum)
  • awardDate (type: string, format: date-time) This allows any employer's verification system to automatically validate the structure of submitted diplomas.

Advanced schemas enable Selective Disclosure and Zero-Knowledge Proofs (ZKPs). A schema can define which attributes are independently verifiable. For instance, a credential containing age, name, and address can have a schema that allows a user to cryptographically prove they are "over 21" (a predicate derived from age) without revealing their exact birth date or other data. This is critical for privacy-preserving verification in DeFi, access control, and age-gated services.

An Issuer is an entity (organization, person, or thing) that creates and cryptographically signs Verifiable Credentials based on a specific Credential Schema. The issuer's authority and identity are typically anchored by a Decentralized Identifier (DID).

• Role: Attests to the truthfulness of claims about a subject.
• Trust: The verifier must trust the issuer for the credential to have value.

The Holder is the entity, typically an individual or organization, that receives and stores Verifiable Credentials from issuers. The holder controls their credentials via cryptographic keys linked to their Decentralized Identifier (DID) and creates Verifiable Presentations for verifiers.

• Control: Has sole custody of private keys and credentials.
• Privacy: Can choose which credentials to present and what data to disclose.

A Verifier is an entity that requests and checks the validity of Verifiable Presentations from a holder. The verifier's trust decision is based on the cryptographic proof, the trustworthiness of the issuer, and the conformity of the data to the expected Credential Schema.

• Role: Grants access or services based on verified claims.
• Process: Validates signatures, checks revocation status, and evaluates claims.