§ Legally-Binding Proof of Personhood for Verifiable Credentials via QES

§ Abstract

This specification defines a mechanism for creating legally binding Verifiable Credentials (VCs)^[1] by binding them to Qualified Electronic Signatures (QES)^[2] under frameworks such as eIDAS 2.0. The approach utilizes a one-way cryptographic binding where the QES signs a digest of the VC as a challenge, ensuring the signer’s verified identity (e.g., via KYC processes) is tied to the VC content without modifying the original VC. A new “Binding Credential”^[3] (a VC) serves as the umbrella structure, embedding the original VC as attachment and the QES-wrapped artifact via integrity-protected properties, enabling reusability, privacy-preserving measures through Selective Disclosure JSON Web Tokens (SD-JWT)^[4].

§ Introduction

Verifiable Credentials (VCs) as defined in the Verifiable Credentials Data Model 2.0 VC-DATA-MODEL-2.0 provide a mechanism for asserting claims in a tamper-evident and privacy-respecting manner. However, in regulated environments requiring legal enforceability, such as under the European Union’s eIDAS Regulation (EU) No 910/2014 and its 2.0 amendments, VCs must be bound to Qualified Electronic Signatures (QES) to achieve equivalence to handwritten signatures. This legal equivalence is established in Article 25 of the regulation, which states that a qualified electronic signature shall have the equivalent legal effect of a handwritten signature.

This specification introduces a one approach for achieving a one-way binding between a VC and a QES-backed identity attestation (e.g., incorporating a KYC hash^[5]). The binding ensures the VC is cryptographically approved by a verified signer without altering the VC’s original signature payload. This avoids invalidation issues associated with direct modifications (e.g., adding references via evidence to the original), as any change to a signed VC’s content would break the issuer’s original cryptographic signature. Instead, a new Binding Credential encapsulates the original VC, and adds the QES-related fields supporting privacy enhancements via SD-JWT.

§ Motivation

Traditional VC issuance, focuses on issuer signatures to attest claims about a subject, but lacks inherent mechanisms for the holder to make their own legally-binding commitments related to the credential. In scenarios like contracts, attestations, or access rights, binding a VC to a QES provides non-repudiation^[6] of both KYC and legal validity. These properties are established by the eIDAS Regulation, where Article 25 guarantees legal validity and Article 26’s requirements for signature creation provide the safeguards to guarantee non-repudiation. The goal of this spec is to define a standard procedure and packaging format using QES to sign VC digests for binding, with privacy wrappers to minimize data exposure. This specification formalizes that into a method aligned with emerging standards like SD-JWT for Verifiable Credentials SD-JWT-VC and eIDAS 2.0 wallet integrations, using a reusable VC structure for persistence.

§ Scope

This specification covers:

• One-way binding via QES challenge signatures^[7].
• Enveloping via a new Binding Credential VC.
• Privacy-preserving wrappers using SD-JWT.
• Verification workflows, security, and privacy considerations.

Out of scope: Multi-party signatures, dynamic proof requests (e.g., via DIDComm), or non-eIDAS signature schemes.

§ Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The keywords MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 RFC2119 when, and only when, they appear in all capitals, as shown here.

§ Binding Mechanism

§ Overview

The binding is one-way: The QES attests to the VC by signing its digest, tying the signer’s verified identity (e.g., KYC level) to the VC content. This avoids circular dependencies—where the VC would need to reference the QES signature and the QES signature would need to reference the VC, creating a deadlock—and preserves the VC’s immutability. The QES is wrapped for privacy and referenced in a new Binding Credential for reusability.

§ QES Challenge Signature

The QES MUST sign a message that includes:

• The digest of the VC JSON payload (e.g., using SHA-256).
• Optional metadata (e.g., timestamp, intent like “approve VC”).

The signature format SHALL conform to eIDAS-qualified standards. The resulting QES artifact MAY include the qualified certificate chain for verification.

Algorithm:

1. Compute vcDigest = hash(serialize(VC)) where hash is SHA-256.
2. Construct challenge message: { "challenge": vcDigest, "nonce": string }.
3. Sign the message with QES: qesSignature = signQES(challengeMessage).

This creates a detached signature binding the QES holder’s identity to the VC.

