Frequently Asked Questions (FAQ)

As a CA within Otentik’s VDS scheme, you are a specialized Trust Service Provider (TSP). Your core function is to issue the X.509 digital signing certificates that VDS Issuers use to create Visible Digital Seals. You play a critical role in the chain of trust by validating certificate requests and ensuring certificates comply with Otentik’s scheme policies and VDSIC standards.

You must meet stringent technical, security, and policy requirements, including:

• Adhering to VDSIC’s TSP Requirements.
• Maintaining a compliant Certificate Policy (CP) and Certification Practice Statement (CPS) aligned with Otentik’s scheme rules and VDSIC standards (e.g., ETSI EN 319 411).
• Operating highly available and secure infrastructure (incl. certified HSMs, ISO 27001 aligned ISMS).
• Implementing robust processes for certificate lifecycle management (issuance, revocation via CRL/OCSP).
• Crucially, implementing technical validation of a VDS Issuer’s authorization for requested Manifest UUIDs (for the UsageList extension) against Otentik’s authoritative source before certificate issuance.
• Undergoing regular independent audits (e.g., WebTrust for CAs).

This is a critical function. When a VDS Issuer requests a certificate containing specific Manifest UUIDs in the vdsic.security.usageList extension, your CA systems must technically verify the Issuer’s authorization for each requested UUID. This verification uses the mechanism defined by Otentik (e.g., querying an Otentik-managed registry API, processing a secure list). You must not issue a certificate including any UUID for which the Issuer is not authorized according to Otentik’s authoritative source. This process must be documented in your CPS.

High availability is mandatory. You must define and meet strict Service Level Objectives (SLOs) for your revocation information services (e.g., >= 99.9% uptime) and ensure timely updates according to your CPS and Otentik’s requirements (e.g., prompt OCSP updates post-revocation, CRL publication before the previous one expires).

You typically need annual independent third-party audits, such as WebTrust for CAs or ETSI EN 319 411 audits. Compliance with relevant security standards like ISO/IEC 27001 may also be required or audited. Attestations must be provided to Otentik and/or VDSIC.

Contact Otentik directly at [email protected] to express interest. We will provide details on our specific scheme requirements and guide you through the application and assessment process, which includes reviewing your technical capabilities, CP/CPS, and audit status.

As a VDS Issuer, your organization is responsible for creating the actual Visible Digital Seals for specific documents or products (e.g., certificates, invoices, product labels) according to the rules of Otentik’s VDS scheme. You use a digital signing certificate, obtained from an accredited Certificate Authority (CA) within our scheme, to generate the VDS.

Each type of VDS corresponds to a “Manifest UUID”. To issue a specific type of VDS, you must first be formally authorized by Otentik (the Scheme Operator) for that specific Manifest UUID. The process involves:

• Applying to Otentik for authorization for the specific Manifest UUID(s) relevant to your use case.
• Meeting Otentik’s criteria for authorization (which may involve vetting your organization and use case).
• Once authorized by Otentik, you can request a signing certificate from an accredited CA, specifying the authorized UUID(s).

When requesting your VDS signing certificate from a CA accredited under Otentik’s scheme, you will need to:

• Complete the CA’s identity verification and certificate request process.
• Specify the exact Manifest UUID(s) that Otentik has authorized you to use. These will be included in the certificate’s vdsic.security.usageList extension. The CA is required to verify your authorization for these UUIDs with Otentik before issuing the certificate.

Your primary responsibilities include:

• Obtaining proper authorization from Otentik for the Manifest UUIDs you intend to issue.
• Accurately representing your identity and authorization status to the CA.
• Securely managing the private key associated with your VDS signing certificate.
• Generating VDS instances that comply with the VDSIC technical specification (KD036) and Otentik’s scheme rules.
• Ensuring the data included in the VDS is accurate and appropriate for the authorized Manifest UUID.

You will need software capable of generating the VDS structure according to the VDSIC specification and signing it using your private key. Depending on your security requirements and volume, you might manage your signing key within a Hardware Security Module (HSM) or other secure environment. Otentik or the VDSIC may provide guidance or lists of compatible software/service providers.

To begin the process of becoming an authorized VDS Issuer within Otentik’s scheme, please contact Otentik directly at [email protected] to discuss your use case and the authorization requirements.

A VDS is a secure, often visually represented (like a QR code), digital seal on a document or product. When successfully verified, it confirms:

