Capability status

What is real today

Designed for a future Midnight proof adapter. Current V1 runs locally in your browser.

Implemented in V1

· Local, deterministic inspection of a plain-English data request.
· User-controlled minimisation: add, remove, and mark which categories are actually necessary.
· The Margin: an explicit pause showing approved and withheld field names before you choose what to share.
· A minimum-disclosure response prepared locally — field names only — copyable and downloadable.
· No field is ever preselected: the minimum selection starts empty and only the user decides what is necessary.
· A metadata-only privacy receipt for both approve and decline, with a Web Crypto SHA-256 integrity fingerprint.
· JSON and PDF receipt export, plus browser-local receipt verification.
· Lens Direct (controlled beta): a guided, sign-in-free walkthrough of one request on synthetic demo data, with Safe Stop, exact resume, and a demo-only receipt. No real service, clinic, department, bank, payment, identity provider, or chain is connected, and a Lens Direct result has no real-world effect.

· No direct transmission to requesters: Midnight Lens never sends your prepared response anywhere.
· No requester or business integration in V1.
· No Midnight wallet connection.
· No Compact contract, zero-knowledge proof generation, or on-chain verification.
· No Midnight City integration. If Midnight City is mentioned anywhere, treat it as an unconfirmed future showcase possibility, never a dependency.
· No monitoring of your device, browser, or network. Scope is only the request you enter here.

· Real server-side session engine on this project's own backend: crypto-random nonce, state and JTI, expected-origin binding, five-minute expiry, and one-time terminal state.
· Signed OpenID4VP 1.0 request (openid4vp-v1-signed) for the Google Wallet sandbox, requesting only org.iso.18013.5.1/age_over_18 with intent_to_retain:false.
· Per-session P-256 response-encryption keypair generated server-side; only the public JWK is sent out, the private JWK stays in the backend vault and is scrubbed on every terminal state.
· Server-side ISO mdoc verification: issuer authentication, device authentication and digest integrity must each report a passed check against pinned sandbox issuing-authority trust roots, or the session fails.
· Verified is written only after those cryptographic checks pass and age_over_18 is exactly true. Nothing in the browser can produce a verified state.
· Stored data is metadata only: session state, normalized result, a SHA-256 digest of the wallet response, receipt metadata and scrubbed audit events. Never a birth date, address, licence number, photo, ID image, raw wallet response or decrypted vp_token.
· Minimal hosted bridge surface: POST /api/public/verifier/sessions creates a session, /verify-age?session=... hosts the flow, GET /api/public/verifier/result returns the normalized result only.

· Sandbox only. Google's published sandbox reader material and sandbox trust roots are used; production issuer onboarding is required before anyone relies on a result.
· The check depends on the browser's W3C Digital Credentials API and a wallet holding a sandbox mobile driving licence. Where that is unavailable the flow reports UNSUPPORTED or NO_CREDENTIAL and never shows a verified state.
· Zero-knowledge age proof (Longfellow mso_mdoc_zk) is requested nowhere yet: verification is baseline non-ZK mdoc.
· No Midnight proof, anchor, Compact contract or on-chain verification is wired: the Midnight anchor on every verifier receipt is empty.
· No Shopify, WordPress or JavaScript Bridge plugin exists yet — only the hosted flow and the two endpoints above.

· It is an unkeyed SHA-256 digest stored inside the same JSON receipt.
· MATCH means only that the stored fingerprint equals a fresh digest of the canonical metadata — the file is internally consistent.
· Anyone able to edit the metadata can also recompute the fingerprint and produce another MATCH.
· So it does not prove originality, history, authorship, identity, issuer, authority, recipient acceptance, time of existence, or tamper resistance, and it is not a zero-knowledge proof, Midnight proof, or on-chain verification.
· CHANGED means the stored fingerprint no longer matches the current metadata. INVALID means the file fails the supported receipt structure and format checks.