Dezentrale digitale Behördenkommunikation
Dezentrale digitale Behördenkommunikation mit Solid Pods und optionaler E-ID Integration.
Bedarf/Problem und Zielgruppe
Die heutige digitale Behördenkommunikation ist fragmentiert: Bürgerinnen und Bürger nutzen unterschiedliche Portale, Logins und Kanäle je nach Behörde. Dies erschwert den Zugang, reduziert die Nutzerfreundlichkeit und schafft Abhängigkeiten von zentralen Plattformen. Betroffen sind insbesondere Einwohnerinnen und Einwohner, Unternehmen sowie Behörden auf kommunaler, kantonaler und nationaler Ebene.
(Nicht) verfügbare Daten
Verfügbar sind öffentlich bekannte Standards und Technologien wie Solid Pods, Verifiable Credentials, E-ID-Grundlagen sowie offene Schnittstellenkonzepte. Für einen Prototyp reichen synthetische Testdaten wie Steuerbescheide, Verfügungen oder Mitteilungen. Nicht verfügbar bzw. abzuklären sind produktive Verwaltungsdaten, bestehende Behördenschnittstellen, reale Zustellprozesse sowie zukünftige E-ID-Integrationen.
Erwarteter Nutzen
Bürgerinnen und Bürger hätten einen zentralen, selbst kontrollierten digitalen Briefkasten für Behördenkommunikation – unabhängig von einzelnen Portalen. Der Zugang zu staatlichen Leistungen würde einfacher, sicherer und nutzerfreundlicher. Behörden könnten standardisiert, interoperabel und effizient kommunizieren, während Datenhoheit, Transparenz und digitale Souveränität gestärkt würden
Ziel für den Hackathon
Ziel ist die Entwicklung eines klickbaren Prototyps oder End-to-End-Demos für eine dezentrale Behördenkommunikation auf Basis von Solid Pods. Gezeigt werden soll, wie eine Behörde ein Dokument sicher zustellt und wie Bürgerinnen und Bürger dieses nutzerfreundlich abrufen, verwalten und freigeben können. Zudem soll die technische Machbarkeit, Sicherheit und Interoperabilität des Konzepts validiert werden.
Lösungsansätze
Mögliche Lösungsansätze sind zentrale Zustellplattformen, klassische E-Government-Portale, E-Mail-basierte Kommunikation oder dezentrale Modelle mit Solid Pods und Verifiable Credentials. Bereits bekannt sind zentrale Ansätze wie „Meine digitale Post“ oder kantonale Portallösungen. Im Hackathon soll gezielt der dezentrale Ansatz mit Solid Pods, offenen Standards und optionaler E-ID prototypisch umgesetzt und mit bestehenden Modellen verglichen werden.
Einschränkungen
Zu beachten sind Datenschutz, Informationssicherheit und der rechtskonforme Umgang mit behördlichen Daten. Für den Hackathon sollten deshalb nur synthetische oder anonymisierte Testdaten verwendet werden. Die Lösung sollte auf offenen Standards, dokumentierten Schnittstellen und einer modularen Architektur basieren, damit Ergebnisse später weiterentwickelt und in bestehende Behördenlandschaften integriert werden können.
Nachhaltigkeit
Nach dem Hackathon werden die Ergebnisse dokumentiert und als Grundlage für eine mögliche Weiterentwicklung des Konzepts bewertet. Je nach Reifegrad kann ein Proof-of-Concept in eine weiterführende Pilotierung überführt werden.
Für eine mögliche Weiterentwicklung können begrenzte interne Ressourcen für Konzeptarbeit, technische Evaluierung und Architekturweiterentwicklung bereitgestellt werden. Ein fixes Budget oder dedizierte Projektmittel sind aktuell noch nicht definiert.
Teilnehmer:innen können bei Interesse in eine weiterführende Ideation- oder Pilotierungsphase eingebunden werden, z. B. über Workshops, technische Reviews oder eine spätere Open-Innovation- bzw. Community-Zusammenarbeit.
Behörden-Briefkasten — Chrome Extension
GovTech Hackathon · MVP
A decentralised government mailbox built on Solid — your official documents live in your own Pod, not on a government server.
What it does
Behörden-Briefkasten ("Government Letterbox") is a Manifest V3 Chrome Extension that gives citizens a single, privacy-preserving inbox for official government documents. Instead of storing letters on a centralised government platform, each document is delivered directly into the citizen's personal Solid Pod. The extension then:
- authenticates the user via Solid-OIDC (Authorization Code Flow + PKCE, Dynamic Client Registration — no pre-configured
client_idrequired), - lists all documents stored in the Pod's
behoerden-briefkasten/inbox container, - polls the inbox every 30 seconds in the background and fires a desktop notification the moment a new document arrives.
The trust anchor for login is an E-ID (prototype flow; production target: swiyu).
Architecture
Chrome Extension (MV3)
│
├── auth.js Solid-OIDC login, token management, authenticated fetch
├── pod.js LDP container listing + JSON envelope parsing
├── background.js Service Worker — alarm-based polling, notifications, badge
├── popup.html/js 360 px popup UI — login view & inbox list
└── manifest.json Permissions: identity, storage, alarms, notifications, offscreen
Auth flow in detail:
chrome.identity.launchWebAuthFlowopens the Solid Provider login page.- The extension performs Dynamic Client Registration on first login — it registers itself at the CSS
registration_endpointautomatically. - After the Authorization Code exchange the access token is stored in
chrome.storage.local. - Every authenticated request sends a
Bearertoken. ADPoPheader upgrade (per-request signed JWT) is marked inauth.jsfor the production path.
Notification flow:
Gateway PUT → new resource in Pod → background.js polls → new ID detected → Desktop Notification
Project Structure
behoerden-briefkasten/
├── manifest.json
├── auth.js
├── pod.js
├── background.js
├── popup.html
├── popup.js
└── icon128.png ← you need to add this (128×128 px)
Prerequisites
- Google Chrome or Microsoft Edge (Chromium-based)
- A running Community Solid Server (CSS) — default URL
http://localhost:3000 - Node.js (only needed to run the CSS locally)
Install the Community Solid Server
npx @solid/community-server -p 3000
Or with a custom config (recommended for CORS tweaks):
npx @solid/community-server -p 3000 -c @css:config/file.json
Installation
1. Load the extension in Chrome
- Open
chrome://extensions - Enable Developer mode (top-right toggle)
- Click "Load unpacked" and select the
behoerden-briefkasten/folder - Note the Extension ID shown on the tile (you'll need it for CORS if issues arise)
2. Create a Solid Pod for the test user
Open http://localhost:3000/.account/ in your browser and create an account for e.g. alice.
3. Log in via the extension
- Click the extension icon in Chrome's toolbar
- The default issuer
http://localhost:3000is pre-filled — adjust if your CSS runs elsewhere - Click Login (or Mit E-ID anmelden for the trust-anchor demo path)
- Complete the Solid-OIDC consent screen in the popup window
- On success the popup switches to the inbox view showing your WebID
CORS Configuration
The extension origin is chrome-extension://<EXTENSION-ID>. Most CSS setups reflect the Origin header automatically, so CORS works out of the box.
If login or inbox listing fails with a CORS error, start CSS with a relaxed CORS config:
npx @solid/community-server -p 3000 -c @css:config/file.json \
--corsOrigin="*"
The OIDC redirect URI used by the extension is:
https://<EXTENSION-ID>.chromiumapp.org/callback
Because Dynamic Client Registration is used, this URI is registered automatically on first login — no manual setup needed on the server side.
End-to-End Test
- Start the CSS:
npx @solid/community-server -p 3000 - Create an
aliceaccount athttp://localhost:3000/.account/ - Load the extension and log in
- Deliver a document via the government gateway:
POST http://localhost:3000/api/behoerde/zustellen - Within ~30 seconds a desktop notification "Neues Behörden-Dokument" appears and the popup inbox list updates automatically
You can also click Aktualisieren in the popup to trigger an immediate check.
Key Design Decisions
| Topic | Decision | Reason |
|---|---|---|
| Auth library | Custom (no @inrupt/solid-client-authn-browser) |
Inrupt's browser library relies on window.location redirects, which don't work in an MV3 Service Worker |
| Token type | Bearer (MVP) | CSS accepts Bearer tokens for the Auth Code flow; DPoP upgrade is marked in auth.js |
| Client registration | Dynamic (RFC 7591) | No pre-configured client_id needed — zero server-side setup for the demo |
| Polling interval | 30 s (POLL_MINUTES = 0.5) |
Short enough to feel live during a hackathon demo; increase for production |
| Storage format | JSON envelopes (.json files in LDP container) |
Simple to produce from the gateway, easy to extend with encryption (ciphertext field already parsed) |
Roadmap / Production Hardening
- [ ] DPoP — replace Bearer with per-request signed JWTs (hook already in
auth.js) - [ ] Token refresh — use
refresh_tokento silently renew expired access tokens - [ ] End-to-end encryption — the
ciphertextenvelope field is reserved; add key management via the Pod - [ ] swiyu E-ID — wire the real Swiss E-ID trust anchor instead of the prototype button
- [ ] Unread tracking — persist read/unread state per message ID
- [ ] Document download — open/download the original file (PDF, etc.) from the Pod resource URL
License
MIT — built during a GovTech Hackathon. Contributions welcome.
Previous
GovTech Hackathon 2026
Next project