• Authenticity: Who issued the VDS (the VDS Issuer).
• Integrity: That the core data associated with the VDS has not been tampered with since it was issued.
• Compliance: That it was issued under the rules of a specific VDS scheme, like Otentik’s ([mention Otentik’s specific scheme name]).

Verification typically involves using a VDS verification application (e.g., a smartphone app or integrated software). The process generally includes:

• Scanning or inputting the VDS.
• The app checks the digital signature on the VDS.
• It retrieves the VDS Issuer’s certificate used for signing.
• It checks the validity of the certificate (if it’s expired or revoked using CRL or OCSP).
• It verifies that the certificate chains up to a trusted root certificate via the Trust Lists (TSLs) published under Otentik’s Scheme List of Trusted Lists (LoTL).

Trust Lists are crucial for verification. Otentik, as the Scheme Operator, publishes a “Scheme List of Trusted Lists” (LoTL). This LoTL points to the specific “Trust Service Lists” (TSLs) of the accredited Certificate Authorities (CAs) operating within our scheme. These TSLs contain information about the CAs, their active certificates, and pointers to where revocation information (CRL/OCSP) can be found. Your verification software uses Otentik’s LoTL and the referenced TSLs to establish trust in the VDS Issuer’s certificate.

Otentik’s Scheme LoTL URI is typically listed within the VDSIC Governance List (Root LoTL) or made available directly by Otentik on its website at [Link to Otentik’s website/LoTL location]. Verification applications are often configured to automatically retrieve and update these lists.

A successful verification (“valid” VDS) indicates that:

• The digital signature is mathematically correct.
• The signing certificate was valid (not expired, not revoked) at the time of checking (or time of signing, depending on verification policy).
• The signing certificate was issued by a CA trusted under Otentik’s scheme, as confirmed via the LoTL/TSLs.
• The data integrity is intact.

Yes, you need a verification application or software capable of performing the VDS verification steps according to VDSIC standards. Various providers offer such applications, and Otentik may recommend or provide specific tools for verifying VDS within its scheme. Check [Otentik’s website or relevant resource page] for recommendations.

A failed verification means the authenticity or integrity of the VDS cannot be confirmed. The data or issuer should not be trusted based on the VDS alone. The reason for failure (e.g., expired certificate, revoked certificate, invalid signature, untrusted issuer) may be indicated by the verification app. You should follow your organization’s procedures for handling untrusted documents or data.

Providing a VDS solution means creating software, platforms, integration services, or consulting offerings that enable organizations to either issue, verify, or manage Visible Digital Seals. This could include:

• Issuance Platforms: Software or services allowing authorized organizations (VDS Issuers) to generate VDS instances for documents or products.
• Verification Tools: Applications (mobile, web, SDKs) or services that allow users or systems (Relying Parties) to check the authenticity and integrity of a VDS.
• Integration Services: Helping organizations integrate VDS issuance or verification capabilities into their existing workflows and systems (e.g., ERP, document management, credentialing platforms).
• Consulting: Advising organizations on implementing VDS strategies, choosing use cases, and navigating the VDS ecosystem.

You should be familiar with:

• VDS International Council (VDSIC): The governing body setting standards.
• Scheme Operators (SOs / TSOs): Entities managing specific VDS schemes (like Otentik), defining rules, accrediting participants within their scheme, and publishing Scheme Lists of Trusted Lists (LoTLs).
• Trust Service Providers (TSPs) / Certificate Authorities (CAs): Entities accredited by SOs to issue the signing certificates used by VDS Issuers and provide revocation services (CRL/OCSP).
• VDS Issuers: Organizations authorized by an SO to create specific types of VDS using certificates from an accredited CA.
• Relying Parties / Verifiers: Individuals or systems checking the validity of a VDS.
• Trust Lists (LoTL/TSL): The machine-readable lists that link trusted CAs to the Scheme Operator and ultimately to the VDSIC root, enabling verification.

Key standards include:

• VDS Specification and Usage: Defines the VDS data structure, processing rules, certificate profiles, and TSL extensions. This is essential reading.
• ETSI TS 119 612: The base standard for Trust Service Lists (TSLs).
• X.509 Standards: For understanding digital certificates.
• CRL/OCSP Standards: For certificate revocation checking.
• Relevant Cryptographic Standards (for signature algorithms, hashing, etc.)

Generally, no. Most VDS solution providers build tools and services that interact with the existing ecosystem. Your customers would typically be VDS Issuers (using your issuance platform) or Relying Parties (using your verification app). These customers would need to engage with an accredited CA (for certificates) and operate under the rules of a Scheme Operator. Your role is to provide the technology that facilitates these interactions correctly and securely.

