Menu

VC use case

Identity verification and staff onboarding

Use Verifiable Credentials to support trusted staff onboarding, reusable workforce attributes, and cleaner access decisions.

  • Government
  • Enterprise
Issuer authoritative source creates the claim
Holder person or organization presents proof
Verifier service checks status and makes a decision

Overview

Organisations can use Verifiable Credentials to let a person prove who they are during staff onboarding using trusted digital identity evidence, rather than repeating manual document checks across disconnected onboarding steps.

The employer can make identity proof a reusable onboarding input instead of a one-off document collection exercise.

Why it matters

Staff onboarding is often fragmented across HR, identity, compliance, and access teams. The same person may be verified multiple times, the same attributes may be re-entered into multiple systems, and access decisions may depend on manual evidence gathering.

Verifiable Credentials offer a cleaner pattern:

  • a candidate or new starter presents trusted identity evidence from an authoritative issuer
  • the employer verifies issuer trust, credential status, and policy fit
  • downstream onboarding steps can rely on a verified identity result
  • additional workforce checks can be layered without re-creating core identity proof from scratch

Additional checks may still occur, but the core identity proof does not need to be repeated across every onboarding process.

Ecosystem roles

  • Issuer: An authorized identity provider or government-recognized credential issuer that issues verified identity credentials to the person.
  • Holder: The person joining the organization, holding their credential in a wallet.
  • Verifier: The employer’s onboarding service, identity team, or relying application evaluating the presented identity evidence.
  • Trust governance: The trust framework, registry, or accreditation model that defines which issuers and credential types can be relied upon.

Trust decision

The verifier decision is narrow: has this person provided identity evidence trusted enough to progress this onboarding step?

That decision may depend on issuer trust, identity assurance level, credential status, role risk, jurisdiction, and whether extra checks are required.

Privacy and assurance

The verifier should request only the identity claims needed for onboarding. Some roles may require higher assurance or additional compliance checks, but a standard onboarding flow should avoid collecting broad identity documents when a verified result is sufficient.

Assurance and lifecycle need to be explicit:

  • Identity credentials should be issued at an assurance level appropriate to the role and risk.
  • Verifiers should confirm issuer trust, credential status, and policy fit before progressing onboarding.
  • Identity proof does not remove the need for HR, police-check, clearance, or compliance processes, but it reduces repeated document-handling and manual re-identification.
  • Once identity is established, later workforce attributes and access rights can still be managed through the employer’s usual systems.

Implementation notes

  • Define accepted identity issuers and assurance levels by role or onboarding pathway.
  • Keep the verified identity result available to HR, identity, and access workflows without copying full credential payloads everywhere.
  • Separate core identity proof from later role, employment, clearance, and access credentials.
  • Include fallback and exception handling for unsupported wallets, failed checks, and manual compliance review.
Objective
Reduce onboarding friction while preserving trust, auditability, and policy control.
Description
Use Verifiable Credentials so a person can prove identity during onboarding without repeated manual document checks.
Actors
Employer; candidate or new starter; identity issuer; onboarding service.
Dependencies
Trust framework rules, issuer trust signals, accepted assurance levels, and onboarding or compliance workflows that consume verified identity evidence.
Preconditions
The person holds a trusted identity credential issued by an accepted issuer.
Postconditions
The employer verifies identity and progresses onboarding based on verified evidence and policy.
flowchart LR
    IDP@{icon: "tabler:id", label: "Identity issuer", pos: "b"} -->|Issues identity VC| CAND
    subgraph PERSON["Candidate / new starter"]
        direction TB
        CAND@{icon: "tabler:user", label: "Person", pos: "b"}
        WAL@{icon: "tabler:wallet", label: "Wallet", pos: "b"}
        CAND -->|Holds credential in| WAL
    end
    CAND -->|Presents identity credential| VER@{icon: "tabler:user-check", label: "Onboarding verifier", pos: "b"}
    REG@{icon: "tabler:book", label: "Trust registry", pos: "b"} -->|Publishes trust metadata| VER
    VER -->|Confirms issuer trust and credential status| EMP@{icon: "tabler:building", label: "Employer onboarding", pos: "b"}
sequenceDiagram
    participant IdP as Identity issuer
    box Candidate context
    participant Person as Candidate / new starter
    participant Wallet as Person's wallet
    end
    participant Verifier as Onboarding verifier
    participant Registry as Trust registry
    participant Employer as Employer onboarding

    IdP-->>Wallet: Issue identity VC
    Person->>Wallet: Hold identity credential
    Person->>Verifier: Start onboarding and present credential
    Verifier->>Registry: Check issuer trust, scope, and status
    Registry-->>Verifier: Trusted / valid
    Verifier-->>Employer: Verified identity result
    Employer-->>Person: Onboarding can proceed

Talk to UNIFY

Explore how this use case could work in your trust ecosystem.

Share the scenario you are testing and we will help map the issuers, holders, verifiers, and policy decisions involved.
Looks good!
Please enter your name.
Looks good!
Please enter your company.
Looks good!
Please enter your e-mail address so we can contact you.
This form uses Google ReCaptcha to ensure interactions with our site are from legitimate users. Please accept the use of recommended storage before submitting the form. Find out more at the Privacy Center.
Your message could not be sent. Try again later.