Enabling Global Verifiable Trust
The Visible Digital Seal (VDS) offers robust digital security thanks to its operation within a clearly defined Trust Environment. This comprises distinct entities with specific roles and responsibilities, all of which are governed by the Visible Digital Seal International Council (VDSIC). This structured approach ensures standardised interactions, clear accountability, global interoperability and a reliable foundation for verifying the authenticity and integrity of VDS data. It also aligns with the governance principles of ISO 22385.
Key Roles and Responsibilities
The environment of the VDS relies on the clear definition and execution of roles by several key participants:
VDSIC – The Governance Board
VDSIC hosts Governance Board which establishes the foundational trust and rules.
Sets Global Standards: Defines and maintains the core VDS technical specifications, operational policies, and security requirements.
Manages Root Trust: Operates and secures the Governance List (Root LoTL), the ultimate trust anchor referencing accredited Scheme Operators.
Accredits Scheme Operators: Evaluates and approves organizations to act as Scheme Operators for specific VDS domains (e.g., countries, industries).
Ensures Global Interoperability: Facilitates harmonization to ensure VDS verification works seamlessly across different schemes and platforms.
Provides Oversight: Monitors compliance and security practices across the environment.
Scheme Operator (TSO)
Operating under VDSIC’s authority, the Scheme Operator manage specific VDS schemes.
Manage Scheme Trust: Establish and maintain lists (Scheme LoTLs), which list the accredited Trust Service Providers (TSPs) and authorized Trust Service Lists (TSLs) within their specific domain.
Define Scheme Policies: May set scheme-specific policies and requirements, complementing VDSIC’s global standards.
Validate Manifests: Validate the scope of Manifest IDs within their scheme (via VDSManifestScope extension), ensuring uniqueness and preventing overlaps. Sign and publish the Manifest files used within their scheme.
Oversee Scheme Participants: Monitor the compliance of TSPs (including CAs) and VDS Issuers operating under their scheme’s rules.
Trust Service Providers (TSPs) & Certificate Authorities (CAs)
TSPs, often acting as Certificate Authorities (CAs), are the entities accredited to issue the digital credentials underpinning VDS security.
Issue Signing Certificates: Provide X.509 digital certificates to authorized Issuers of VDS after rigorous identity validation, adhering to VDSIC and Scheme Operator policies (e.g., based on ETSI EN 319 411-1).
Manage Certificate Lifecycle: Securely handle the entire lifecycle of VDS signing certificates, including issuance, renewal, suspension, and critically, revocation (providing CRLs or OCSP services).
Maintain Trust Service Lists (TSLs): Publish and maintain digitally signed TSLs (compliant with ETSI TS 119 612 and VDSIC extensions) that list their services, authorized CAs (VDSAuthorityID), and provide crucial URIs for accessing public certificates (VDSCertResource) and Manifest files (VDSManifestResource).
Ensure Security: Employ robust security practices, including secure key generation and management (often using Hardware Security Modules – HSMs), compliant with international standards (ISO 27002).
VDS Issuers
These are the organizations authorized by Scheme Operator within a specific scheme to create and sign instances of VDS.
Generate VDS’s instances: Create Visible Digital Seals strictly following the rules and constraints defined in the specific Manifest file for their use case.
Sign VDS Data: Use their private key (corresponding to a valid, CA-issued certificate) to cryptographically sign the VDS Header and Payload hash, ensuring data authenticity and integrity.
Secure Key Management: Responsible for securely protecting their private signing keys.
Comply with Rules: Adhere to all operational and technical standards set by their Scheme Operator.
Verification Applications (TEPs – Trusted Entry Points)
TEPs are the crucial endpoint applications that read and verify VDS’s data.
Acquire VDS’s Data: Read VDS’ ‘s data from various carriers (QR codes, NFC tags, digital files, URL fragments).
Execute Verification Process: Perform the step-by-step validation: check VDS structure, traverse the trust chain (TSLs), retrieve and validate the Manifest, retrieve and validate the signing certificate (including revocation checks), and cryptographically verify the VDS signature.
Interpret & Present Data: Use the validated Manifest to correctly decode and interpret the VDS’ ‘s Payload. Utilize the Response Formatting Function (RFF) defined in the Manifest to securely and consistently display the verified information to the end-user.
Essential Environment Resources
Trust Lists (TSLs – Root LoTL, Scheme LoTL, TSL): Digitally signed XML documents forming a verifiable chain. They list trusted entities and provide secure pointers (URIs) to locate other TSLs, Manifests, and public certificates. VDSIC defines specific XML extensions to the ETSI TSL standard for the VDS’s needs.
Use Case Manifests: Digitally signed XML documents defining everything about a specific VDS type: its data schema (Payload/AuxData structure, types, constraints), validation policies (validity periods, authorized usage), extensions, and the secure presentation format (RFF). Each VDS instance points to its specific Manifest via an ID in the header.
X.509 Signing Certificates: The digital credentials issued by CAs to VDS Issuers. They securely link an Issuer’s identity to their public key, contain specific VDS-related policy OIDs and extensions (e.g., UsageList, TestCertificate), and enable signature verification.
Trust Chain
- A TEP acquires VDS data and reads the identifiers (Manifest ID, CA/Cert reference) from the header.
- Starting from a pre-configured Trust Anchor (typically the VDSIC Root LoTL or a Scheme LoTL), the TEP retrieves and validates the TSL chain using digital signatures.
- The TEP follows pointers in the validated TSLs to locate and retrieve the correct Manifest file (based on the Manifest ID and defined scopes) and the Signing Certificate (based on CA/Cert reference).
- The TEP validates the Manifest’s signature (signed by the Scheme Operator) and the Signing Certificate’s validity (chaining back to the trust anchor, checking revocation).
- Using the validated Manifest, the TEP processes the VDS Payload.
- Using the validated public key from the Signing Certificate, the TEP verifies the VDS Signature.
- If all checks pass, the TEP uses the RFF from the validated Manifest to display the verified data.
