Provica prüft die swiyu-Wallet Ihrer Nutzer und gibt Ihnen das Ergebnis so zurück, wie es zu Ihrer Anwendung passt: als OIDC-Login, als anonyme Ja/Nein-Prüfung oder als fertigen Altersnachweis für Ihren Shop. Zweckgebunden, datensparsam, in Ihrem Namen.
Für Portale, die ein Konto führen: Ihr Portal spricht nur Standard-OIDC, den Wallet-Teil übernimmt Provica.
Ein Standard-OIDC-Client (Authorization Code + PKCE). Kein proprietäres SDK, keine Wallet-Logik.
Provica erzeugt die Prüfanfrage und zeigt QR bzw. Deeplink für die swiyu-Wallet.
Die Wallet präsentiert nur die zweckgebundenen Attribute (SD-JWT VC über OID4VP).
Provica prüft, minimiert und liefert die Attribute als OIDC-ID-Token und Userinfo.
Ihr Portal bekommt pro Mandant ein eigenes, nicht korrelierbares sub. Für Portale mit Konten gibt es einen Wiederherstellungscode: Bekommt eine Person eine neue e-ID ausgestellt, wird das unbekannte Credential nie stillschweigend mit einem bestehenden Konto verknüpft — die Anmeldung pausiert, bis der Code vorliegt. Ein Namenswechsel führt weiterhin zu einem neuen sub; das Konten-Matching dafür bleibt bei Ihnen.
Wenn Sie kein Konto brauchen, sondern nur eine Antwort — «über 18?», «Schweizer Staatsangehörigkeit?». Kein OIDC-Redirect, kein Konto, kein dauerhafter Identifikator. Zwei Prüfungen derselben Person sind nicht miteinander verknüpfbar.
Ein POST auf /v1/checks mit Ihren Client-Credentials. Zurück kommen check_id, check_url und ein Ablaufzeitpunkt.
Provica hostet die Seite: QR-Code oder Same-Device-Deeplink, dazu Zwecktext und Regelliste im Klartext.
/check/:id/status meldet ausschliesslich pending, done oder failed — nie das Ergebnis selbst.
/v1/checks/:id liefert genau einmal ein signiertes JWT, gebunden an aud, nonce und exp. Ein zweiter Abruf scheitert.
// 1) Create the check — keep the nonce in the session const nonce = randomBytes(16).toString('base64url') const { checkId, checkUrl } = await provica.createCheck( [{ attribute: 'age_over_18', op: 'is_true' }], { nonce, redirectUri: 'https://shop.example.ch/zurueck' }, ) // 2) Send the user to checkUrl. On the way back: const { resultJwt } = await provica.getCheckResult(checkId) const { satisfied } = await provica.verifyCheckResult(resultJwt, { nonce })
Prüfbare Regeln: age_over_16, age_over_18 und age_over_65 (ist wahr) sowie nationality (ist gleich). Im Ergebnis-Token steht nur der von Ihnen angefragte Vergleichswert — der offengelegte Attributwert nie.
Zwei Grenzen, die Sie vor der Integration kennen sollten. Ein per QR gescannter Wallet-Zugriff beweist nicht, dass die Person vor dem Bildschirm dieselbe ist, die im Wallet zustimmt — nur ein Same-Device-Deeplink mindert das wirksam. Und weil eine Prüfung keiner betroffenen Person zuordenbar ist, können Sie dafür auch keine personenbezogene Auskunft erteilen: Das ist bei anonymer Verarbeitung so gewollt, muss aber zu Ihrem Anwendungsfall passen.
Der Age Gate ist ein von Provica gehosteter Dienst, der den Check-Client Ihres Shops für Sie verwahrt. Ihr Shop spricht nie mit dem Broker und hält kein client_secret — in WooCommerce nur einen API-Key, in Shopify gar nichts.
Altersanforderung je Produkt: keine, ab 16 oder ab 18. In WooCommerce zusätzlich pro Kategorie — ein Produkt ohne eigene Einstellung erbt dann die strengste. In Shopify steht dafür am Produkt das Feld «Altersfreigabe».
Liegt etwas Altersbeschränktes im Korb, erscheint neben «Zur Kasse» ein Button zum Altersnachweis.
Der Kunde landet auf der gehosteten Prüfseite — QR oder Same-Device-Deeplink — und kehrt mit einem gültigen Nachweis in den Shop zurück.
Ohne passenden, unverbrauchten Nachweis kommt die Bestellung nicht durch: WooCommerce blockt sie auf jedem Checkout-Weg, den es kennt. Shopify hält sie nach dem Kauf zurück und taggt sie.
Das Client-Secret liegt verschlüsselt beim Age Gate und wird dem Händler nie angezeigt. Kompromittiert jemand den Shop, bekommt er keinen Broker-Zugang.
Die Altersgrenze wird an jedem Durchsetzungspunkt neu berechnet — nie aus dem, was der Browser behauptet. In WooCommerce im klassischen Checkout, im Block-Checkout und in der Store API, damit auch im agentischen Checkout. In Shopify liest der Webhook zur Bestellung jede Position über die Admin-API nach — ein manipulierter Warenkorb ändert, wann gefragt wird, nicht das Ergebnis.
In WooCommerce wird der Nachweis weder bei der Validierung noch beim Anlegen der Bestellung eingelöst — eine abgelehnte Karte verbrennt den Altersnachweis Ihres Kunden nicht. In Shopify löst ihn die Bestellung ein, und am Nachweis steht, welche: Stellt Shopify denselben Aufruf erneut zu, hält das keine bereits geprüfte Bestellung zurück.
Zurück kommt ein Ja oder Nein zur Altersgrenze. Das Geburtsdatum verlässt die Wallet nicht — der Shop speichert es also auch nicht.
Ein Unterschied, den Sie vor der Wahl der Plattform kennen sollten. WooCommerce prüft, bevor die Bestellung entsteht — scheitert der Nachweis, gibt es nichts zu stornieren. Shopify bietet auf den hier unterstützten Plänen keinen solchen Haken: Die Bestellung existiert und ist unter Umständen schon bezahlt, bevor wir davon erfahren. Durchgesetzt wird sie deshalb als Fulfilment-Hold samt Tag, den Sie freigeben oder stornieren. Ohne Nachweis endet sie also in einer Stornierung, nicht in einer sauberen Ablehnung. Das ist eine Grenze der Plattform, keine Einstellung.
Stand heute: Der Age Gate ist gebaut, für WooCommerce end-to-end getestet und für Shopify auf einem Dev-Store erprobt — ausgerollt ist er noch nicht, buchen können Sie ihn also noch nicht. Tragen Sie sich auf die Warteliste ein, wenn Sie ihn brauchen; wir melden uns, sobald er steht.
Drei Integrationen, drei Aufgaben: Die eine schützt Inhalte, die zweite blockiert eine Bestellung, die dritte hält sie zurück.
Der swiyu-Verifier ist Open Source — der Betrieb ist es, der wehtut. Diese Stolpersteine haben wir gegen die swiyu-Beta bereits gelöst.
Dieselbe Zweckbindung, dieselbe Datenminimierung, dasselbe Protokoll — ob Login, Prüfung oder Age Gate.
Jeder Client hat eine Attribut-Policy und einen sichtbaren Zwecktext. Angefragt wird nur der Schnitt aus Scope und Policy.
Über DCQL wird exakt und nur das angefragt, was der Zweck erfordert — nie mehr.
Append-only Protokoll jeder Freigabe — mit Zweck-Snapshot, aber ohne Attributwerte.
Pro Mandant ein eigenes, nicht korrelierbares sub — Portale können Nutzer nicht übergreifend verknüpfen.
Self-Service von der Registrierung an: Clients, Attribut-Policies, Prüfanfragen, Prüfungen, Einwilligungen und Betroffene — in Ihrer eigenen Konsole.
client_secret oder private_key_jwt, Secrets AES-256-GCM at rest, rotierbar.
JWKS mit Rotation; retirte Schlüssel bleiben zur Verifikation. Keine ephemeren Keys in Produktion.
Zertifizierte OIDC-Provider-Library. Funktioniert mit jedem konformen OIDC-Client.
Endet die Session, schickt der Broker ein Logout-Token an die hinterlegte URL Ihres Clients — Sie erfahren es, ohne zu pollen.
Eine neu ausgestellte e-ID wird nie stillschweigend mit einem bestehenden Konto verknüpft. Die Anmeldung pausiert, bis der einmalige Wiederherstellungscode vorliegt.
Auskunft per Subjekt-Export, Löschung der Pseudonym-Zuordnung und ein mandantengebundener CSV-Export des Consent-Logs.
Mandanten, Clients und Policies sind von Anfang an getrennt, samt mandantengebundener Rollen in der Konsole.
Sicherheits-Invarianten, die im Code durchgesetzt werden, nicht nur im Marketing.
Attribute ausserhalb der Policy führen zu access_denied — bevor überhaupt eine Verifikationsanfrage entsteht.
sub = HMAC(Mandanten-Secret, Identität). Kein Tracking über Portalgrenzen hinweg.
Verifizierte Attribute liegen AES-256-GCM-verschlüsselt und werden nach Ablauf der Retention gelöscht.
Nur explizit akzeptierte Issuer-DIDs werden vertraut — Defense-in-Depth zur Verifier-Pflicht.
Das Consent-Log speichert Attribut-Namen und Zweck — nie die Attributwerte selbst.
Die Regelauswertung einer Check-Anfrage passiert nur im Speicher. Gespeichert wird das Ja/Nein — für Attributwerte existiert dort gar keine Spalte.
Die Verwaltungsschnittstelle des Verifiers ist ausschliesslich im internen Netz erreichbar, nie vom Internet aus.
Mit Default-Schlüsseln startet der Broker in Produktion gar nicht erst. Ephemere Signaturschlüssel sind dort ausgeschlossen.
Ein Prüfergebnis ohne gültigen nonce wird abgelehnt, nicht stillschweigend akzeptiert. Ein Token aus fremder Prüfung lässt sich so nicht einspielen.
Provica fordert die Antwort der Wallet grundsätzlich verschlüsselt an. Eine unverschlüsselte Vorlage kommt gar nicht zustande.
Discovery, Authorization Code + PKCE, ID-Token, Userinfo — genau wie erwartet. Und wenn Sie gar kein Login brauchen: zwei REST-Aufrufe.
// lib/provica.ts — no other auth library needed import { createProvicaAuth } from '@provica/sdk-next' export const { handlers, auth, signIn, signOut } = createProvicaAuth({ issuer: 'https://auth.staging.provica.ch', clientId: 'alpfon-kundenkonto', redirectUri: 'https://portal.example.ch/api/auth/provica/callback', sessionSecret: process.env.PROVICA_SESSION_SECRET, scopes: ['openid', 'eid'], }) // app/profile/page.tsx — verified claims, server-side const session = await auth() const { given_name, family_name, birthdate } = session.claims
Die JS/TS-Pakete liegen noch nicht öffentlich auf npm — Beta-Kunden bekommen sie zusammen mit den Zugangsdaten von uns. Wer lieber ohne SDK arbeitet, nimmt jeden zertifizierten OIDC-Client.
| Scope | Attribute |
|---|---|
| openid | nur das pseudonyme sub |
| profile | given_name, family_name, birthdate |
| eid | given_name, family_name, birthdate, nationality |
| age_verification | age_over_18 |
| eid_full | given_name, family_name, birthdate, age_over_16, age_over_18, age_over_65, age_birth_year, birth_place, place_of_origin, sex, nationality, portrait |
Angefragt wird immer nur der Schnitt aus Scope und der Attribut-Policy des Clients. Was die Policy nicht erlaubt, holt auch ein grosszügiger Scope nicht.
| Paket | Was Sie bekommen |
|---|---|
| @provica/sdk | Framework-unabhängig über openid-client: Login-URL, Callback, Logout, typisierte Claims — dazu die Check API. |
| @provica/sdk-next | Next.js in zwei Varianten: eigenständig mit auth() und Login-Button, oder als Provider-Preset für Projekte, die schon Auth.js nutzen. |
| Angular & andere SPAs | Kein Provica-Paket nötig: angular-oauth2-oidc oder angular-auth-oidc-client gegen die Discovery-URL, als Public Client mit PKCE. |
| .NET, Java, PHP | Auf der Roadmap. Bis dahin trägt jeder zertifizierte OIDC-Client die Integration. |
Während der geschlossenen Beta ist Provica vollständig und kostenlos nutzbar. Standard und Enterprise folgen zum Produktivstart — die Preise legen wir gemeinsam mit Ihnen fest.
swiyu ist die staatliche Wallet-App für die Schweizer e-ID. Provica prüft die daraus vorgelegten Nachweise — es ersetzt swiyu nicht.
Ja — die swiyu-Wallet mit einer Beta-ID. Ihr Portal selbst braucht nichts ausser einem OIDC-Client.
Nur die, die Ihre Policy und der Zweck erlauben — z. B. Altersnachweis oder Name. Werte werden nach der Retention gelöscht.
SwissID ist ein Identitätsanbieter. Provica ist ein Broker zur staatlichen e-ID (swiyu): Sie integrieren einmal OIDC, wir sprechen mit der Wallet.
In der Schweiz. Verifizierte Attribute liegen verschlüsselt und nur für die konfigurierte Retention-Dauer.
Zweckbindung, Datenminimierung und ein Consent-Log ohne Werte sind Kern des Designs. Die finale Konformitätsprüfung liegt bei Ihnen.
Die Beta ist kostenlos, aber derzeit geschlossen: Sie tragen sich auf die Warteliste ein und wir melden uns mit einem Zugang. Für den Produktivbetrieb erstellen Sie später ein neues Konto — Beta-Konten und -Daten werden nicht migriert.
Brauchen Sie einen stabilen Identifikator, um ein Konto zu führen, oder normale Profilattribute wie Name und Geburtsdatum? Dann Login. Brauchen Sie nichts als die Antwort auf eine gestellte Bedingung — Altersschranke, Staatsangehörigkeit — und hätten sonst keinen Grund für einen OIDC-Client? Dann Check API. Eine Prüfung legt kein Subjekt an und ist mit keiner zweiten Prüfung derselben Person verknüpfbar.
Nein. Beim Age Gate hält der von uns gehostete Dienst den Check-Client Ihres Shops — in WooCommerce bekommt Ihr Shop nur einen API-Key, in Shopify nicht einmal den, weil Shopify den Aufruf selbst signiert. Direkt mit dem Broker spricht er nie. Wird der Shop kompromittiert, sind damit keine Broker-Zugangsdaten erbeutet.
Nein — und das sagen wir lieber deutlich. Wer den QR-Code oder den Link bekommt, kann die Prüfung abschliessen, auch aus der Ferne. Ein Same-Device-Deeplink, bei dem sich die Wallet auf demselben Gerät öffnet, mindert das wirksam; ein Cross-Device-Scan nicht. Das liegt an wallet-basierter Verifikation allgemein, nicht an Provica.
Ein Ja oder Nein zur Altersgrenze, sonst nichts. Die Altersschranken sind im Nachweis bereits vorberechnet, deshalb muss für «über 18» kein Geburtsdatum offengelegt werden — es verlässt die Wallet nicht und Ihr Shop speichert es folglich auch nicht.
Ihre Produkte bekommen ein Feld «Altersfreigabe» — leer, ab 16 oder ab 18 —, und der Warenkorb erbt die strengste Stufe seiner Positionen. Liegt etwas Altersbeschränktes darin, führt der Weg zur Kasse über die gehostete Prüfseite. Anders als WooCommerce kann Shopify eine Bestellung nicht vorab ablehnen: Ohne gültigen Nachweis entsteht sie, wird aber zurückgehalten und getaggt, damit Sie sie freigeben oder stornieren. Zwei Handgriffe bleiben bei Ihnen — die App-Einbettung im Theme aktivieren und die Altersfreigabe setzen. Beide scheitern in die sichere Richtung: Unterbleiben sie, werden Bestellungen zurückgehalten, nie ungeprüft durchgelassen.
Provica ist in geschlossener Beta. Tragen Sie sich ein, und wir melden uns, sobald ein Platz frei wird.