Skip to content
FFN Pass Open your pass

For sites and developers

Ask for an answer, not a document.

Verify with FFN gives your site a signed yes or no for exactly the claims you need, with the source, method and date behind each one. No ID images to store, secure or delete.

SiteVerificationRecord
{
  "provider": "ffn",
  "subjectId": "per-site id for this person",
  "claims": [
    { "name": "identity.ageOver21",
      "label": "Over 21", "value": true,
      "issuerName": "FFN",
      "evidence": { "method": "vendor-document",
        "assurance": "substantial", "checkedAt": "…" } }
  ],
  "notChecked": ["address"],
  "verifiedAt": "…"
}

Why sites use it

Less to hold, more to go on

Claims, not uploads

You get facts and a few fields, never ID images. Nothing sensitive to breach.

Evidence you can weigh

Each claim says how it was checked, by which source, when, and at what assurance. Set the lowest assurance you accept.

Never blocked by FFN

You keep your own verification record. If FFN is unreachable, you carry on with what you stored and when it was checked.

What you can ask for

A small, typed catalog of claims

Mark a claim optional and the person can choose whether to share it. The SDK refuses to request a claim no listed issuer can provide.

Credential Claims Issued by
FFN Identity personVerified, ageOver18, ageOver21, birthDate, legalName, holdsValidLicense with issuingState FFN, after an ID check
FFN Link Account type (email, phone, GitHub, Google, LinkedIn), handle, account age when the provider shares it, and whether the name matches the verified name FFN, after a code or sign-in
Site attestation videoCallCompleted, referencesChecked, tripCompleted Your site, under its own name
Travel vouch Tags and an optional note, carrying the voucher's own signature Your site

Get started

One config on your server

The Door SDK wires the Verify with FFN button's server side, your own attestations, re-checks and reissue after recovery from one config. Your accounts and data model stay yours.

  1. Get listed. FFN adds your site to its signed trust registry with your name, domain and response address.
  2. Add the SDK and mount its handler on one server route.
  3. Add the button to your page. On a phone it opens the wallet; on a computer it shows a QR code.
  4. Save the record you get back, and re-check it when it matters.

In this first version the FFN team adds sites to the registry, and the SDK is shared as a vendored package. Self-serve onboarding comes later.

Talk to the FoFo Network team
ffn.ts
import { createSite, networkFromEnv } from '@fofonet/door-site';

const site = createSite({
  origin: 'https://example.com',
  network: networkFromEnv(process.env),
  store, // e.g. FirestoreKvStore
  claims: [
    'identity.personVerified',
    'identity.ageOver21',
    'identity.legalName',
    'videoCallCompleted?', // optional
  ],
  purpose: 'Check members before the trip',
  display: { name: 'Example Co' },
});

// site.handler serves the button's API,
// site.attest() issues your own credentials,
// site.recheck() checks status before you rely on it.

What happens

From button to verified, in four steps

  1. You ask

    Your server builds an OpenID4VP request: the claims you want, which are required, and a fresh nonce.

  2. They consent

    The person unlocks their pass, sees your verified name and purpose, and chooses what to share.

  3. The pass presents

    An SD-JWT presentation with only the chosen claims, bound to your request by a key-binding signature.

  4. You verify

    Issuer signature, the trust registry, expiry, the status list and key binding. Then you keep the record.

Issue your own

Your site can be an issuer too

Some facts only you know: the video call happened, references were checked, the trip was completed. Issue them as your own credentials, signed with your own key under your own did:web.

  • Your key stays in your own key service. FFN never holds it.
  • The registry scopes what you may issue, so a verifier rejects anything outside it.
  • The person adds your credential with one tap, and it always shows your name as issuer.
  • You publish your own status list and can revoke what you issued in error.

Standards

Open standards in your path

Any OpenID4VP and SD-JWT VC library that trusts FFN's registry key can verify an FFN credential, with or without our SDK.

OpenID4VP + DCQL

How your site asks, and how the pass answers.

SD-JWT VC

Credentials with each claim disclosed separately, plus key binding.

OpenID4VCI

How credentials, including yours, reach the pass.

Token Status List

One static file per issuer, so revocation checks are cheap and private.

did:web

Issuers publish their keys on their own domains.

WebAuthn passkeys

The holder's vault is unlocked by a passkey, with PRF where available.

Pricing

One price per check

$0.99 per FFN Pass check

For outside sites asking a person to share verified claims.

  • Any claim in the catalog: verified person, over 18 or 21, linked accounts
  • A signed answer with its evidence, over OpenID4VP and SD-JWT VC

Verify people without holding their documents

FFN Pass launches with FoFo Adventures. Your site can be next.