Your verification software MUST be designed to:

• Securely fetch the relevant Scheme LoTL(s) and the TSLs they reference.
• Process these lists according to VDSIC specifications.
• Use the information (trusted CA certificates, service pointers) to validate the certificate chain of a presented VDS back to a trusted anchor defined by the Scheme Operator / VDSIC.
• Perform revocation checks (CRL/OCSP) using endpoints listed in the TSLs.

Your issuance platform should:

• Securely manage the VDS Issuer’s signing credentials (private key).
• Generate VDS structures compliant with KD036.
• Correctly encode the data provided by the Issuer.
• Apply the digital signature using the Issuer’s key.
• Crucially, if your solution helps Issuers request certificates from CAs, it must support the mechanisms needed for the CA to verify the Issuer’s authorization for specific Manifest UUIDs (often via the UsageList extension), as mandated by the relevant Scheme Operator. Your software facilitates this; the CA performs the check against the SO’s authoritative source.

Strictly adhere to the VDSIC KD036 specification for VDS structure and processing. Ensure correct cryptographic operations, proper handling of certificates, trust lists, and revocation checking. Participate in interoperability testing events if offered by VDSIC or Scheme Operators.

• Thoroughly study the VDSIC specification.
• Identify your target market and the specific type of solution (issuance, verification, integration) you want to offer.
• Understand the roles and requirements within the VDS ecosystem.
• Consider potential partnerships with Scheme Operators or CAs.
• Start developing based on the technical specifications.

An Otentik VDS Solution is a software application, platform, or service designed specifically to operate within the VDS scheme managed by Otentik (acting as the accredited Scheme Operator). This means your solution must not only comply with global VDSIC standards but also adhere to the specific rules, policies, and trust framework defined by Otentik.

Key differences include:

• Scheme-Specific Rules: Your solution must respect any additional policies or technical requirements set by Otentik beyond the base VDSIC standards.
• Accredited Participants: Your solution must interact correctly with CAs specifically accredited by Otentik for its scheme.
• Otentik’s Trust Anchor: Verification solutions must be configured to use Otentik’s Scheme List of Trusted Lists (LoTL) as the entry point for establishing trust within the scheme.
• Manifest Authorization: Issuance solutions must support the process where CAs validate an Issuer’s authorization for specific Manifest UUIDs against the authoritative source managed by Otentik.

Otentik manages the overall health and rules of its scheme. This includes accrediting CAs, publishing and maintaining the authoritative Scheme LoTL, and managing the authorization process for VDS Issuers and their specific Manifest UUIDs. Depending on your solution (especially if it involves issuance or specific integrations), you may need to coordinate with Otentik, potentially through partnership programs or compatibility testing.

Your issuance platform must enable your VDS Issuer clients to specify the Manifest UUIDs they are authorized by Otentik to use. Furthermore, your system should facilitate the process where the CA (chosen by the Issuer from Otentik’s accredited list) can perform the mandatory check of these UUIDs against Otentik’s authoritative authorization source before issuing the certificate containing the UsageList extension. Your software must not interfere with or bypass this crucial validation step performed by the CA.

Your verification tool MUST be configured to:

• Retrieve and trust Otentik’s specific Scheme LoTL URI.
• Correctly process Otentik’s LoTL and the TSLs it references to validate VDS instances originating from within Otentik’s scheme.
• Perform revocation checks using the CRL/OCSP endpoints specified by the CAs listed in Otentik’s TSLs.

Typically, solution providers (who are not acting as CAs or VDS Issuers themselves) may not require formal accreditation from Otentik. However, Otentik may have:

• Partnership programs for solution providers.
• Compatibility testing or certification for verification/issuance tools to ensure they work correctly within the scheme.
• Specific requirements for solutions integrating deeply with their infrastructure.
• It’s essential to contact Otentik directly to understand their policies regarding third-party solution providers.

You should contact Otentik directly at [email protected] or visit developer/partner portal (if available). We can provide access to our scheme-specific documentation, policies, the LoTL URI, and details about our Manifest UUID authorization mechanism.

• Contact Otentik to express your interest and understand our partnership model.
• Obtain and thoroughly review Otentik’s scheme-specific documentation alongside VDSIC standards.
• Clearly define the type of solution you intend to build (issuance, verification, integration).
• Design your solution architecture to explicitly accommodate Otentik’s LoTL, accredited CAs, and the Manifest UUID authorization process.
• Engage with Otentik for any required testing or validation.