Get a verifiable credential from the hosted lab

View as Markdown

In the hosted lab, Registry Notary issues a signed verifiable credential to a hosted demo wallet that answers a question without exposing the underlying record. This is a guided browser flow, not a curl sequence: a real OID4VCI issuance needs a holder key and a sign-in, which is wallet territory. You do not need to install a wallet: the lab hosts a demo wallet at wallet.lab.registrystack.org, so you can receive the credential end to end in the browser. Everything runs in the hosted lab at lab.registrystack.org, so this page has no setup on your machine.

Outcome: One signed, privacy-preserving verifiable credential issued by Registry Notary to a hosted demo wallet, against the public hosted lab.
Time: About 5 minutes
Level: Hosted lab, zero install
Prerequisites: A web browser

This lab uses synthetic data and public demo-only credentials by design. Do not reuse anything you copy here outside the lab.

What is running

The lab runs a citizen Notary you will use in this tutorial: an issuer that hands out a privacy-preserving credential instead of the raw record, at citizen-notary.lab.registrystack.org. The lab also runs a health-program Notary in front of a demo DHIS2 health information system, used only by the DHIS2 integration tutorial, at dhis2-notary.lab.registrystack.org. For how these connect to the rest of the stack, see the architecture overview. For the full set of live demo credentials, identities, and ready-made requests, open the lab homepage at lab.registrystack.org.

Get a signed credential

The citizen Notary issues a Selective Disclosure JWT Verifiable Credential (SD-JWT VC) of type person_is_alive_sd_jwt, media type application/dc+sd-jwt. The credential discloses a single predicate, whether the person is alive, as a true or false claim. It never hands over the underlying civil record. The quickstart Relay row-read example uses NID-1001 / Miguel Santos, while this wallet flow uses the lab wallet identity NID-2001 / Maria Santos.

Start in the Wallet test section of lab.registrystack.org, which links the credential flow end to end: start the citizen Notary flow, sign in, then paste the generated credential offer into the hosted wallet. The Notary requires you to sign in before it issues. The sign-in runs through eSignet, the lab’s hosted demo identity provider; you do not need an account, and the following values are synthetic demo identities:

National ID: NID-2001
Name: Maria Santos
Login and OTP code: 111111
PIN: 545411

After sign-in, the hosted wallet receives the signed person_is_alive_sd_jwt credential, with the alive predicate set to true. If you prefer your own OID4VCI-compatible wallet, you can open the credential offer directly instead:

https://citizen-notary.lab.registrystack.org/oid4vci/credential-offer?credential_configuration_id=person_is_alive_sd_jwt

See the issuer refuse

Try this in the same browser flow. Self-attestation binds the credential subject to the identity you signed in as. If you sign in as NID-2001 but ask for a credential bound to NID-1001, the Notary refuses: it will not issue a credential for a subject you did not authenticate as. The issuer cannot be talked into vouching for someone else. For more on this service, see Registry Notary.

DHIS2 integration path

The lab also runs a DHIS2-backed Notary for API credential and claim-evaluation work. Because that path is about integrating an existing source system, use Integration patterns for the source-adapter model.

What you built

You watched Registry Notary issue a signed, privacy-preserving Selective Disclosure JWT Verifiable Credential to a hosted demo wallet: the credential discloses a single true or false predicate, whether the person is alive, without exposing the underlying civil record. Self-attestation held: signing in as NID-2001 and asking for a credential bound to NID-1001 was refused, because the issuer will not vouch for a subject you did not authenticate as.

Evaluate a claim with Registry Notary: run a Notary against the Relay you published and evaluate a claim.
Run a protected registry API locally: stand up your own protected Relay from a sample workbook.

Troubleshooting

Symptom	Cause	Fix
The hosted lab or a service URL does not respond	n/a	First run with Solmara Lab runs a separate, fully local multi-service demo if the hosted lab is unavailable
Sign-in refuses the documented demo identity (`relay_auth_subject_denied`)	The hosted deployment’s identity set has drifted from these instructions.	File a registry-stack issue; in the meantime, First run with Solmara Lab walks through an equivalent evidence flow entirely locally.