> For the complete documentation index, see [llms.txt](https://docs.nfh.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nfh.global/product-documentation/products/vc-on-edge.md). # VC on Edge — prove anything Issue & verify Verifiable Credentials at the edge — powered by OpenCred. All transactions run on trust. > **Realises the NFH fabric** [**Credentialling Edge**](/product-documentation/products/vc-on-edge.md) **service. The engine is OpenCred — VC on Edge *****is***** OpenCred, deployed at the edge of an NFH fabric network.** All transactions run on trust. A buyer needs to know the seller is licensed. A patient needs to know the doctor is registered. A logistics partner needs to prove cold-chain compliance. Today, this trust is established through manual document uploads, periodic audits, and centralized registries that become bottlenecks and single points of failure. **Verifiable Credentials (VCs)** solve this at the protocol level. A VC is a digitally signed, tamper-proof claim — "this seller holds license #X," "this driver passed background check Y," "this product is organic-certified" — issued by a trusted authority, carried by the subject, and independently verifiable by anyone, instantly, without calling back to the issuer. No PDFs. No manual checks. No registry lookups. Just cryptographic proof that travels with the transaction. NFH fabric supports the issuance and verification of VCs at the edge — where Network Participants (NPs) and Network Facilitator Organizations (NFOs) actually operate. Each NP/NFO issues and verifies credentials locally within their own infrastructure, embedding trust directly into the flow of value. This capability is powered by **OpenCred** — an open-source credential infrastructure for issuing, signing, and verifying W3C Verifiable Credentials. OpenCred keeps all signing local (private keys never leave the issuer's environment), supports multiple key sources (software keys, hardware tokens, OS certificate stores), and ships as both a desktop app and a self-hosted Docker image — making it ideal for edge deployment within NFH fabric. #### Use Cases #### NFOs — Network-Level Credentials NFOs see aggregate activity across all participants, making them natural issuers for reputation and performance credentials. | Credential | Example | | --------------------- | --------------------------------------------------------------------------------------------------------------------- | | Top-rated seller | "Top Rated Seller Q1 2026" based on ratings aggregated across all consumer nodes — portable to any NFH fabric network | | Fulfillment rate | Logistics provider with 99.2% on-time delivery last quarter — verifiable, not self-reported | | Best buyer experience | consumer node recognized for highest satisfaction scores — provider nodes use this to prioritize catalog availability | | Volume milestones | "10,000 orders fulfilled" — verifiable growth signal for partners, investors, other networks | | Network compliance | NP has passed onboarding, protocol conformance, and is in good standing — reusable across networks | | Dispute track record | Low dispute rate, fast resolution times — a trust signal that's hard to fake | #### provider nodes — Provider & Operations Credentials provider nodes issue credentials grounded in actual transactional data from their providers. | Credential | Example | | ----------------------- | ------------------------------------------------------------------------------------------------------------ | | Seller performance | Restaurant: "Avg prep time 12 min, 4.7 stars across 3,200 orders" — portable, not locked to one app | | Driver track record | "2,400 rides, 4.9 rating, zero safety incidents" — driver carries this to any network | | Cold-chain compliance | Temperature logs within range across 500 deliveries — pharma/healthcare consumer nodes verify before routing | | Verified catalog claims | Organic certification, GI tags, allergen testing actually checked — not just the seller's word | #### consumer nodes — Demand-Side Credentials consumer nodes see buyer behavior, order patterns, and payment reliability. | Credential | Example | | ----------------- | ----------------------------------------------------------------------------------------------------- | | Verified buyer | KYC + payment history — provider nodes verify before accepting COD or credit orders | | Repeat customer | "100 orders placed, member since 2024" — sellers offer preferential terms based on verifiable history | | Provider feedback | "92% positive reviews across 1,800 transactions" — provider carries this as portable reputation | ### The Value VCs on edge change the trust model fundamentally: * **Cryptographic proof replaces paper trails** — a seller's license, a driver's background check, a product's organic certification become machine-verifiable claims that travel with the transaction itself. * **Trust is portable across networks** — a provider verified in one NFH fabric network carries that credential into another without re-onboarding. Trust compounds instead of resetting at every boundary. * **Fraud surface shrinks** — forged documents, impersonated providers, and fake certifications become detectable during the transactions. * **Compliance becomes continuous** — instead of point-in-time audits, credentials can carry expiry, revocation status, and scope — participants that fall out of compliance are flagged in real time. * **The network gets stronger as it grows** — every credential issued adds to a web of verifiable trust. Unlike centralized trust registries, this scales horizontally with the network itself. *** ## The engine: OpenCred **OpenCred** is the local-first platform that powers VC on Edge — issuing and verifying **W3C Verifiable Credentials**. It ships as a **Desktop Client** (Electron) for interactive use and a **Docker Image** (headless HTTP API + CLI) for cloud and CI/CD deployment. It is published by [NFH Trust Labs](https://github.com/nfh-trust-labs). {% hint style="info" %} **Issuer private keys never leave the issuer's environment.** All signing happens locally on the issuer's machine or inside the issuer-operated container. There is no `api.opencred.com` — you deploy into **your** infrastructure, you hold the key, and NFH never receives your credential data or your keys. This is what makes the trust model credible — see [Security model](/product-documentation/products/vc-on-edge/security.md). {% endhint %} {% hint style="warning" %} **🧪 Beta.** OpenCred is in early-access beta. Functionality is feature-complete and the protocols are stable; desktop installer polish is in progress (macOS shows a one-time approval prompt on first launch; Windows installers will follow). Support: [open an issue](https://github.com/nfh-trust-labs/opencred-releases/issues). {% endhint %} ### Get OpenCred | | Where | How | | --------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- | | **Desktop** (macOS / Linux) | [opencred-releases/releases](https://github.com/nfh-trust-labs/opencred-releases/releases) | Download the `.dmg` / `.AppImage` / `.deb` for your platform | | **Docker server** | `ghcr.io/nfh-trust-labs/opencred/opencred-server:latest` | `docker pull ghcr.io/nfh-trust-labs/opencred/opencred-server:latest` | Both are public — no authentication required. The source code is maintained privately at NFH Trust Labs; distributed binaries are public. {% embed url="" %} | | | | --------------------- | ---------------------------------------------------------------------------- | | **Site** | [opencred.global](https://opencred.global) | | **Org** | [github.com/nfh-trust-labs](https://github.com/nfh-trust-labs) | | **Releases & issues** | [opencred-releases](https://github.com/nfh-trust-labs/opencred-releases) | | **VC schemas** | [opencred-vc-schemas](https://github.com/nfh-trust-labs/opencred-vc-schemas) | ### Explore the docs
ConceptsVCs, the DID methods used, how trust flows, and how revocation works (via DeDi).Concepts: VCs, DIDs, trust chains, revocation
Desktop appInstall, onboarding wizard, key import, issuing your first credential.Desktop app
Docker image & APIdocker run/Compose, signing-key sources, HTTP API, CLI, Cloud HSM.Docker image & API
Verifying credentialsThe four verification surfaces and the common result shape.Verifying credentials
Security modelThe never-touch-issuer-keys guarantee and the seven invariants.Security model
### How it fits NFH fabric OpenCred is the edge-run reference software for the [Credentialling Edge](/product-documentation/products/vc-on-edge.md): the issuer holds the keys, the holder holds the credential, and the NFH fabric Registry ([REGISTR](/product-documentation/products/registr.md), built on [DeDi](https://docs.nfh.global/dedi)) carries the issuer/key surface and revocation status. Credential **contents never touch NFH fabric** — only status and issuer metadata are public. **Standards alignment:** W3C Verifiable Credentials (Data Model 2.0) · `did:key` / `did:jwk` / `did:web` · selective disclosure (SD-JWT, BBS+) · DeDi-backed revocation. ## The NFH fabric capability: Credentialling Edge VC on Edge realises the NFH fabric **Credentialling Edge** — Verifiable Credentials issued and verified at the edge, by participants, in their own infrastructure or wallets. NFH fabric carries the issuer metadata and status surface; the credential content stays with the holder. **What it gives you** * **Issuance** — sign claims about a subject (a person, business, agent, asset). * **Holder custody** — the recipient holds the credential. No central store. * **Selective disclosure** — prove what's needed; reveal nothing more. * **Revocation and status** — issuers can revoke; verifiers can check without contacting the issuer in real-time. * **Schema discovery** — find the right credential type by schema, via the Registry. **Where it sits** — the protocol NFH defines (the W3C VC profile for NFH fabric, status discovery via Registry) plus reference software NFH publishes (issuer, holder, and verifier libraries running at the edge). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.nfh.global/product-documentation/products/vc-on-edge.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.