Enforcement, programmable
Let the right credentials open the right doors.
TrustGate validates Verifiable Credentials at physical entry points. Visitors scan a QR at the door, present a credential to the broker, and the door unlocks — or doesn't, with a reason logged. No credential storage on the device, no PII at the edge.
What TrustGate does
TrustGate is a physical access control gateway. Operators configure a hierarchy of Sites (buildings), Zones (areas with a credential requirement), and Doors (physical entry points). A visitor scans a QR at the door; their wallet presents a credential to the broker; TrustGate looks up the zone's requirements, optionally calls the Policy Engine, grants or denies entry, and writes an audit entry. The door device never holds credentials.
Flow
How an entry flows
- Step 1
products.trustGate.flow.s1
- Step 2
Visitor scans the QR; wallet presents matching credentials to the broker.
- Step 3
Broker verifies the credential and webhooks TrustGate with verified_claims.
- Step 4
TrustGate optionally calls the Policy Engine against the claims and zone's rule.
- Step 5
TrustGate logs the decision and signals the physical lock via webhook relay.
Standards
Standards at the edge
OID4VP
Presentation protocol inherited from the broker; TrustGate sees only verified claims.
QR (ISO/IEC 18004)
Session URL encoded as a QR for the door screen; no mobile app required.
Webhook relay
Integration point for physical hardware — door controllers, turnstiles, barriers.
Append-only audit log
Every attempt recorded with door, zone, site, decision, reason, timestamp.
Compliance
Privacy at the door
TrustGate is designed for the door device: low trust, no persistent credentials, no PII at the edge. The audit log lives in the backend; the door itself only renders a QR and calls a webhook.
- No credential storage — the broker holds the verification, TrustGate sees only verified claims
- Policy-per-zone — each zone ties to a Policy Engine rule that evaluates the claims
- Append-only audit log — every attempt (allowed or denied) is recorded with reason
- Configurable fail-open or fail-closed when the Policy Engine is unreachable
Integration
Configure sites, mount doors, forget the credentials
Create a Site via the admin API, add Zones (optionally tied to a Policy Engine rule), add Doors. Mount a small screen at each door running a tiny HTML page that fetches a fresh QR every 30 seconds. TrustGate does the rest — you only see the audit log.
- Admin API for Sites, Zones, Doors, and rule bindings
- Webhook out to physical hardware — integrates with any controller that speaks HTTP
- Append-only PostgreSQL audit log — you own retention and GDPR compliance
FAQ
Frequently asked
- What if someone guesses a door ID?
- They can create a credential presentation session, but they cannot unlock anything unless they have a valid credential that passes the zone's policy. The door ID is not the secret — the credential validation is. For defence in depth, restrict network access to the door session endpoint so only your door devices can reach it.
- Can I use TrustGate without a Policy Engine?
- Yes. Leave POLICY_ENGINE_URL blank. TrustGate will still validate credentials with the broker and log every entry, but it won't evaluate a policy — any valid credential-holder will be allowed. Useful for simple presence-verification scenarios.
- Where are the entry logs?
- In the PostgreSQL access_log table. Append-only — never modified by the application. You are responsible for retention (GDPR, legal compliance). Set up a scheduled job to delete old entries or archive them to cold storage.
Ready to gate doors with credentials?
Request access to mount TrustGate at your first zone.