Menu

VC use case

Borrowing an asset

Provide kioskless access to student borrowing assets such as library books.

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

Overview

Students can borrow physical or digital assets by presenting a Student ID Verifiable Credential at the point of checkout. The verifier confirms that the student is current, eligible, and linked to the institution before recording the loan.

The same pattern can apply to library books, laptops, lab equipment, lockers, specialist facilities, or any asset where the borrowing decision depends on student identity and eligibility.

Why it matters

Traditional borrowing often depends on physical cards, staffed desks, kiosks, or manual account lookups. Those steps add friction for students and make it harder for institutions to support unattended or distributed asset access.

Verifiable Credentials create a cleaner model:

  • the student proves enrollment or eligibility from their wallet
  • the verifier checks issuer trust and credential status at checkout
  • the asset system records the loan without needing to store unnecessary identity evidence
  • the institution can apply policy consistently across different asset types and locations

This is not just a library workflow. It is a reusable pattern for trusted student access to institution-managed resources.

Ecosystem roles

  • Issuer: The education institution issuing student identity, enrollment, or eligibility credentials.
  • Holder: The student storing credentials in a wallet and approving presentation at checkout.
  • Verifier: The library, asset kiosk, facility system, or asset management service validating the credential.
  • Asset system: The system of record for the borrowed item, loan period, return status, and exceptions.
  • Trust governance: The rules that define accepted credentials, status checks, borrowing policy, and fallback handling.

Trust decision

The verifier decision is narrow: can this student borrow this asset now?

That decision may depend on:

  • current enrollment status
  • student identifier or library identifier
  • borrowing privileges or holds
  • asset category and borrowing rules
  • credential status, expiry, and issuer trust

The credential should prove enough to make the borrowing decision without turning the checkout point into a broad student-record lookup.

Privacy and assurance

The verifier should request only the claims needed for the transaction. For example, a library checkout may need proof of current student status and a stable student identifier, but not date of birth, address, or unrelated enrollment details.

Assurance depends on the verifier checking issuer trust, credential status, and policy fit before recording the loan. The asset system should retain the transaction record it needs, not a full copy of the presented credential.

Implementation notes

QR codes, NFC prompts, self-service kiosks, or staff-assisted checkout can initiate presentation. The same verifier pattern can be reused across channels as long as the asset system receives a trusted result and a transaction reference.

Implementation should define fallback paths for forgotten devices, expired credentials, suspended enrollment, blocked borrowing privileges, and offline operation if the checkout point cannot reach a status service.

Objective
Enable a student to borrow an institution-managed asset using a verifiable student credential.
Description
The student presents a Student ID or eligibility credential; the verifier checks trust and status, then records the loan in the asset system.
Actors
Student; education institution; library or asset verifier; asset management system.
Dependencies
Accepted student credential schema, issuer trust registry, status endpoint, checkout channel, and asset system integration.
Preconditions
The student holds a current credential and is eligible to borrow the requested asset.
Postconditions
The asset is loaned, declined, or sent to exception handling based on verified identity, eligibility, and policy.
flowchart LR
    STU@{icon: "tabler:school", label: "Student", pos: "b"} -->|Presents student ID VC| VER@{icon: "tabler:book", label: "Library / verifier", pos: "b"}
    VER -->|Verify issuer, status| REG@{icon: "tabler:building-bank", label: "Institution registry", pos: "b"}
    VER -->|Record loan| SYS@{icon: "tabler:database", label: "Library system", pos: "b"}
sequenceDiagram
    participant Student
    participant Wallet
    participant Verifier as Library / verifier
    participant Registry as Institution registry
    participant LibrarySystem as Library system

    Student->>Wallet: Approve presentation
    Wallet->>Verifier: Present student ID VC
    Verifier->>Registry: Check issuer and status
    Registry-->>Verifier: Valid
    Verifier->>LibrarySystem: Record loan
    LibrarySystem-->>Student: Loan confirmed

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 Centre.
Your message could not be sent. Try again later.