Issue Credential Protocol

These protocols define three core roles in the credential lifecycle:

• Holder: The entity (e.g., a user) that receives and stores a credential in their digital wallet.
• Issuer: The trusted entity (e.g., a university, government) that creates and signs the credential.
• Verifier: The entity (e.g., a website, employer) that requests and validates the credential's authenticity and claims. This role separation is fundamental to decentralized identity models like W3C Verifiable Credentials.

Protocols specify the data structure and proof mechanism for credentials. Common formats include:

• W3C Verifiable Credentials (JSON-LD): A standardized data model for expressing claims.
• JSON Web Tokens (JWTs): A compact, URL-safe format often used for AnonCreds-style presentations. Credentials are cryptographically signed by the Issuer using keys linked to a Decentralized Identifier (DID), ensuring tamper-evidence and provenance.

A Verifiable Presentation is how a Holder shares credentials with a Verifier. Key features include:

• Selective Disclosure: The Holder can reveal only specific attributes from a credential (e.g., proving they are over 21 without revealing their exact birthdate).
• Zero-Knowledge Proofs (ZKPs): Advanced cryptographic methods, used in AnonCreds and BBS+ signatures, enable this without exposing the underlying data or correlatable identifiers.

Standardized interaction sequences govern the credential exchange. For example, the W3C Credential Handler API and DIDComm protocols define message types for:

• Credential Offer: An Issuer proposes a credential to a Holder.
• Credential Request: A Holder formally requests the credential.
• Credential Issuance: The signed credential is transmitted.
• Presentation Request/Submission: The Verifier requests proof, and the Holder submits a presentation.

Adherence to open standards ensures credentials work across different ecosystems. The primary standards bodies are:

• World Wide Web Consortium (W3C): Defines the Verifiable Credentials Data Model and Decentralized Identifiers (DIDs).
• Decentralized Identity Foundation (DIF): Develops implementation specs like DIDComm for secure messaging.
• OpenID Foundation: Manages OpenID for Verifiable Credentials (OID4VC), which bridges SSO and credential protocols.

Protocols must handle the revocation of issued credentials. Common mechanisms include:

• Revocation Registries: A cryptographically verifiable list (e.g., on a blockchain) of revoked credential identifiers, used by AnonCreds.
• Status Lists: W3C-standardized bitstring lists that indicate credential status.
• Timestamping: Using an Anchored Data Registry to prove a credential was valid at a specific point in time, independent of issuer availability.

An advanced cryptographic implementation enabling holders to reveal only parts of a credential. The BBS+ (Boneh-Boyen-Shacham) signature scheme allows for zero-knowledge proof generation over multiple attributes.

• Process: Issuer signs a credential with a BBS+ key. The holder can later generate a proof for a subset of attributes (e.g., only birth year).
• Privacy: The verifier learns only the disclosed data and that it was signed by a valid issuer.
• Standardization: Part of the W3C VC Data Model and implemented in frameworks like AnonCreds.

The issuer's cryptographic signature is the primary mechanism for establishing authenticity and integrity. The credential is signed with the issuer's private key, creating a tamper-evident seal. This ensures:

• Data Integrity: Any alteration to the credential data invalidates the signature.
• Provenance: The credential can be cryptographically traced back to the issuer's Decentralized Identifier (DID).
• Non-repudiation: The issuer cannot later deny having issued the credential.

A credential's validity must be dynamically verifiable. Protocols implement status mechanisms to handle revocation without compromising privacy.

• Status Lists: Issuers maintain a cryptographically signed list (e.g., a Status List 2021 bitstring) of revoked credential indices.
• Selective Disclosure: Verifiers can check revocation status without learning the holder's identity or other credential details.
• On-Chain Registries: Some implementations use smart contracts as a revocation registry, providing an immutable audit trail.

Protocols must protect the holder's privacy. Selective disclosure allows holders to prove specific claims from a credential without revealing the entire document.

