Credential Template

The core of a template is its schema, which defines the exact data fields and their types (e.g., string, integer, timestamp) that a credential must contain. This ensures all credentials issued from the same template have a consistent structure, enabling automated parsing and verification by smart contracts and applications.

• Example Fields: holderAddress, issuanceDate, expiryDate, scoreValue.
• Standardization: Often uses formats like JSON Schema or IPLD for portability.

Templates encode rules about who can issue and revoke credentials. This is typically managed through an issuer registry or a smart contract that holds a list of authorized signing keys or addresses.

• Permissioned Issuance: Only approved issuers can sign credentials, preventing forgery.
• Revocation Mechanisms: Supports on-chain revocation lists (e.g., a Merkle root) or expiry timestamps, allowing issuers to invalidate credentials without altering the original data.

Embedded within or referenced by the template is the verification logic that applications use to validate a credential's authenticity and current state. This logic checks the cryptographic signature against the issuer's public key and queries the relevant revocation registry.

• On-Chain vs. Off-Chain: Verification can be performed by a smart contract for high-value actions or off-chain by a verifier's client.
• Deterministic Outcome: The rules ensure any verifier will reach the same conclusion about the credential's validity.

Templates include human and machine-readable metadata for discovery and understanding. This often includes a unique identifier (like a URI or template ID), a display name, description, and links to the issuer's attestation policy.

• Interoperability: Standard metadata fields allow credential registries and wallets to properly categorize and display credentials.
• Context: Provides the "why" behind the credential, explaining what it represents (e.g., "KYC Level 2 Attestation").

Advanced templates can reference or require other credentials, enabling credential composition. This allows for complex attestations built from simpler, reusable proofs.

• Example: A "High-Value Loan Eligibility" credential template might require the holder to also possess a valid "KYC Verified" credential and a "Credit Score > 700" credential.
• Graph Relationships: Creates a graph of trust where the validity of one credential depends on the state of others.

To ensure trust, credential templates are typically registered to an immutable, public registry (often a smart contract or decentralized storage like IPFS). This prevents tampering with the template's definition after deployment.

• Versioning: Registries may support template versioning, allowing for upgrades while preserving the integrity of credentials issued under previous versions.
• Auditability: Anyone can audit the template's source code and validation rules, fostering transparency.

A credential template for proving unique human identity. It typically includes fields for a verified selfie, government ID check, and social proof. Issuers like BrightID or Worldcoin use this template to create Sybil-resistant credentials essential for fair airdrops and governance.

• Core Fields: verifiedTimestamp, issuerDID, verificationMethod
• Use Case: Grants access to Quadratic Funding rounds and one-person-one-vote DAOs.

A compliance-focused template used by regulated DeFi protocols and token issuers. It cryptographically asserts a user has passed Know Your Customer and Anti-Money Laundering checks without exposing raw personal data.

• Core Fields: jurisdiction, levelOfAssurance, expiryDate, accreditedInvestorStatus
• Use Case: Required for accessing permissioned DeFi pools or participating in security token offerings (STOs).

A template for issuing a verifiable, portable credit score based on on-chain history. It aggregates data from DeFi loan repayment, wallet age, transaction volume, and governance participation.

• Core Fields: score, calculationModel, dataSources, lastUpdated
• Use Case: Enables under-collateralized lending and trust-minimized rental agreements in DeFi.

A widely adopted template for issuing non-transferable Soulbound Tokens (SBTs) as proof of event participation or community membership. Each credential is a unique NFT minted against a standard schema.

• Core Fields: eventName, eventDate, location, issuerImage
• Use Case: Builds verifiable reputation history, grants access to gated communities, and serves as a achievement record.

A template for issuing verifiable professional credentials, such as developer certifications, legal bar admissions, or financial advisor licenses. It allows for trustless verification of qualifications in decentralized autonomous organizations (DAOs) or freelance markets.

• Core Fields: licenseType, issuingAuthority, licenseNumber, validUntil
• Use Case: Verifying contributors in a developer DAO or hiring for a smart contract audit role.

A dynamic credential template that represents delegated governance rights in a DAO. It is often time-bound and revocable, encoding the specific voting contract address and delegation parameters.

• Core Fields: delegatorAddress, delegateeAddress, tokenContract, expiryBlock, votingPower
• Use Case: Facilitating liquid democracy or expert delegation in protocols like Compound or Uniswap.

The credential template must be anchored to an immutable ledger (e.g., a blockchain) to prevent tampering. This ensures the schema definition—including required fields, data types, and issuer authorization rules—cannot be altered after deployment. A hash of the template stored on-chain provides a verifiable reference point for all credentials issued against it, guaranteeing their structural validity.

Templates enforce trust in the issuer. They define which cryptographic keys or decentralized identifiers (DIDs) are authorized to sign credentials. Advanced templates can implement delegation models, where a root authority (e.g., a government) can delegate issuance rights to sub-issuers (e.g., licensed banks). This creates a verifiable chain of trust without centralized registries.

A secure template supports privacy-preserving verification. It allows holders to prove claims derived from their credential (e.g., 'I am over 18') without revealing the underlying data (their birthdate) using zero-knowledge proofs (ZKPs). The template defines which attributes are disclosable and which can be used in ZKP circuits, balancing utility with data minimization.

Trust requires the ability to invalidate credentials. Templates must define a revocation strategy, such as:

• Status Lists: Checking a distributed revocation registry.
• Accumulator Schemes: Using cryptographic accumulators (e.g., Merkle trees) for efficient, private status checks.
• Expiry Timestamps: Built-in expiration to limit credential lifetime. The chosen mechanism impacts privacy, scalability, and issuer overhead.

To be trusted across ecosystems, templates should adhere to open standards like W3C Verifiable Credentials (VCs) or Decentralized Identifiers (DIDs). Conformance ensures credentials can be validated by standard libraries and wallets, preventing vendor lock-in. It also defines how credential proofs (e.g., JWT, JSON-LD signatures) are structured and verified.

Long-lived systems require a process for template evolution. Security considerations include:

• Governance Models: Who can propose and approve changes (e.g., token voting, multi-sig).
• Backward Compatibility: How updates affect existing, valid credentials.
• Deprecation Pathways: Secure sunset procedures for old templates. Poor governance can lead to fragmentation or unauthorized schema changes.

A Schema defines the data structure and semantic meaning for the claims within a credential template. It specifies the allowed property names, data types, formats, and constraints. In blockchain contexts, schemas are often registered on-chain (e.g., using the IBC Protocol's Interchain Accounts) to create a shared, immutable reference for issuers and verifiers, ensuring interoperability.

A Revocation Registry is a mechanism for an issuer to revoke a previously issued Verifiable Credential before its natural expiration. This is critical for maintaining trust, as it allows issuers to invalidate credentials that are compromised or no longer accurate (e.g., a revoked driver's license). Methods include revocation lists and more advanced accumulator-based techniques for privacy.

Selective Disclosure is a privacy-preserving feature that allows a credential holder to prove a specific claim from a credential without revealing the entire credential or other unrelated claims. For example, proving you are over 21 from a driver's license credential without revealing your exact birthdate or address. This is enabled by cryptographic techniques like zero-knowledge proofs (ZKPs).