OpenCerts Documentation

website·Indexed 35 days ago

https://docs.opencerts.io/

Documentation for OpenCerts, a Singapore Smart Nation initiative for the issuance and validation of tamper-resistant certificates. Covers versions v1, v2, and v3, including the use of TrustVC for W3C Verifiable Credentials, identity verification, multi-issuer workflows, and the OpenCerts Schema for certificates and transcripts.

Tokens
21.2K
Snippets
79
Records
149
Agent score
61%

What's inside OpenCerts

  1. Overview of the OpenCerts Certificate Store

    v1
    A Certificate Store is a registry of issued and revoked certificates used by OpenCerts.io to verify certificate authenticity. Institutions must deploy at least one instance of the Certificate Store smart contract on the Ethereum public main net. The contract is configured for public-read and owner-write access.
  2. Overview of OpenCerts v3 and TrustVC

    OpenCerts v3 is built on TrustVC, a wrapper library that supports both W3C Verifiable Credentials (VC) Data Model v2.0 and OpenAttestation Verifiable Documents. Key upgrades include support for cryptosuites ecdsa-sd-2023 and bbs-2023, selective disclosure capabilities, and the use of did:web Decentralized Identifiers with Multikey verification methods for issuer identity.
  3. Understand the relationship between OpenCerts and OpenAttestation

    v2
    OpenCerts is a specific implementation of the OpenAttestation standard. While OpenAttestation provides the general standard for creating Verifiable Documents, OpenCerts specifically applies this standard to enable institutions to create, issue, and validate tamper-resistant academic certificates.
  4. Understand the Skills Passport repository

    v2
    Skills Passport is a feature of SkillsFuture Singapore’s MySkillsFuture website. It acts as a central depository for an individual's records, including skills, certificates, licenses, and other achievement records. Users can selectively share these records with potential employers using the 'Share Skills Passport' function.
  5. OpenCerts v3 Overview and Key Changes

    OpenCerts v3 is built on the TrustVC framework, moving away from the direct use of OpenAttestation seen in v2. Key upgrades include:

    • W3C Verifiable Credentials: Adoption of the W3C VC Data Model v2.0 for better global interoperability.
    • TrustVC Framework: A unified library supporting both W3C VC and OpenAttestation documents, including signing (ecdsa-sd-2023, bbs-2023), verification, and selective disclosure.
    • DID-based Identity: Issuers now use did:web Decentralized Identifiers with Multikey verification methods.
  6. OpenCerts Certificate Data Schema Overview

    v1
    OpenCerts files are .json files conforming to the OpenAttestation specification. The actual certificate data is stored under the data key and must conform to the OpenCerts JSON schema (v1.5). The schema defines the structure of the certificate object, including identity, issuance details, issuer information, and recipient details.
  7. Verify issuer identity in OpenCerts

    To ensure certificates are issued by the correct identity, OpenCerts verifies that at least one of the following conditions is met:

    1. The issuer identity is registered in the OpenCerts registry.
    2. The issuer has a valid DNS-TXT record associated with its document store.

    If neither condition is fulfilled, the certificate is considered to be from an unknown source and is declared invalid. Note: The OpenCerts registry has been ceased.

  8. Set up credential revocation using trustvc-cli

    In v3, revocation is handled off-chain using the W3C Bitstring Status List instead of the on-chain Document Store. You must host the status list yourself over HTTPS with CORS enabled.

    1. Create the status list: Run the creation command and provide the key pair path, cryptosuite, the intended hosting URL, output directory, and list length (default is 131072).
    2. Link the VC to the list: When authoring the unsigned VC, add a credentialStatus field containing the list URL and a unique index for that specific credential.
    3. Revoke a credential: Use the update command to modify the hosted list by specifying the existing list path/URL, your key pair, and the index to revoke or suspend. Re-host the updated file at the original URL.
    # Create a new status list
    trustvc credential-status-create
    
    # Update/Revoke a credential in an existing list
    trustvc credential-status-update
    "credentialStatus": {
      "id": "https://your-domain.com/credentials/statuslist/1#94567",
      "type": "BitstringStatusListEntry",
      "statusPurpose": "revocation",
      "statusListIndex": "94567",
      "statusListCredential": "https://your-domain.com/credentials/statuslist/1"
    }
  9. Host a credential status list

    The signed status list VC must be hosted at the URL specified in the statusListCredential field. To ensure verifiers can access the list, the following requirements must be met:

    • The endpoint must be publicly accessible over HTTPS.
    • CORS must be enabled (Access-Control-Allow-Origin: *) to allow web-based verifiers to perform checks.
    • The Content-Type header must be set to application/json.
  10. Migrate to the Opencerts v2 renderer

    v2

    To migrate to the new Opencerts v2 renderer, follow these steps to ensure template correctness and style consistency:

    1. Define Certificate Types: Explicitly type your certificate to prevent the misuse of properties during template authoring.
    2. Adapt the Template: Copy the provided template and perform necessary transformations, such as converting to TypeScript or integrating third-party libraries.
    3. Update Styles: Reconfigure styles to account for differences between the new repository and the legacy renderer.
    4. Handle Dependencies: Perform necessary library upgrades. For example, ensure your code is compatible with the latest version of date-fns if used in your template.
    5. Configure Template: Finalize the template configuration settings.
  11. Migrate from OpenCerts v1.5 to v2.0 Decentralized Rendering

    v2
    OpenCerts v2.0 moves away from a centralized GitHub repository for certificate templates. Instead of submitting pull requests to the main repository, institutions must now host their own decentralized renderer. This removes the need for manual approval of templates and increases fault tolerance, as code errors in one institution's renderer will not affect others.