Identity verification and staff onboarding

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.

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 can present trusted identity evidence from an authoritative issuer during onboarding, allowing the employer to verify identity with less friction and better auditability. Additional checks may still occur, but the core identity proof does not need to be re-created from scratch for every onboarding process.

Ecosystem roles

• Issuer: An authorised identity provider or government-recognised credential issuer that issues verified identity credentials to the person.
• Holder: The person joining the organisation, 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.

Assurance and lifecycle

This pattern only works if lifecycle is explicit. Identity proofing, expiry, revocation, and policy evaluation all need to be handled deliberately.

• 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.

flowchart LR
    IDP@{icon: "fa:id-card", label: "Identity issuer", pos: "b"} -->|Issues identity VC| CAND
    subgraph PERSON["Candidate / new starter"]
        direction TB
        CAND@{icon: "fa:user", label: "Person", pos: "b"}
        WAL@{icon: "fa:wallet", label: "Wallet", pos: "b"}
        CAND -->|Holds credential in| WAL
    end
    CAND -->|Presents identity credential| VER@{icon: "fa:user-check", label: "Onboarding verifier", pos: "b"}
    REG@{icon: "fa:book", label: "Trust registry", pos: "b"} -->|Publishes trust metadata| VER
    VER -->|Confirms issuer trust and credential status| EMP@{icon: "fa: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