Certificate verification

:::info Planned work This page describes what runs today. A redesign with automatic issue, review queues and a managed lifecycle is specified in .kiro/specs/certificate-lifecycle/ and is not built. See ADR 11. :::

Someone holding a certificate, such as an investor or a registrar, can check it without an account. Three operations are public: verify, PDF and QR. The certificate's own identifier, a random UUID, is the capability.

Certificate verification. A verifier scans the QR code on a certificate, which opens the verification page on the site. The page calls the public verify endpoint on the LMS service with the certificate id. The service looks the id up and returns the number, holder name, course, dates and a valid flag that is true only for an issued certificate that has not expired. An unknown id returns 404 with valid false. The PDF and QR endpoints use the same id.

What is public and what is not

Only three path shapes skip the token check: /certificates/verify/*, /certificates/*/pdf and /certificates/*/qr. The register, issue, eligibility, my-certificates and the JSON by id need a bearer token.

The key is the certificate's identifier, not its number. Certificate numbers run in sequence (RTIH-<year>-<5 digits>), so an open endpoint keyed on the number would have listed every holder. A number no longer resolves on the verify endpoint.

Validity

Being in the register is not the same as being valid. The response says valid: true only for a certificate with status ISSUED whose validUntil, if any, has not passed.

Sources: services/lms-service/src/main/java/com/rtih/startupos/lms/{resource/CertificateResource,service/CertificateService}.java, services/lms-service/src/main/resources/application.yml (permission.public.paths). The frontend page path comes from CertificateService.verificationPageUrl; the page itself was not opened for this document.