§ Privacy Wrappers

To preserve privacy, the QES artifact SHALL be wrapped as:

• SD-JWT: Encode QES details (e.g., certificate thumbprint, signed challenge) with selective disclosure claims (e.g., _sd for hidden attributes). The SD-JWT MAY include a Key Binding JWT (KB-JWT) to prove holder possession.

Wrappers MUST NOT expose unnecessary identity details, adhering to data minimization principles.

§ Umbrella Structure: Binding Credential

The umbrella SHALL be a new VC conforming to VC-DATA-MODEL-2.0, termed a Binding Credential:

• type: [“VerifiableCredential”, “BindingCredential”] (extension type RECOMMENDED).
• evidence: An array of objects, each referencing:
  • The original VC (via URI, with digestMultibase for integrity).
  • The privacy-wrapped QES artifact (via URI or embedded as a data URI, with digest).
• Alternatively, use relatedResource for external integrity-protected references.
• Signed by the holder or a trusted issuer using a securing mechanism (e.g., JOSE for JWT/SD-JWT or DataIntegrityProof).

This structure ensures reusability, as the Binding Credential can be stored and presented like any VC.

Example (JSON) – TO BE UPDATED:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "BindingCredential"],
  "id": "http://example.com/bindings/123",
  "issuer": "did:example:holder",
  "credentialSubject": {
    "id": "did:example:subject",
    "bindingDescription": "QES-bound University Degree"
  },
  "evidence": [
    {
      "type": ["VerifiableCredentialReference"],
      "id": "http://example.edu/credentials/3732",
      "digestMultibase": "z01... (multihash of original VC)"
    },
    {
      "type": ["QESArtifact"],
      "id": "data:application/sd-jwt;base64,... (wrapped QES)",
      "digestMultibase": "z01... (multihash of QES wrapper)"
    }
  ],
  "proof": {
    "type": "JsonWebSignature2020",
    // ... signature details
  }
}

§ Verification Workflow

Verifiers SHALL:

1. Validate the Binding Credential’s signature.
2. Fetch/resolve references in evidence or relatedResource.
3. Verify the original VC signature and match its digest.
4. Extract the wrapped QES artifact and verify:
   • The QES signature over the challenge.
   • That the challenge matches the VC digest.
   • QES certificate validity (e.g., via OCSP).
5. Process SD-JWT disclosures.

Verification MUST fail if any binding check mismatches.

§ Examples

§ Use case Sequence Diagram

§ Basic Binding Example (Non-Normative)

Consider a VC asserting a degree. The holder creates a QES signing the VC digest, wraps it in SD-JWT, and issues a Binding Credential referencing both for presentation to an employer.

§ Security Considerations

• Digest Collisions: Use collision-resistant hashes (e.g., SHA-256).
• Replay Attacks: Include cryptographic nonce in challenge.
• Certificate Revocation: Verifiers MUST check QES status via CRL/OCSP.
• Side-Channel Attacks: Minimize metadata in references to avoid timing or correlation risks.

§ Privacy Considerations

• Data Minimization: Use SD-JWT to disclose only necessary claims; reference rather than embed where possible.
• Consent: Holders MUST control issuance and presentation; align with GDPR/eIDAS data protection.
• Metadata Leakage: Use anonymous URIs if references could enable tracking.

§ IANA Considerations

This document has no IANA actions.

§ Acknowledgements

This specification builds on concepts from decentralized identity labs proposals for beta-cohort-2-2025, incorporating feedback on QES-VC bindings and structure reusability.

§ References

§ Normative References

• VC-DATA-MODEL-2.0 Verifiable Credentials Data Model v2.0. W3C Recommendation.
• SD-JWT Selective Disclosure for JWTs. IETF Draft.
• RFC2119 Key words for use in RFCs to Indicate Requirement Levels.
• RFC8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.

§ Informative References

• eIDAS Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC.
• RFC7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs). M. Jones. IETF RFC 7800.
• SD-JWT-VC SD-JWT for Verifiable Credentials. IETF Draft.
• VC-DATA-INTEGRITY Verifiable Credential Data Integrity 1.1. W3C Working Draft.

§ Terminology

This section defines the terms used in this specification. A link to these terms is included whenever they appear in the document.