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.
What's inside OpenCerts
- 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.
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 cryptosuitesecdsa-sd-2023andbbs-2023, selective disclosure capabilities, and the use ofdid:webDecentralized Identifiers with Multikey verification methods for issuer identity.Understand the relationship between OpenCerts and OpenAttestation
v2OpenCerts 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.Understand the Skills Passport repository
v2Skills 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.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:webDecentralized Identifiers with Multikey verification methods.
OpenCerts Certificate Data Schema Overview
v1OpenCerts files are.jsonfiles conforming to the OpenAttestation specification. The actual certificate data is stored under thedatakey 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.Understand the OpenCerts Identity Registry
v1OpenCerts maintains a registry to associate the identity of a contract store owner with a physical legal entity. This registry is stored as a flat JSON file available at https://opencerts.io/static/registry.json. Certificates issued by institutes listed in this registry will display 'Accredited by SSG' in their verification status.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:
- The issuer identity is registered in the OpenCerts registry.
- 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.
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.
- 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).
- Link the VC to the list: When authoring the unsigned VC, add a
credentialStatusfield containing the list URL and a unique index for that specific credential. - 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" }Host a credential status list
The signed status list VC must be hosted at the URL specified in the
statusListCredentialfield. 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-Typeheader must be set toapplication/json.
Migrate to the Opencerts v2 renderer
v2To migrate to the new Opencerts v2 renderer, follow these steps to ensure template correctness and style consistency:
- Define Certificate Types: Explicitly type your certificate to prevent the misuse of properties during template authoring.
- Adapt the Template: Copy the provided template and perform necessary transformations, such as converting to TypeScript or integrating third-party libraries.
- Update Styles: Reconfigure styles to account for differences between the new repository and the legacy renderer.
- Handle Dependencies: Perform necessary library upgrades. For example, ensure your code is compatible with the latest version of
date-fnsif used in your template. - Configure Template: Finalize the template configuration settings.
Migrate from OpenCerts v1.5 to v2.0 Decentralized Rendering
v2OpenCerts 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.