• Zero-Knowledge Proofs (ZKPs): Enable holders to generate proofs for predicates (e.g., 'age > 21') without revealing the actual birth date.
• Blinded Signatures: In some schemes, the issuer can sign a credential without seeing its final contents, preventing correlation.
• Minimal Disclosure: The principle of sharing the least amount of data necessary for a verification.

Trust in a credential is predicated on trust in its issuer. The protocol relies on Decentralized Identifiers (DIDs) and Verifiable Data Registries.

• DID Resolution: The verifier resolves the issuer's DID to a DID Document containing public keys and service endpoints.
• Key Rotation: DID Documents allow for secure key rotation and revocation in case of issuer key compromise.
• Trust Registries: External frameworks or smart contracts that maintain lists of authorized or accredited issuers for specific credential types.

The structure and semantic meaning of credential data must be trustworthy. This is managed through credential schemas.

• Immutable Schemas: Schemas are often published to an immutable ledger or content-addressable storage (e.g., IPFS) to prevent tampering.
• Schema Registries: Trusted registries provide discoverability and versioning for schemas, ensuring verifiers and issuers reference the same data structure.
• Governance Models: Defining who can create and update schemas for high-stakes credentials (e.g., academic degrees, professional licenses) is a critical trust decision.

The issuance protocol itself must be resilient to known attack vectors.

• Replay Attacks: Prevented by including unique identifiers (nonces) and issuance timestamps in the credential.
• Phishing & Fake Issuers: Mitigated by rigorous DID resolution and reliance on trusted root-of-trust registries.
• Correlation Attacks: Addressed through privacy-preserving techniques like ZKPs and unlinkable credential identifiers.
• Key Management: The security of the entire system depends on the issuer's and holder's secure key storage practices.

A major application is reusable Know Your Customer (KYC) attestations. A bank (issuer) can issue a verifiable credential to a user (holder) after initial onboarding. The user can then present this credential to other financial institutions (verifiers), eliminating redundant paperwork. This reduces friction, enhances user control over data, and lowers compliance costs through selective disclosure.

Universities and certification bodies use the protocol to issue tamper-proof digital diplomas and licenses. A graduate holds a credential that can be instantly verified by employers without contacting the issuing institution. This combats credential fraud and creates a lifelong, portable learner record. Systems like Blockcerts were early pioneers of this model.

The Holder is the entity, typically an end-user, that receives, stores, and controls the presentation of Verifiable Credentials. In the Issue Credential Protocol, the holder is the recipient in the credential exchange. Key responsibilities include:

• Managing a Digital Wallet to securely store issued VCs.
• Providing Consent for the issuance and any data sharing.
• Selectively Disclosing credentials to verifiers using the Present Proof protocol. The protocol ensures the credential is delivered securely to the holder's agent.

A Verifier is the entity that requests and checks the validity of Verifiable Credentials presented by a holder. While not a direct participant in the issuance protocol, the verifier is the ultimate consumer of its output. Their role involves:

• Specifying Proof Requests for required credentials and claims.
• Cryptographically Verifying the issuer's signature and credential status.
• Trusting the Issuer's authority and adherence to standards. The value of the Issue Credential Protocol is realized when a verifier accepts its output.

The Present Proof Protocol is the complementary protocol to Issue Credential, governing how a holder shares credentials with a verifier. It defines the message flow for:

• Proof Request: A verifier asks for specific credentials, often with constraints.
• Proof Presentation: The holder constructs a Verifiable Presentation—a wrapper for one or more VCs—and sends it back.
• Verification: The verifier checks the presentation's validity. This protocol consumes the credentials created by the Issue Credential Protocol.

A Credential Schema is a blueprint that defines the structure and data types for the claims within a Verifiable Credential. It ensures interoperability by standardizing the semantic meaning of fields. During issuance:

• The issuer references a specific Schema ID within the credential metadata.
• This allows verifiers to programmatically understand the data structure (e.g., degreeType is a string, issueDate is a datetime).
• Schemas are often published to a verifiable data registry (like a blockchain) to ensure immutability and discoverability.