The journey
Six builds: BHI's identity and its ecosystem, the employer, the job board, the candidate's wallet, the application itself, and what happens to the impostors.
Six builds: BHI's identity and its ecosystem, the employer, the job board, the candidate's wallet, the application itself, and what happens to the impostors. Each step follows the playground template: narrative, trust-graph diagram, Reproduce it, Under the hood.
BHI's identity, and its ecosystem
anchor + Recruitment Trust NetworkBefore governing trust for a sector, BHI proves itself.
BHI becomes verifiable and creates the Recruitment Trust Network
BHI deploys its Business Wallet: a vs-agent on a BHI domain. A DID is generated, the identifier everything else attaches to. It proves nothing yet; it is the empty identity card. BHI then joins the Verana ECS Ecosystem and completes a Know-Your-Business exchange over DIDComm with Orchestrating Identity. Because Orchestrating Identity is a provider certified under the UK DVS trust framework, the Verana Council has accredited it as a qualified ISSUER of the ECS-Organization credential: it does not merely run the onboarding, it verifies the organisation, confirms DVS register status, and issues the credential itself. Finally BHI publishes its governance framework (the sector standard the Standards workstream is already producing, rendered as an Ecosystem Governance Framework) and creates its registry with the two schemas from Chapter 2.
- DVS certification is the accreditation criterion: any provider certified under the UK DVS trust framework can be accredited by the Verana Council the same way and issue ECS-Organization credentials. The route is not the point, the credential is; build 3 shows a participant taking a different one.
- New in this step: BHI's DID is born, the check turns green, and the Recruitment Trust Network exists.
Click a participant to see the credentials it presents.
Reproduce it
- 1Deploy a vs-agent on a public domain (Docker image and compose examples in the vs-agent repository).
- 2Open https://<your-host>/.well-known/did.json - that document is your Business Wallet's DID.
- 3Resolve it: https://resolver.testnet.verana.network/v1/trust/resolve?did=<your-did> returns UNTRUSTED. That is the starting line.
- 4In the Verana app: Discover & Join → ECS Ecosystem → Organization schema → Participants → join under an active issuer branch. Complete the KYB exchange over DIDComm.
- 5My Ecosystems → create an ecosystem (name plus governance-framework document) → add credential schemas → create root Participant entries.
Under the hood
- The vs-agent generates the DID (did:webvh recommended) and publishes its DID Document with a DIDComm endpoint.
- Orchestrating Identity holds an ISSUER Participant entry on the ECS-Organization schema, granted under the ECS Ecosystem governed by the Verana Council; its UK DVS certification is the accreditation criterion. Joining creates a HOLDER Participant entry on the same schema; the validating issuer sets it to VALIDATED and it becomes ACTIVE in the public tree.
- Ecosystem creation is three transactions: Create New Ecosystem (with the EGF document) → Create New Credential Schema → Create Root Participant.
Meridian Technologies becomes a verifiable employer
ECS-Org + ECS-Service + Verified EmployerThe employer walks the same path BHI just walked, then joins the sector's network.
Anchor, KYB, service identity, and the Verified Employer credential
Meridian Technologies (demo) deploys its anchor, completes KYB, and receives its ECS-Organization credential. It then self-accredits as an ECS-Service issuer and issues an ECS-Service credential to its careers and ATS service. Finally it applies to the Recruitment Trust Network as a holder of Verified Employer: the validating provider identifies Meridian by the ECS-Organization credential already on its DID. Reusable KYB, no fresh paperwork. That is what stands behind the “Apply with Verifiable Credentials” flag on the listing: not a marketing claim, a resolvable credential chain.
Click a participant to see the credentials it presents.
Reproduce it
- 1Repeat build 1, steps 1-4, for the employer's Business Wallet.
- 2ECS Ecosystem → Service schema → Participants → join on the issuer side; self-issue the ECS-Service credential via the vs-agent Admin API and link it.
- 3Recruitment Trust Network → Verified Employer schema → Participants → Join. Present ECS-Organization when asked to identify.
Under the hood
- Self-issuance of ECS-Service is valid because the same DID already presents a proven ECS-Organization: every service traces back to an accountable organisation.
- Meridian joins as HOLDER under a grantor branch; validation is an ECS-Organization presentation check, not a document review.
JobSearch becomes a recognised verifier, and picks its own provider
VERIFIER + two grantorsThe job board is the party that actually asks the candidate for credentials. This build also shows the network is open.
Verifier entries under a second grantor
JobSearch (demo) needs two things: its own verifiable identity (ECS-Organization plus ECS-Service), and a VERIFIER Participant entry on each candidate credential schema it intends to request. As an ARTP member it also holds a Recognised RecTech Provider credential. And here is the step that shows the network is open: JobSearch does not use Orchestrating Identity. It already has a commercial relationship with Trustworthy Verification Services (demo), another certified DVS provider. So Trustworthy Verification Services is established as a verifier grantor in the network, and JobSearch is onboarded by them instead. Same schemas, same rules, same verdict in the candidate's wallet: nothing about the trust the candidate sees depends on which provider did the onboarding.
- When the candidate scans the QR code, the wallet does not see “a website”. It sees a DID presenting ECS-Service, controlled by an organisation presenting ECS-Organization and Recognised RecTech Provider, holding verifier entries for exactly the credentials it is asking for.
- Its verifier policy accepts Qualification credentials from issuers accredited on the Qualification schema, and right-to-work and Employment credentials from certified DVS issuers.
Click a participant to see the credentials it presents.
Reproduce it
- 1Deploy a vs-agent for the credential-request service; issue it an ECS-Service credential from the organisation anchor and link it.
- 2Join each candidate credential schema tree as VERIFIER for that service's DID, under whichever grantor you have chosen.
- 3Generate a DIDComm out-of-band invitation as a QR code; the wallet resolves the inviting DID before showing the request.
Under the hood
- The QR code carries a DIDComm out-of-band invitation, not a URL to a form. Nothing is submitted to a web endpoint.
- The Personal Wallet applies the mirror rule before presenting: verify the verifier is trusted, and authorised to request these schemas.
- This is the step that kills the fake job ad. See build 6.
The candidate's wallet
three schema families, one walletAlex's credentials arrive from three different issuers, over DIDComm, and sit in one wallet: qualifications, employments, and right to work.
Qualifications, employments and right to work, none issued by BHI
The BSc and the professional cloud certification are both Qualification credentials: one from Caledonian University (demo), one from Cirrus Certification (demo). Qualifications repeat naturally, one credential per award, from any number of institutions. The Employment credentials (one per employment relationship, including any current ones) and the single right-to-work credential come from Northbank Identity (demo), a certified DVS provider. Every one of these is issued by somebody else: BHI issues none of them, and that is the point. The Recruitment Trust Network governs the hiring side and consumes the rest. Each credential is issued to Alex's DID, held by Alex, revocable by its issuer, and, critically, not held by any employer.
- Where the employment credential actually comes from: this is the one credential in the demonstration with a real statutory route behind it. The Data (Use and Access) Act 2025 created an information gateway through which a certified DVS provider can request data from HMRC on behalf of a citizen. HMRC already holds the payroll history that establishes where someone has worked and when.
- So the issuer is the DVS provider, and HMRC is the data source. That distinction matters: HMRC has not agreed to become a credential issuer and is not being represented as one. What the demonstration shows is a credential built on a data route that already exists in law, which is why this part of the model requires a request to HMRC rather than a change to it.
Click a participant to see the credentials it presents.
Under the hood
- Issuance runs over DIDComm; the Personal Wallet verifies the issuer is trusted and authorised to issue that schema before accepting.
- Revocation is issuer-side and visible at verification time: a suspended certification or a withdrawn right-to-work status shows up on the next presentation, not at the next audit.
The draft claim sets
draft, for reviewThe proposed claims of the three schema families, for review. Field names and formats are finalised when BHI defines each schema (a definition template is in preparation) and the schemas are created on the testnet.
Qualification
Issued by the awarding body: Caledonian University (demo) for the degree, Cirrus Certification (demo) for the professional certification
- Issuing educational establishment
- Date awarded
- Qualification subject
- Qualification type (e.g. BSc, PhD)
- Grade awarded
One credential per qualification, degrees and professional certifications alike: many Qualification credentials co-exist in the wallet, each issued by its own institution.
Employment
Issued by Northbank Identity (demo), from HMRC payroll records
- Employer
- Start date
- End dateoptional
One credential per employment relationship; the five-year history is the set of these in the wallet, repeating until the record reaches back five years. End date is absent for a current employment, and one or more current employments can co-exist.
Right to Work
Issued by Northbank Identity (demo), certified DVS issuer
- First name
- Surname
- Date of birth
- Photograph
- Nationality
- Date right to work was established
- Right-to-work expiry dateoptional
Exactly one credential per person.
Modelling note: a verifiable credential carries a flat claim set, so lists repeat as credentials, not as fields inside one credential. Each employment and each qualification is issued as its own credential, and the wallet accumulates them: employments until the record reaches back five years (with one or more current employments), qualifications from any number of institutions. Right to work is a single credential. An employment-reference schema was considered and dropped as redundant.
The application
9:41 to 9:44The wireframe flow, end to end: search, scan, review, select, approve, submit.
From search to submitted, in one sitting
The board filters listings to employers presenting a Verified Employer credential, and the job detail page declares up front which credentials will be requested: the schemas the verifier holds VERIFIER entries for. Alex scans the QR: a DIDComm out-of-band invitation, and the wallet resolves the requesting DID. Then the step the wireframes did not have: the Proof-of-Trust card. Who is asking, what credentials they present, who certified them, shown before anything is shared. Alex selects credentials (selective disclosure: per credential, and per attribute), unlocks the wallet, and the presentation travels over DIDComm. The verifier checks signature, revocation status, and the issuer's registry entry. Confirmed: 4 of 4 verified, reference number, and the activity log is the audit trail.
- Elapsed time in the wireframe: 9:41 to 9:44. Elapsed time today: two to six weeks.
Click a participant to see the credentials it presents.
Under the hood
- Verification is three checks per credential: the signature is valid, the credential is not revoked, and the issuer holds an active ISSUER Participant entry on that schema in the registry. The third check is the one with no equivalent today.
- The employer receives a cryptographically signed proof, not a document set. There is nothing to store and nothing to leak.
The impostors
refusals, with proofThree failures, each failing at a different link of the chain.
The fake job ad, the uncertified provider, the forged degree
Halcyon Talent (demo) can build a convincing careers site, copy Meridian's branding, and put up a QR code. What it cannot do is present a Verified Employer credential, because only the Recruitment Trust Network issues one and it never recognised Halcyon. The candidate's wallet refuses before any data moves: the scam fails at the point where scams currently succeed, the moment of asking. Worth stating plainly: Halcyon may itself be a perfectly verifiable organisation, with valid ECS-Organization and ECS-Service credentials, like Umbra Repairs in the Vesta story. Verifiable is not the same as authorised. Legitimate organisation, wrong network.
- Northgate Screening (demo) holds ECS-Organization but not Recognised RecTech Provider, and is not on the DVS register. An employer evaluating providers can establish this in one resolution instead of one procurement cycle.
- The forged degree: a credential claiming a First Class BSc, signed by a DID with no ISSUER Participant entry on the Qualification schema. It verifies as a signature and fails as a credential. That distinction is the whole point.
Click a participant to see the credentials it presents.
Six builds, and the wireframe's line stands: your credentials remain in your wallet. The employer receives a cryptographically signed proof, not a document set. There is nothing to store and nothing to leak.