# CodeB Sovereign Communications — llms-full.txt # Plain-text export of every public page in /sitemap.xml, in one file, # for answer engines, search engines and model training. You are welcome # to read, index, quote and learn from it; please link back to the # Source URL of a section when you cite it. Companion to /llms.txt # (link index), /ai.txt (usage policy), /robots.txt (crawl policy). # Generated 2026-10-13 from 244 pages. # --- =================================================================== # CodeB · Sovereign identity, EU Wallet, Voice AI + WebRTC/SBC layer · Aloaha # Source: https://www.aloaha.com/default.html =================================================================== > Nine sovereign products from Aloaha Limited, Malta: Windows Credential Provider V2, OpenID Connect + Passkeys IdP, EU Digital Identity Wallet verifier, programmable Voice AI on browser + SIP, and a sovereign Session Border Controller. The identity-aware AI, WebRTC and SBC layer for your existing telephone network — or the modern foundation for your own communications service. NIS2 / DORA / CRA / GDPR aligned, no cloud required. Sovereign identity · European Digital Identity Wallet · Voice AI · Self-hosted ## Identity, wallets, telephony and Voice AI. One sovereign stack. Zero cloud lock-in. Nine integrated products, one self-hosted platform. Hardened Windows logon , an OpenID Connect + Passkeys identity provider, a live European Digital Identity Wallet verifier and issuer, a new Business-Wallet for multi-employee firms, browser meetings + softphones , a programmable Voice AI layer, a sovereign SBC , a Remote Signature Service (CSC v2, PAdES-B-T with trusted timestamp) and the ZUGFeRDPro e-invoicing SDK (ZUGFeRD, XRechnung, Factur-X, UBL — ready for the German 2025-2028 mandate and EU ViDA). Bolted onto what you already own — FRITZ!Box, Asterisk, FreePBX, carrier SIP, Teams Direct Routing — or the foundation for a fresh service. NIS2 / DORA / CRA / GDPR aligned. Runs in air-gapped networks. This page itself is the production tenant. Free during preview · 30-day no-limits grace · early-adopter pricing locked in · EU-hosted, no tracking pixels, no analytics beacons. What's new · August 2026 - European Business-Wallet — multi-employee corporate credential vault, once-only, selective disclosure, immutable audit - Cross-tenant trust federation (signed bilateral trust statements) - Countersign endpoint — banks, notaries and auditors endorse documents - HMAC public share links + Bitstring Status List revocation - Wallet-Instance-Attestation per employee · multi-DID (did:web, did:key, did:jwk, did:webvh) - mDoc / ISO 18013-5 issuance + presentation scaffolding ### Nine sovereign products, one integrated platform. Ranked by where they create the most defensible value. Take one. Take all nine. Run them next to anything you already own — carrier SIP, Teams Direct Routing, FRITZ!Box, Asterisk, FreePBX — or replace those pieces piecemeal on your own timeline. On wide screens the tiles flow as a 3×3 grid; on tablet and mobile they collapse to two columns and then one. 01 · CodeB Credential Provider V2 #### Replace the Windows password tile. The flagship of the CodeB line. Replaces the Microsoft password tile via the documented Credential Provider Filter interface — NFC, TOTP, PKI smartcards or USB tokens, as second factor or full passwordless. 100 % managed .NET. FIPS 140-2 enforceable by Group Policy. Windows 8 through Server 2025. No cloud, no telemetry, runs in air-gapped networks. - NFC, TOTP, PKI smartcards, USB tokens · second factor or fully passwordless - FIPS 140-2 enforceable by Group Policy - System Tray Edition · card-remove auto-lock - Tools Edition · standalone helpers, scriptable - Admin CLI · CSV-driven enrolment for hundreds of cards - Pairs with the CodeB IdP and EU Wallet verifier to extend Windows logon into single sign-on for your apps 02 · OpenID Connect & Passkeys IdP #### A drop-in EU identity provider you can host yourself. An OpenID Connect identity provider for Nextcloud, WordPress, Grafana, GitLab, Teams, AWS, Azure or your own apps — with Passkeys (FIDO2 / WebAuthn) and magic-links wired alongside. Per-tenant RS256 keys, PKCE-only flows, RFC 7662 introspection, RP-Initiated Logout. Server never sees plaintext passwords; the user's own device signs the assertion. - OIDC IdP · per-tenant RS256 keys · PKCE-only · RFC 7662 introspection · RFC 7009 revocation - Passkeys (FIDO2 / WebAuthn) · TouchID / Windows Hello / YubiKey · phishing-resistant - Magic-link sign-in & self-service password recovery - Identity claims propagate into the SIP, WebRTC and SBC layers below — a caller is the same subject as a logged-in user - Wallet-as-recovery: forgot-password via your EU Wallet 03 · EU Digital Identity Wallet validator #### Accept verified EU Wallet credentials — today, in production. One of the first self-hostable EU Digital Identity Wallet verifiers in operation. OID4VP 1.0 , HAIP 1.0 , SD-JWT VC . Live on this domain right now. Replace usernames and passwords with cryptographically verified European Digital Identity Wallet claims — SD-JWT VC + KB-JWT selective disclosure — for sign-in, account recovery, customer onboarding, KYC, age gating, healthcare attestations, public-sector portals. Government-issued Personal Identification Data (PID) remains reserved for Member State-notified providers; CodeB is the verifier / relying-party integration. - OID4VP 1.0 verifier · HAIP 1.0 profile · SD-JWT VC and mDL credential formats - Cited by the Maltese Minister responsible for digital identity (2026-06) - Interoperability tracked in a published per-Member-State wallet matrix — wider real-wallet coverage lands as the ecosystem stabilises - Wallet sign-in, wallet recovery, wallet KYC at onboarding, wallet-bound consent for AI calls - REST API + signed webhooks for integration into any application Live proof: the EU Reference Wallet on Android after a successful PID presentation to this verifier. Verified CodeB / Aloaha Limited badge is drawn by the wallet from the entry the EU registry holds against us. See the registration proof → 04 · Voice AI & PBX #### Programmable, sovereign, carrier-independent Voice AI — not just an AI receptionist. A self-hosted browser-and-SIP communications platform with a fully programmable Voice AI core. Per-number persona prompts, real-time multilingual conversations, scheduled outbound campaigns with conditional retries, human SIP transfer mid-call, signed transcripts and summaries emailed after every call, REST API initiation, HMAC-signed webhooks, pluggable AI engine, local TTS fallback, bring-your-own SIP carrier. WebRTC meetings + browser softphones + SIP gateway included. - Programmable Voice AI · per-vnum persona / prompt / voice / language - Outbound campaigns · scheduled, conditional retries, signed summary delivery - SIP REFER human-transfer mid-call · AI hands the caller to a hardphone or browser tab - REST v1 initiation + HMAC-signed webhooks · the AI is API-first - Pluggable AI Voice Engine · cloud or on-prem · local TTS fallback if the engine is unreachable - HD WebRTC meetings · browser softphones (SIP-over-WebSocket RFC 7118) · bring-your-own SIP trunk - Signed call recordings (forensic-grade ECDSA sidecar) 05 · Sovereign SBC #### The identity-aware SIP/WebRTC layer between your apps and your telephony. A self-hosted Session Border Controller folded into the same install as the meetings, identity and Voice AI. Sits at the boundary of your VoIP estate — in front of FRITZ!Box, Asterisk, FreePBX or your carrier trunk — and does the work classic SBC vendors sell as a standalone appliance, plus identity-aware policy that none of them ship. For telecom operators, CPaaS developers, white-label communications providers, companies embedding calls into portals, and vendors building specialist browser phones. - SIP normalisation, NAT traversal, integrated TURN (UDP / TCP / TLS) with ICE-Lite for hardphones - SIP-over-TLS (RFC 5630) for encrypted hardphone registration · per-trunk SDES SRTP (RFC 4568) on the carrier leg · persistent REGISTER-pinhole reuse (RFC 5626) so TLS phones survive NAT teardowns - Any-to-any voice interop matrix · WebRTC browsers, SIP-over-WebSocket softphones (sip-js / JsSIP), classic UDP phones (MicroSIP, Asterisk) and TLS-registered hardphones (Yealink) reach each other through one bridge with full SDP rewriting + media transcoding - Native WebRTC ↔ SIP gateway · DTLS-SRTP ↔ RTP/SRTP · Opus ↔ G.711 transcoding - Identity-aware SIP · OIDC, Passkeys, EU Wallet claims resolve to the same tenant subject as REGISTER - Access control with CIDR + glob + per-tenant + private-IP bypass + brute-force auto-block - Signed CDRs + tamper-evident recordings (ECDSA-P256 sidecar) - Multi-tenant by domain · one bridge, isolated App_Data per tenant · hot-reloadable trunks and TURN config - BYO carrier · no vendor lock on the underlying telephony estate 06 · Team Chat #### The messaging layer that stays inside your tenant. Direct messages, group channels and file sharing — all served by your own IIS / bridge install, per-tenant isolated, OIDC-authenticated. No third-party gateway ever sees the messages. Real-time delivery over WebSocket, poll fallback for restrictive networks, drag-and-drop uploads up to 20 MB, and an offline-catch-up email if a teammate has unread messages after 24 hours away. - Direct messages + group channels · per-tenant isolated under App_Data - Real-time WebSocket delivery · poll fallback works behind restrictive networks - File attachments up to 20 MB · drag-and-drop · images preview inline - OIDC-authenticated senders · identity clamped server-side, no spoofing - Offline catch-up email · if a user is offline ≥24 h with unread messages - Embeddable widget · drop "Chat with us" into any tenant page (visitor pairing via HMAC invitation) - Unified bubble · in-meeting chat and standalone chat share one visual style across every surface - Meeting archives · signed-in users get an auto per-day, per-room record of what they said in the room chat, browseable from chat.html (guests stay ephemeral) - Full REST + WS API · automate bots, hook into CRMs, script announcements - WhatsApp Business Cloud API connector · per-tenant Meta App credentials, HMAC-verified webhooks, media caching, appsecret_proof, and a shared “WhatsApp Inbox” group thread so your team replies to WhatsApp customers from the same UI as internal chat 07 · Business Intelligence #### Property Management System that publishes its own website — and uses your phone system. A full PMS for short-let, holiday-let and hotel operators, running inside the same CodeB tenant as your phone system. Real-time ops dashboard, revenue analytics, housekeeping, guest inbox and owner statements — and the public-facing property website is a live rendering of the same inventory, no separate CMS. Meet, Chat and Call are the CodeB comms you already know. Multi-tenant, OIDC-authenticated, EU-hosted. - Today dashboard · check-ins, check-outs, stay-overs, bookings, transactions · live - Ops modules · arrivals, turnovers, guest inbox, housekeeping, issues, calendar, CDR, devices - Revenue · revenue, cashflow, forecast, pick-up, pace, performance, owner statements - Properties · occupancy, pricing, catalog, reviews, channels, guests, inventory · single source of truth - Dynamic public website · auto-generated from Properties, per-tenant branding, leads capture, iCal sync - Channel managers · The PMS plugs in natively, source picker in the top nav - Meet · Chat · Call · the CodeB phone system, not a third-party embed - Multi-tenant · each customer (or owner) on their own subdomain, per-tenant audit log 08 · Remote Signature Service #### Sign PDFs from a browser or from your backend — PAdES-B-T with trusted timestamp. A Cloud Signature Consortium (CSC) v2 signing service and a browser-side signing client, running on the same tenant as the rest of the platform. Per-user signing certificates minted from your OIDC profile (Common Name, given name, family name, email), incremental save preserves prior signatures, RFC 3161 trusted timestamp from a configurable TSA, and full support for encrypted source PDFs (Standard V2 RC4-128 and V4 AES-128). Advanced Electronic Signature (AdES) scope, self-signed keys today — the CSC v2 API surface and audit trail are designed to accept a Qualified Signature Creation Device (QSCD) connector for Qualified Electronic Signatures (QES) as a future upgrade, aligned with the European Digital Identity Wallet remote-signing patterns. - Browser signing client · sign.html · drag-drop, multi-page preview, arrow-key navigation, edit Reason/Location/ContactInfo per signature - Cloud Signature Consortium v2 API subset — per-user credential list, SCAL2 authorisation with WebAuthn plus PIN, hash signing, full-document signing, RFC 3161 timestamp fetch - PAdES-B-B baseline — CMS signed attributes per ETSI EN 319 122-1, including signing-certificate v2 with issuer and serial binding - PAdES-B-T — RFC 3161 timestamp embedded in every signature; the timestamp authority is a per-install configuration knob - Per-user certificate lifecycle — every user gets their own EC P-256 signing key on first use, wrapped by the operating system key store; the certificate subject is populated from the OIDC profile (name, given, family, e-mail) - Incremental save preserves prior signatures — classic xref-table PDFs and xref-stream PDFs both supported (ISO 32000-1 §7.5.6) - Encrypted PDF support — signs source PDFs protected by the Standard security handler (RC4-128 and AES-128) without requiring decryption first - SCAL2 Signature Activation Data — short-lived signed authorisation bound to the document hash, with PIN and WebAuthn second factors verified server-side before the signature is released - Advanced Electronic Signature scope today — not QES yet, but the crypto module is pluggable so a certified HSM or QTSP backend can be swapped in on customer engagement 09 · E-Invoicing SDK · ZUGFeRDPro #### ZUGFeRD, XRechnung, Factur-X and UBL — on your own servers, in your own code. The Aloaha ZUGFeRDPro SDK creates and reads EN 16931-conformant electronic invoices in CII syntax — ZUGFeRD, XRechnung, Factur-X — and reads UBL / PEPPOL as a bridge. On-premise COM + .NET + CLI + Web Services surface. Invoice data never leaves your process. Ready for the German mandate: receive since 2025-01-01, issue phased 2027-01-01 (turnover > EUR 800k) and 2028-01-01 (all businesses). France Factur-X 2026-09-01 receive / 2026-09-01 issue for large + medium, 2027-09-01 all. Italy SDI mandatory since 2019; Poland KSeF, Belgium PEPPOL 2026-2028. EU ViDA directive brings a common wire in 2030-2035. - Create ZUGFeRD / XRechnung / Factur-X XML in UN/CEFACT CII syntax - Embed the XML into existing PDF/A or generate a fresh PDF/A-3 from XML + Word template - Extract the XML back out of any received ZUGFeRD or Factur-X PDF, no OCR - Read UBL 2.1 / PEPPOL BIS Billing 3 into the same internal model — SDK acts as UBL→CII bridge - XAdES on the XML, PAdES + RFC 3161 timestamp on the wrapping PDF (via CodeB Signature Server) - COM interface for VB6 / VBA / classic ASP / MS Access / Navision / Delphi retrofit - .NET assembly (early and late binding) for C# / VB.NET / PowerShell / F# / modern ERP - Command-line tools for batch pipelines + Web Services for language-agnostic HTTP callers - OEM licence for ISVs embedding ZUGFeRD output into their own accounting / billing / ERP product - Standalone GUI + free ZUGFeRD PDF Viewer for exception-handling by accounting staff ### Three ways to phone from your browser. Same audio quality. Same call routing — internal extensions, AI agents, virtual numbers, external destinations all work identically. Pick whichever matches how your team already works, or run all three side by side. All are installable PWAs. A · Office (CodeB native) #### Full-featured CodeB Webphone. The default browser softphone for CodeB tenants. Click-to-call, meeting handoff, in-room chat, screen share, presence. Talks to the bridge over the CodeB signalling channel — no third-party SIP library to learn. - One-click meeting handoff to/from a phone call - Presence, in-room chat, screen share built in - PWA install · works offline for sign-in shell B · SIP.js #### Bring your own RFC 7118 softphone. For teams that already use the SIP.js library or want a pure standards-based path. Speaks SIP over WebSockets directly to the bridge. Real 3×4 dialpad with DTMF. Credentials in your browser’s localStorage — never on our servers. - Pure RFC 7118 · vendor-neutral SIP-over-WSS - SIP.js v0.21.2 from public CDN - PWA install · credentials never leave the device C · JsSIP #### Same standard, alternative library. For teams that prefer the JsSIP library or already have integrations against it. Same RFC 7118 wire protocol, same dialpad UX, same browser-only credential storage. Pick whichever JS library your team already knows. - Pure RFC 7118 · vendor-neutral SIP-over-WSS - JsSIP v3.10.1 from public CDN - PWA install · credentials never leave the device Live, on this very server ### This page proves itself. SIP fraud engine built-in An operator-curated Access Control system gates every inbound INVITE and every outbound dial. CIDR + glob + per-tenant + private-IP bypass + auto-blacklist on brute-force. Toll fraud doesn't reach your trunk. EU Wallet verifier live Full OID4VP 1.0 end-to-end with SD-JWT VC + KB-JWT holder binding. The wallet-preferred x509_hash (HAIP 1.0 Final) and additional x509_san_dns (OpenID4VP compatibility mode) client identifier prefixes supported. Try it on logineu.html . Standards-first RFC-based Built on published RFCs and OpenID / EUDI specifications, with minimal proprietary crypto glue. RFC 6749, 7009, 7517, 7523, 7662, 8414, 9101, 9116, 9309. OID4VP 1.0. HAIP 1.0. WebAuthn L3. SIP over UDP and TLS (SIPS, RFC 5630). No proprietary protocol, no lock-in. Hosted in EU Aloaha Limited — Malta-registered, EU-hosted. Zero tracking pixels, zero analytics SDKs, zero third-party CDN. RFC 9116 security.txt published. Why this exists ### Because EU sovereignty isn't a slogan. #### Your data never leaves your infrastructure. No US analytics SDK. No third-party CDN. The phone calls, the identity sign-ins, the Windows logon events — all stay on your server. The same binaries you run, you can audit. The AI Voice Engine is pluggable: local TTS auto-reply ships by default (no cloud at all); the real-time AI Voice Engine is operator-selected per tenant (local or your chosen cloud provider) so the data-path choice is yours. #### NIS2 · DORA · CRA aligned by default. Designed around the EU Cyber Resilience Act (Reg. 2024/2847), NIS2 and DORA from the first commit. Secure-by-default, vulnerability handling documented, security.txt published, atomic file writes with rolling backups everywhere. #### Standards over lock-in. Always. Every protocol we speak is RFC, W3C, OIDF or ISO. Every API is documented and curl-able. Every integration is BYO-anything: bring your own SIP trunk, your own AI engine, your own SMTP, your own IdP — or use ours. Walk away anytime. #### One team. One product line. Real humans. You email info@aloaha.com , you get a reply from the people who write the code. Aloaha Limited has shipped signing, PKI and secure communications software since 2003 — and dogfoods every product in production. Your own free live tenant ### Try it on your own domain. Free. In production. Conference, Phone bridge, Voice AI and the OIDC + EU Wallet identity stack are fully multi-tenant . Every customer gets their own isolated tenant — their own users, their own trunks, their own admin UI, their own data on disk. Free to evaluate, live, on infrastructure you can verify. Path A · You point the DNS #### Bring your own subdomain. Point an A record from your subdomain (e.g. phone.yourcompany.com ) at our IP, then email us. We light up your tenant inside one business day — your domain, your Let's Encrypt certificate, your isolated admin console at phone.yourcompany.com/admin.html . - Your domain in every URL — full white-label feel - Your own SIP trunks, vnums, recordings, transcripts - Your own OIDC IdP signing keys (per-tenant RS256) - Zero data sharing with other tenants — HARD-isolated by host Path B · We host the subdomain #### Pick a name. We host it. No DNS control needed. Suggest a tenant name and we provision .codeb.io or .aloaha.com for you, live, free, inside one business day. Same isolation, same admin console, same per-tenant data — just under our DNS. - Live within one business day — no infrastructure prep - Same multi-tenant isolation as Path A - Move to your own subdomain later, anytime, no data loss - Free evaluation period · no card, no contract, no auto-billing Both paths give you a real production tenant — not a demo sandbox, not a screenshot, not a marketing trial that's artificially gated. The same multi-tenant code that runs phone.aloaha.com runs your tenant. The same ACL system that defends our trunks defends yours. Walk away anytime, take your data with you. How it works ### See the architecture, not just the screenshots. Four canonical data flows, each one diagrammed end-to-end so an architect can verify our claims before booking a call. Every flow is on a separate page with two SVG diagrams — ingress and egress — sized for print and screen. Flow 01 · Meetings #### Your video never touches the server. Browser-to-browser DTLS-SRTP over WebRTC; the server only relays signalling. Peer-to-peer mesh by default; auto-promotes to a self-hosted SFU on demand. See where media flows, where signalling goes, and where neither does. View the meeting data flow → Flow 02 · SIP bridge #### Where the browser meets the phone network. WebRTC ↔ SIP gateway with BYO trunk. PAI/RPID outbound caller-ID, multi-trunk priority, integrated TURN. Two diagrams: inbound from PSTN, outbound to PSTN. View the SIP bridge data flow → Flow 03 · Identity (OIDC) #### Sign-in, end to end, no cookies. OpenID Connect Authorization Code + PKCE through to refresh-token rotation, plus the EU Wallet (OID4VP) side path. Per-tenant RS256 keys, RFC 7662 introspection, RFC 7009 revocation. View the identity data flow → Flow 04 · Voice AI #### AI on your trunk, prompts on your disk. How a single inbound DID is mapped to a virtual-number persona, how the prompt is loaded, where the AI Voice Engine sits, and how the transcript ends up in your tenant's storage. Pluggable engine, fixed contract. View the AI receptionist data flow → Each diagram is a static SVG — no client-side rendering, no third-party CDN, no JavaScript required. Open the page, hit Ctrl+P, hand the print-out to your architect. Three ways to start a conversation ### Let's talk. Whether you want a Credential Provider evaluation key, a 20-minute demo of the AI receptionist, an integration walkthrough for the OIDC IdP, or just to understand whether self-hosted CPaaS makes sense for your team — start here. 01 #### Send the form Quick, captcha-gated, no account. Tell us your scenario; we'll come back with the right person and the right deck. contact.html → 02 #### Email us directly One business day for substantive replies. Forward a brief, attach a deployment diagram, send an RFP — whatever helps. info@aloaha.com → 03 #### Call us in the browser One click, WebRTC, no app to install, no number to dial. Rings the office during business hours CET. Uses the same SIP bridge we sell. Click to call → Replies within one business day. Email lands with humans, not a queue. Need an evaluation key for the Credential Provider? Add "eval key" to your subject — we ship one inside 24 hours. Built and operated by Aloaha Limited , Malta-registered since 2003. CodeB Conference runs in production on this domain as the daily-driver phone and meeting platform for the team that develops it — dogfooded, not demoware. Registered: Malta · Aloaha Limited · EU-hosted · no tracking pixels, no analytics SDKs · RFC 9116 security.txt published · Talk to us → By industry: Hospitality · Healthcare · Law firms · Public sector · IT providers & resellers · Telecoms (EU Wallet) CP V2 · Voice AI · Identity · EU Wallet · All features · Public APIs · Pricing · Contact · Status · Imprint Architecture diagrams: Meetings flow · SIP bridge flow · OIDC flow · Voice AI flow The sovereign Plan B ### Plan A is surrender. Plan B is sovereignty. In today’s IT landscape, ‘Plan A’ is surrendering your data to Big Tech, accepting vendor lock-in, and relying entirely on the public cloud. When the internet drops, your workforce is locked out. We are CodeB . We are the sovereign, self-hosted Plan B . We give you back control of your keys, your communications, and your identity — and our systems keep running even when the internet doesn’t. - Your keys - Your communications - Your identity - LAN-fallback continuity Air-gap-capable. FRITZ!Box, Asterisk, FreePBX, Teams Direct Routing next to it — not above it. NIS2 / DORA / CRA / GDPR aligned. EU-built. ### Frequently asked questions What is CodeB? CodeB Sovereign Communications is a self-hosted platform from Aloaha Limited that combines identity, European Digital Identity Wallet support, telephony and Voice AI in one stack. The platform is made up of nine integrated products that can be run next to systems you already own, such as FRITZ!Box, Asterisk, FreePBX, carrier SIP or Teams Direct Routing, or used as the foundation for a new service. The www.aloaha.com homepage itself runs on the production tenant. Who makes CodeB? CodeB is built and operated by Aloaha Limited, a Malta-registered company that has shipped signing, PKI and secure communications software since 2003. Aloaha Limited runs CodeB in production as the daily phone and meeting platform for its own team. Emails to info@aloaha.com are answered by the people who write the code. Which products are in the CodeB line? The CodeB line has nine products: CodeB Credential Provider V2 for Windows logon, an OpenID Connect and Passkeys identity provider, a European Digital Identity Wallet verifier, Voice AI and PBX, a sovereign Session Border Controller, Team Chat, a Business Intelligence property management system, a Remote Signature Service and the ZUGFeRDPro e-invoicing SDK. Customers can take one product or all nine. Can I self-host CodeB? Yes, CodeB is designed to be self-hosted on your own IIS and bridge install, and it runs in air-gapped networks. Aloaha Limited also offers hosted tenants under your own subdomain or under codeb.io or aloaha.com. Every tenant is isolated with its own users, trunks, admin console and data on disk. Does CodeB keep my data inside my own infrastructure? Yes. According to Aloaha Limited, phone calls, identity sign-ins and Windows logon events stay on your server, with no US analytics SDK and no third-party CDN. The AI Voice Engine is pluggable: local TTS auto-reply ships by default with no cloud at all, and the real-time AI Voice Engine is selected per tenant by the operator, either local or a cloud provider of your choice. Is CodeB GDPR, NIS2 and DORA aligned? CodeB is described as aligned with NIS2, DORA, CRA and GDPR, and designed around the EU Cyber Resilience Act (Regulation 2024/2847), NIS2 and DORA from the first commit. Aloaha Limited publishes an RFC 9116 security.txt and documents its vulnerability handling. Aloaha Limited is Malta-registered and EU-hosted. Does CodeB use tracking or analytics? No. The CodeB site and platform are described as having zero tracking pixels, zero analytics SDKs and zero third-party CDN. The public site is EU-hosted by Aloaha Limited in Malta. What is CodeB Credential Provider V2? CodeB Credential Provider V2 replaces the Windows password tile through the documented Credential Provider Filter interface. The product supports NFC, TOTP, PKI smartcards and USB tokens as a second factor or for fully passwordless logon, is 100% managed .NET, and FIPS 140-2 can be enforced by Group Policy. Credential Provider V2 supports Windows 8 through Server 2025, has no cloud and no telemetry, and runs in air-gapped networks. Can CodeB be my OpenID Connect identity provider? Yes. CodeB includes a self-hostable OpenID Connect identity provider for Nextcloud, WordPress, Grafana, GitLab, Teams, AWS, Azure or your own apps. The IdP supports Passkeys (FIDO2 / WebAuthn), magic-link sign-in, per-tenant RS256 keys, PKCE-only flows, RFC 7662 introspection, RFC 7009 revocation and RP-Initiated Logout. The server never sees plaintext passwords. Does CodeB support the European Digital Identity Wallet? Yes. CodeB includes a self-hostable European Digital Identity Wallet verifier based on OID4VP 1.0, HAIP 1.0 and SD-JWT VC, live on www.aloaha.com. The verifier can be used for sign-in, account recovery, onboarding, KYC and age gating. Government-issued Personal Identification Data (PID) remains reserved for Member State-notified providers; CodeB is the verifier and relying-party integration. What can CodeB Voice AI do? CodeB Voice AI is a programmable, self-hosted voice AI on browser and SIP. Features include per-number persona prompts, real-time multilingual conversations, scheduled outbound campaigns with conditional retries, human transfer mid-call via SIP REFER, and transcripts and summaries emailed after every call. Calls can be started through a REST API with HMAC-signed webhooks, the AI engine is pluggable, and a local TTS fallback answers if the engine is unreachable. Do I have to replace my existing phone system to use CodeB? No. CodeB can run next to FRITZ!Box, Asterisk, FreePBX, carrier SIP or Teams Direct Routing, or replace those pieces on your own timeline. The CodeB sovereign SBC sits in front of your PBX or carrier trunk and handles SIP normalisation, NAT traversal, TURN and WebRTC to SIP gatewaying. You bring your own SIP carrier. Can I make phone calls from a web browser with CodeB? Yes. CodeB offers three browser softphones: the native CodeB Office webphone, a SIP.js softphone and a JsSIP softphone. The SIP.js and JsSIP options use SIP over WebSocket per RFC 7118 and keep credentials in the browser's localStorage. All three are installable PWAs and route calls to extensions, AI agents, virtual numbers and external destinations the same way. Does CodeB include team chat? Yes. CodeB Team Chat provides direct messages, group channels and file sharing up to 20 MB, served from your own install and isolated per tenant. Messages are delivered in real time over WebSocket with a poll fallback, and senders are OIDC-authenticated. A WhatsApp Business Cloud API connector lets a team reply to WhatsApp customers from the same interface. Can CodeB sign PDF documents? Yes. The CodeB Remote Signature Service signs PDFs from a browser or a backend using a Cloud Signature Consortium (CSC) v2 API, producing PAdES-B-T signatures with an RFC 3161 trusted timestamp. The service is Advanced Electronic Signature (AdES) scope with self-signed keys today, not Qualified Electronic Signatures (QES); the design is intended to accept a QSCD connector as a future upgrade. Does CodeB support e-invoicing such as ZUGFeRD and XRechnung? Yes. The Aloaha ZUGFeRDPro SDK creates and reads EN 16931-conformant ZUGFeRD, XRechnung and Factur-X invoices and reads UBL / PEPPOL. The SDK runs on-premise with COM, .NET, command-line and Web Services interfaces, so invoice data never leaves your process. Aloaha positions the SDK for the German 2025-2028 e-invoicing mandate and EU ViDA. How much does CodeB cost? CodeB is free during the preview, with a 30-day no-limits grace period and early-adopter pricing locked in. A free evaluation tenant needs no card, no contract and no auto-billing. Licensing and hosting options are listed on the CodeB pricing page. How do I get started with CodeB? You can request a free live tenant in one of two ways. Path A: point an A record from your own subdomain at the CodeB IP and email Aloaha Limited. Path B: pick a name and Aloaha provisions a subdomain under codeb.io or aloaha.com. Either tenant is live within one business day; you can also try a meeting demo without signing up. How do I contact Aloaha Limited about CodeB? You can use the contact form, email info@aloaha.com, or call the office from the browser with one click over WebRTC during business hours CET. Aloaha Limited replies within one business day. For a Credential Provider evaluation key, add "eval key" to the email subject and a key is sent within 24 hours. =================================================================== # CTIC — Registered EU Digital Identity Wallet Verifier + Six-Pillar Telecoms XaaS for EU Wholesale · Aloaha Limited # Source: https://www.aloaha.com/ctic.html =================================================================== > CTIC by Aloaha Limited: the first production-ready, EU-Reference-Registry-listed Wallet Relying Party for European wholesale telecoms. Six pillars in one binary — EU Digital Identity Wallet verifier + issuer + hosted holder PWA, SIP-over-WebSocket, database-free stack, QES/AdES signatures via EU wallet, EN 16931 e-invoicing, interoperable eForms. Voluntary call-traceability plug-in for the 2027 acceptance mandate. Self-hosted, sovereign, NIS2/DORA/CRA-aligned. ## Six pillars. One deployable stack. The registered EU Digital Identity Wallet verifier, telephony and call-traceability platform for EU wholesale telecoms. CTIC is a self-hosted, six-pillar XaaS platform from Aloaha Limited that gives European wholesale telecoms operators a production-live EU Digital Identity Wallet verifier already listed on the EU Reference Registry ( registry.serviceproviders.eudiw.dev , entity CodeB / Aloaha Limited , VATMT14814406, IDPC Malta supervisory authority), plus a full-stack EUDI Wallet issuer, hosted holder PWA, browser-native SIP-over-WebSocket telephony, a database-free self-hostable stack, QES / AdES digital signatures — including wallet-driven remote signing via CSC v2 — interoperable eForms and EN 16931 XInvoice / XRechnung / ZUGFeRD e-invoicing, in one integrated binary. A voluntary industry-wide call-traceability plug-in rides on top: originating carriers, wholesale interconnects and terminating retailers attach a chain-of-trust attestation to every call, sovereign and eIDAS-native. CTIC is Aloaha Limited’s global innovation beacon for the EU telecoms sector. eIDAS 2.0 applies to the entire European Economic Area — 30 countries in total. The 27 EU Member States must offer at least one certified wallet by December 2026 and accept it at regulated touchpoints including SIM registration, eSIM activation, number portability and B2B onboarding; Norway, Iceland and Liechtenstein follow with roughly one additional year of lag. CTIC is one of the very first EU-shipped EUDI Wallet verifiers delivered as-a-Service to be registered on the EU Reference Registry today , and among the first production-ready platforms to pair that verifier with a voluntary call-traceability plug-in for the wholesale-to-retail chain. The screenshot below is the actual success screen from the EU Reference Wallet after a live PID (SD-JWT VC) presentation to this platform on 2026-08-09. Live proof, captured 2026-08-09. The EU Reference Wallet showing a successful PID presentation to this platform — verified badge next to CodeB / Aloaha Limited . The verified badge is drawn by the wallet from the tradeName + registry-issued signing certificate the EU Reference Registry holds against our WRP entry. Verify the entry live → Sovereign SBC SIPS / RFC 5630 E-Invoicing SDK Full feature list REST + webhook APIs Get your own tenant For wholesale · not for end users ### Built for the buyers who sit between the platform and the retail subscriber. CTIC is a wholesale-shaped, six-pillar XaaS deployment. It targets organisations that resell connectivity, identity and voice services to downstream partners — MVNOs, MVNEs, eSIM brands and national carriers included — and are directly exposed to the 2027 EU Digital Identity Wallet acceptance obligations at the moment a subscriber is onboarded, activated or ported. CTIC is a self-hosted, six-pillar XaaS platform for wholesale telecoms. The four 2027 touchpoints where CTIC replaces manual KYC and paper-based flows: SIM registration , eSIM activation , number portability and B2B account onboarding . Each is a regulated moment. Each currently costs the wholesale operator hours of manual verification per subscriber, per port, per new corporate account. CTIC turns each into a wallet-presentation flow that completes in seconds, with a signed, tamper-evident verification receipt kept in the operator's own filesystem. The first-mover position ### Among the very first EU-shipped EU Digital Identity Wallet verifiers delivered as-a-Service. CTIC is production-ready and among the first EU-shipped EUDI Wallet verifiers delivered as-a-Service. It ships six market-first pillars in one integrated binary: an EU Digital Identity Wallet verifier that speaks the OpenID for Verifiable Presentations profile and accepts SD-JWT Verifiable Credentials over the high-assurance interoperability profile (HAIP), browser-native SIP-over-WebSocket telephony, a database-free self-hostable runtime, eIDAS QES-sealed signatures, interoperable eForms and EN 16931-aligned XInvoice / XRechnung / ZUGFeRD e-invoicing — delivered as installable software the operator runs itself. The 2027 acceptance mandate is not a suggestion. It is a hard obligation on any organisation whose customer-onboarding flow triggers the eIDAS 2.0 acceptance requirement. Wholesale telecoms operators sit at every one of those triggers. The organisations that deploy a wallet verifier before the deadline capture two things: procurement leverage against retail partners still scrambling for a verifier of their own, and a regulatory-alignment story that lands with national regulators, ministries and enterprise procurement. Shipped in the last 90 days · production-live · last update 2026-08-10 ### The verifier is now a registered, EU-listed EU Digital Identity Wallet platform. The six pillars anchor CTIC. Since the wholesale rollout began, the platform has extended the identity pillar into a full self-hosted EU Digital Identity Wallet stack — registered Wallet Relying Party on the EU Reference Registry , EJBCA-issued wrp.p12 JAR-signing certificate, JAdES-B intended-use attestation, verifier + issuer + hosted holder PWA, LOTL-anchored trust chain, OpenID Federation 1.0, W3C Bitstring Status List, W3C VCDM 2.0 (JOSE envelope), four DID methods, Wallet Instance Attestation, cross-tenant trust federation, EU-Ref-CA autofetch and per-check attestation reports — and hardened the telephony and communications pillars around it. Everything below is deployed and reachable on Aloaha Limited's production tenants today ( phone.codeb.io , phone.aloaha.com ). Fifteen chips visualise ninety days of shipments — the newest row (mDoc / ISO 18013-5 primitives, OID4VP QR camera scanner, OID4VCI authorization_code + PAR + PKCE) landed on 2026-07-20; between then and 2026-08-10 the platform also gained an EU-Registry entry, a registry-issued wrp.p12 , LOTL trust-chain enforcement, the CSC v2 remote signature service and the Cross-tenant Trust Federation shortcut listed below. Amber chips extend the EU Digital Identity Wallet pillar; blue chips harden the telephony and communications pillars. Diagram viewBox 800x264 scales to 380px mobile. Between 2026-07-21 and 2026-08-10 — twenty days of additional identity + signing wins: - Registered Wallet Relying Party on the EU Reference Registry at registry.serviceproviders.eudiw.dev/wrp . Entity: CodeB / Aloaha Limited, VATMT14814406, IDPC Malta supervisory authority. Public proof + peer-list on /eudi-registration.html . - EJBCA-issued wrp.p12 JAR-signing certificate installed; every OID4VP authorization request JAR is signed with the registry-issued key, not a self-signed placeholder. Wallet-side chain-walk against LOTL passes. - JAdES-B intended-use attestation embedded in every JAR per ETSI TS 119 182-1 with the WIA EUDI extensions. - EU-Ref-CA autofetch + LocalMachine\Root install so tenants pick up the EU dev-CA chain on first boot with no operator step. - PID VCT triplet in DCQL — urn:eudi:pid:1 + urn:eu.europa.ec.eudi:pid:1 + eu.europa.ec.eudi.pid.1 — so every EU PID vintage in the wild satisfies the query. - /.well-known/eudi-relying-party.json per RFC 8615 published for wallet-side discovery; multi-format providesAttestations block with real ARF entitlement URIs. - CSC v2 Remote Signature Service (RSSP) MVP : info , credentials/list , credentials/info , credentials/authorize (SCAL1 + SCAL2), signatures/signHash , signatures/signDoc (PAdES-B-B / B-T / B-LT / B-LTA), signatures/timestamp , signatures/tsa (issuer), OCSP responder. Pluggable ICryptoModule for soft-key today, HSM tomorrow. - W3C Bitstring Status List v1.0 alongside OAuth Status List for credential revocation. - W3C VCDM 2.0 (JOSE envelope) issuer + verifier alongside SD-JWT VC and mDoc. - Four DID methods — did:key , did:web , did:jwk , did:webvh — resolver + emitter. - Wallet Instance Attestation (WIA) / Wallet Unit Attestation (WUA) per HAIP interoperability profile. - Cross-tenant Trust Federation — tenant A’s VCs are verifiable by tenant B without HTTPS round-trip when both live on the same host. - EU Trusted List publishing per ETSI TS 119 602 / 612 / 615 at /.well-known/trust-list.xml ; XMLDSig ECDSA signed. - OpenID Federation 1.0 discovery at /.well-known/openid-federation (ES256 entity statement). - Per-check HAIP attestation reports on the verifier — JAR ok, x5c chain-walk, DCQL match, nonce echo, JWE decrypt, KB-JWT verify, disclosures match, aud match — each returned explicitly rather than inferred, screenshot-able for RFP responses. - Live EU-issuer status ping + operator-visible EU sandbox status banner across all wallet flows — users no longer chase our-side ghosts during EU sandbox outages. - EUDIW registration flow — a one-click 14-step operator page ( /eudiw-register.html ) walks the entire EU Reference Registry tree end-to-end with per-step wire capture and debug panel. - DPIA (Article 35) + RoPA (Article 30) templates published in EN + DE with per-tenant admin editor at /compliance-admin.html . Zero third-party JavaScript libraries in the wallet. Eight in-house modules totalling roughly 137 kB minified deliver the full EU Digital Identity Wallet holder experience — SD-JWT VC, mDoc / ISO 18013-5, CBOR, COSE, OpenID4VCI, OpenID4VP, QR camera scanner and visual credential renderer. No npm install , no CDN fetch, no transitive dependency graph. Every byte the browser loads is written by Aloaha Limited . - Wallet Attestation endpoint (HAIP interoperability profile). Wallet-instance attestations issued and validated on the operator's own tenant, so downstream relying parties see a full chain of trust from wallet instance through verifier to their own trust store. - OpenID4VCI issuer. The same platform that verifies presentations now issues Verifiable Credentials over the pre-authorized_code flow, with a per-tenant admin UI for defining credential types, key rotation and revocation. - Hosted holder wallet PWA. A self-hostable, installable Progressive Web App that lets operators offer their own subscribers a wallet without waiting for national scheme apps. Zero-knowledge backup between devices via the operator's own OIDC store. - OpenID Federation 1.0 discovery. Wallets and other relying parties can discover the operator's trust anchor at /.well-known/openid-federation , ready for the incoming federation-based EU trust model. - List-of-Trusted-Lists poller. Continuously refreshes the EU trust list and validates x5c chains presented at the verifier, so no manual trust-store rotation is required. - Per-tenant EU Wallet audit log. Every wallet presentation is written to a per-tenant, greppable audit trail; the tenant's CISO and DPO have full auditability over identity flows without leaving the operator's own filesystem. - Public verifier conformance test. A third party can point their wallet at the operator's verifier and inspect the presentation exchange end-to-end — useful for RFP responses, procurement diligence and downstream retail-partner reassurance. - Per-trunk SDES SRTP. RFC 4568 SDES SRTP is available per-trunk across every bridge in the SBC, so signalling and media stay encrypted regardless of the interconnect partner's posture. - ACL v3 with hot-reload and auto-blacklist. Signalling scanners at well-known OVH and other hosting ranges are auto-blocked on startup; per-tenant allow-lists reload without a service restart. - Multi-tenant chat platform with drop-in widget. Direct messages, groups and file transfers between tenant users, plus a per-tenant visitor widget that lets a wholesale operator embed one line of script on their own retail-portal. - Stereo per-trunk call recording and transcription. Per-trunk and per-virtual-number toggle. Recordings are stereo PCM16 WAV; transcripts flow into the per-tenant audit trail with sharable links the operator controls. - Growing mDoc / ISO 18013-5 pipeline. CBOR, COSE_Sign1 and mDoc primitives are in the codebase today — end-to-end mDoc issuance and presentation is progressing through the same production tenants that already run the verifier. Next up · wallet-driven remote signing · scoped, dated, on-schedule ### Two tracks to complete wallet-driven remote signing on top of the CSC v2 RSSP. The Cloud Signature Consortium v2 REST surface shipped in the last sprint (see the milestone list above). Two additional tracks complete the wallet-driven remote signing story so a subscriber can scan a QR in a browser and sign a PDF with their EU Digital Identity Wallet against this platform. Both tracks are scoped, reference-repo-aligned and behind honesty-gated feature flags (see the EU RQES reference library ). #### Track 1 · QR-scan RP flow (wallet-centric, ~5 dev days) Subscriber loads Sign with your EU Wallet , uploads a PDF, scans a QR from the browser. The wallet uses its OWN QTSP (e.g. walletcentric.signer.eudiw.dev ) to produce the signature, then POSTs the signed PAdES back to our oidc.ashx?action=vp-response . Reuses ~75% of the OID4VP verifier already in production — JAR signing via wrp.p12 , request_uri storage, response_uri receiver, same-device cookie binding, session poll. Wire format: DCQL with credentials[].format = https://cloudsignatureconsortium.org/2025/x509 plus base64url transaction_data[] of type https://cloudsignatureconsortium.org/2025/qes per the EUDI RQES Kotlin reference. Zero dependency on our own QTSP. #### Track 2 · CSC v2 wallet-driven RSSP (QTSP-centric, ~10 dev days) Our tenant IS the QTSP. The EU Reference Wallet's RQES UI SDK drives our csc.ashx directly: OID4VP-driven service auth, second OID4VP round per signing (SAD implicit in Bearer), signHash, and a small SCA sidecar ( calculate_hash + obtain_signed_doc ) wrapping the existing PadesInlineSigner.cs . Deep-link redirect URIs ( wallet:// , rqes:// ) and PKCE S256 enforced. Revenue model: per-signature meter ( vc.sign.qes ) counted the same way as vc.login.eudi . Slice A/B/C/D shippable independently; the full track completes eIDAS Advanced Electronic Signature (AdES) via wallet with a documented upgrade path to Qualified Electronic Signature (QES) once a QTSP-issued signing key is onboarded. Both tracks are scoped and filed against the platform’s live TODO list. See the canonical wallet-driven rQES specification for wire-level detail. Honesty note: the spec is explicitly flagged pre-release, still work in progress at both the EUDI Kotlin library and the German BSI Blueprint — we ship each track behind a per-tenant feature flag so wire churn during the 2026 ARF Refinement Round doesn’t destabilise production. ARF 3.0.0 · released ~late July 2026 · three-layer RP + two-cert + Intermediary role ### ARF 3.0.0 fit — and the Intermediary opportunity CTIC is already shaped for. The European Commission published Architecture and Reference Framework (ARF) 3.0.0 at the end of July 2026. It is the biggest ecosystem change since the 2024 launch: every Relying Party is now decomposed into three formal layers, every service ships with two complementary certificates, and a new Intermediary role lets one party carry the registration and certificate lifecycle for many downstream Relying Parties. CTIC is already the right shape for all three shifts. What follows is an honest split of what we ship today, what maps to the new model, and what we are formally adding. The ARF 3.0.0 three-layer Relying Party structure. One legal entity may run multiple RP Instances (datacentres, DR sites, tenants). Each Instance exposes one or more Services, each with its own Registration Certificate declaring the exact Intended Use the wallet will let the user share. The wallet now shows the SERVICE name, not just the org name, on its consent screen. #### What we ship today that already maps - wrp.p12 (EU-Registry-issued via EJBCA) acts as the Access Certificate at the RP Instance layer. - intended-use.jades (JAdES-B with the WIA EUDI extensions per ETSI TS 119 182-1) is the anchor for the ARF 3.0.0 Intended Use concept. - Service-shaped DCQL builders already exist — BuildEudiLoginQuery , BuildAloahaIdentityQuery , and BuildAloahaAgeQuery . Each maps 1:1 to a distinct RP Service in the ARF 3.0.0 sense. - Per-tenant registration flow (14-step tree walker at eudiw-register.ashx ) can be extended to loop-register multiple services under one legal entity. #### What is being added for full ARF 3.0.0 conformance - Per-service Registration Certificates under EU Regulation 2024/2982. New ?action=register-rc flow that mints one RC per RP Service, cryptographically bound to the Access Certificate and the service’s Intended Use list. - Multi-service intended-use JAdES emission so each service ships its own JAdES token alongside the tenant-wide baseline during the transition. - Public verifier metadata refresh — /.well-known/eudi-relying-party.json gains a services array with per-service RC references. - eudi-registration.html public proof extends to show BOTH cert chains per service — AC (who) and RC (what) — with expiry, thumbprint and Intended Use for each. #### The Intermediary opportunity — CTIC as managed compliance for SMEs. ARF 3.0.0 formalises the Intermediary role : a special Relying Party that acts on behalf of one or more other Relying Parties, handling Wallet communication without ever storing the content of the transactions it forwards. Not every organisation wants to run its own EU Reference Registry registration, its own EJBCA-issued wrp.p12 lifecycle, its own per-service RC minting and renewals, its own JAdES-B intended-use signer, its own LOTL trust chain check. Most European SMEs — medical practices, MVNOs, hospitality operators, notaries, insurance brokers, retail chains — will not build any of that in-house. This is exactly the compliance-overhead-into-recurring-revenue shape CTIC has been architected for. CodeB positioned as an ARF 3.0.0 Intermediary. One registration surface to the EU Reference Registry; per-downstream-RP AC + RC issuance and renewal handled by CodeB; the end user still sees only the downstream RP’s name on the wallet consent screen, with Intermediary involvement recorded in the wallet audit log per ARF 3.0.0 traceability rules. This is the missing managed-service layer the SME market has been waiting for. - Formal mandate flow. Each downstream Relying Party signs a mandate authorising CodeB to act on its behalf; mandate captured via the existing European Business Wallet director-signed workflow. The Registrar verifies the mandate before issuing the RC. - Per-tenant Intermediary mode. A single intermediary=true flag on the tenant switches eudiw-register.ashx from RP mode to Intermediary mode. Same pipeline, same certificates, different registration frame. - Downstream RP visibility, not Intermediary visibility. The wallet consent screen shows the downstream RP’s tradeName + verified badge, not CodeB’s. Intermediary involvement is captured in wallet audit logs per the ARF 3.0.0 traceability requirement — useful for compliance, invisible to the user. - Metered like everything else. Per-downstream-RP and per-Service meters on the same clientRef plumbing already used for wallet verifications, CSC v2 signHash calls, call minutes and AI tokens (see the wholesale distribution section below). - Legal template. An ARF 3.0.0 Intermediary Mandate Template ships alongside the existing DPIA + RoPA templates — per-tenant configurable via compliance-admin.html . Positioning note. The three-layer RP structure, the two-certificate model, and the Intermediary role are new formal concepts — the underlying capabilities they organise (AC-style tenant cert, service-scoped attribute lists, third-party managed compliance) have been shipped in CTIC for months. What ARF 3.0.0 gives us is a common vocabulary to describe an offer the SME market has been asking for and no other EU-sovereign vendor is yet positioned to deliver at price. Sales language: “Compliance is a moat when you don’t have to build it yourself.” Architecture ### One deployable stack. Six load-bearing pillars. CTIC is not a suite of separately-licensed products bolted together. It is one integrated binary that presents six pillars to the operator, each labelled with the exact standard it implements. Every pillar is switchable on or off per tenant, per trunk, per user — so a wholesale operator can start with just the EU Digital Identity Wallet verifier and extend into telephony, signatures, eForms and e-invoicing as their retail programme grows. CTIC is a self-hosted, six-pillar XaaS platform for wholesale telecoms. CTIC platform architecture — six pillars, one deployable stack. On mobile the two-by-three grid reflows vertically at the same aspect ratio; the SVG viewBox scales fluidly with the container down to 380px widths. Wholesale distribution ### Multi-tier tenancy that keeps every customer relationship end-to-end. CTIC is wholesale-shaped at the tenancy layer. Aloaha bills the platform tenant. The platform tenant bills its distributor tenants. Each distributor bills its reseller tenants. Each reseller bills the end-customer. Every event carries a clientRef slot so revenue is attributable at any tier — and every tenant owns its own subscriber list, call detail records, recordings and transcripts inside its own domain, end-to-end. Each tenant is an independent per-domain partition on disk. Every subscriber list, CDR, transcript and recording stays inside its own tenant boundary, owned end-to-end by whichever party in the wholesale-to-retail chain the data belongs to. Diagram remains legible at 380px mobile widths thanks to the responsive viewBox. Voluntary call-traceability plug-in · sovereign, eIDAS-native ### A voluntary plug-in that aligns wholesale and retail telecoms against unidentifiable-call fraud. CTIC offers global mobile operators, MVNOs, eSIM brands, telecom retailers and their wholesale peers a voluntary plug-in solution to the long-standing traceability problem for unidentifiable calls. Because the same platform runs the EU Digital Identity Wallet verifier, per-trunk SIP-over-TLS, per-trunk SDES SRTP, per-tenant OIDC identity and RFC 4028 Session-Timer, it can attach a chain-of-trust from originating carrier through interconnect to terminating retailer — voluntarily, without waiting for a regulator to mandate it. The six-pillar delivery makes it operationally cheap to adopt: no separate KYC vendor, no separate signalling-protection vendor, no separate identity IdP. This is the missing piece the wholesale-to-retail chain has been waiting for. The plug-in is designed as the sovereign, eIDAS-native alternative to the US regulatory-driven approach. It attaches a signed attestation at each hop — originating carrier, interconnect, terminating retailer — so the terminating operator and, ultimately, the retail subscriber can see the verified origin of the call. Because CTIC already terminates SIPS, mints per-tenant certificates and issues QES-sealed signatures across the same tenant boundary, no new vendor is needed. Any operator can opt in on their own timeline, and the chain-of-trust flows through only the CTIC-enabled hops. CTIC-attested chain-of-trust across originating carrier, wholesale interconnect and terminating retailer. Each CTIC-enabled hop attaches a signed attestation the terminating retailer and the verified end-user can inspect. Diagram viewBox 800x260 scales fluidly to 380px mobile. - Voluntary industry-wide plug-in. Not a regulatory mandate. Any operator, MVNO, eSIM brand, wholesale distributor or retail carrier can opt in on their own timeline — the chain flows through only the CTIC-enabled hops. - Sovereign, eIDAS-native. Built on eIDAS 2.0 primitives — EU Digital Identity Wallet presentations, QES signatures, per-tenant certificates. No dependency on non-EU regulatory frameworks or non-EU trust anchors. - Attach the attestation without adding vendors. The six pillars are already in the box: no separate KYC vendor, no separate signalling-protection vendor, no separate IdP. The plug-in reuses what CTIC already ships. - Wholesale-to-retail chain-of-trust. The attestation attaches at originating carrier, wholesale interconnect and terminating retailer, so the retail subscriber ultimately sees a verified origin for their inbound call. - Aligns wholesale and retail incentives. Wholesale interconnects that opt in get a differentiator; retail carriers that opt in reduce fraud losses on unidentifiable calls; end subscribers get an inspectable proof. The 2027 acceptance mandate · four wholesale touchpoints ### Where CTIC turns each regulated moment into a wallet flow. Each of the four touchpoints below is a moment where an EU Member State regulator will, from 2027, expect the wholesale operator to accept an EU Digital Identity Wallet presentation as a valid identity assertion. The flow is the same shape in each case: the subscriber presents from their wallet, CTIC's verifier validates cryptographically, and the operator activates or ports. ##### SIM registration Retail SIM sale by a distributor or MVNE. Wallet presentation replaces paper-based ID capture and manual KYC. Verification receipt stored in the reseller tenant's partition. ##### eSIM activation Travel-eSIM and consumer-eSIM aggregators face the highest onboarding volume in the sector. Wallet-first onboarding eliminates the SMS-OTP fallback that keeps failing across roaming boundaries. ##### Number portability Number-portability fraud costs European carriers hundreds of millions annually. A wallet-presented port authorisation carries cryptographic non-repudiation the losing carrier can inspect. ##### B2B account onboarding Corporate customer onboarding: legal-entity credentials plus signatory authorisation, both wallet-issued. The signed presentation is the contract prerequisite. Capability breadth ### Everything the wholesale operator needs in one stack. CTIC's XaaS breadth is deliberately unusual for the category. A typical wholesale procurement bundles a verifier from one vendor, an SBC from another, a CPaaS from a third, an e-invoicing SDK from a fourth and a metering system from a fifth. CTIC ships all of the following out of one install. #### EU Digital Identity Wallet verifier OID4VP + HAIP + SD-JWT VC. x509_hash (mandated by HAIP 1.0 Final) and x509_san_dns (additional OpenID4VP compatibility mode) client-identification schemes. Production-shipped. Cited in ministerial correspondence. #### Sovereign SBC Multi-tenant SIP border with per-trunk TLS, per-trunk SRTP via SDES, ICE-Lite for STUN-less hardphones, per-source-IP auto-blacklist. #### SIP-over-WebSocket Browser-native RFC 7118 endpoint. WSS transport terminated at the SBC. Sits alongside UDP/TLS listeners without rearchitecting routing. #### SIP-over-TLS (SIPS) RFC 5630 SIPS on TCP 5061/6061, per-tenant certificates by SNI, ACL and auto-blacklist shared with the WebRTC surface. #### WebRTC SFU Selective forwarding unit for meetings beyond mesh peer count. Composite trigger on bandwidth and participant count. Client preference honoured. #### Programmable AI voice Receptionist, outbound caller and transcription. Per-virtual-number prompts. Bring-your-own AI provider key. Per-trunk transcription tap. #### E-invoicing SDK ZUGFeRD, XRechnung, Factur-X. Reads UBL, writes CII per EN 16931. On-premise library; no cloud round-trip for invoice generation. #### Chat with embed widget Real-time chat plus a drop-in visitor widget. Per-tenant origin allow-list is the trust boundary; no OIDC required from the visitor. #### Per-trunk recording & transcription Stereo PCM16 WAV per call, admin UI, retention policy, fan-out to matched tenants. Transcript emission is a per-trunk toggle. #### Wholesale-billable metering Every event carries clientRef . Counted entitlements plus consumable budgets. LicenseGate stub is Allowed-true until deals close. #### Standards compliance readiness NIS2 · DORA · eIDAS 2.0 · EU Cyber Resilience Act · EU AI Act · GDPR Art. 32. Documented alignment across each layer. #### Wallet Attestation HAIP interoperability profile. Attestations issued and validated on-tenant so relying parties see a signed chain from wallet instance through verifier to trust store. #### OpenID4VCI issuer Same tenant that verifies presentations now issues credentials via the pre-authorized_code flow. Per-tenant admin UI for credential types, key rotation and revocation. #### Hosted wallet PWA Installable Progressive Web App the operator hosts for its own subscribers. Zero-knowledge cross-device backup via the operator's own OIDC store. #### Trust-list poller Continuous EU List-of-Trusted-Lists refresh with x5c chain validation at the verifier. No manual trust-store rotation. #### Per-tenant EU Wallet audit Every VP presentation lands in a greppable per-tenant audit trail. CSV export. Full auditability without data ever leaving the operator's filesystem. #### OpenID Federation 1.0 Wallets and relying parties discover the operator's trust anchor at /.well-known/openid-federation . Ready for the incoming federation-based EU trust model. #### Multi-tenant chat platform Direct messages, groups, file transfers between tenant users, plus a per-tenant visitor widget the operator embeds on its retail portal with one line of script. #### Public conformance test Third parties can point their wallet at the operator's verifier and inspect the presentation exchange end-to-end — RFP-ready, procurement-inspectable. #### Filesystem storage No SQL, no NoSQL, no embedded database. NTFS atomic writes with .backup shadow. Per-tenant partition. DR is a folder copy. Sovereignty · no middleman ### Self-hosted. No national-identity-cloud in the loop. DR is a folder copy. A wholesale telecoms buyer's regulatory exposure is directly proportional to the number of vendors sitting between their subscriber and the identity-assertion outcome. CTIC removes middlemen from that chain. - Self-hosted on operator infrastructure. Deploy inside the operator's own datacentre, a sovereign-cloud region or a colocation cabinet. No Aloaha-side data plane. No mandatory outbound telemetry. - No national-identity-cloud middleman. The wallet verifier speaks directly to the presenter and the operator's own trust store. The operator does not route identity presentations through an intermediary hosted-verifier service. - Filesystem-only state. Every setting, every credential store, every recording, every transcript, every CDR is a file on disk in a per-tenant directory. No SQL server dependency. No database patch window. - Disaster recovery is a folder copy. Snapshot the tenant directory, ship it to a warm-standby node, start the process. No schema migration. No point-in-time restore ceremony. - No hyperscaler tie-in. The stack runs on .NET Framework 4.8 on any Windows Server. Cert issuance uses public ACME. Storage is native NTFS. Nothing forces the operator into a specific cloud provider. - Explicit DPO/CISO-friendly logging. Every trust decision leaves a greppable INF-level log line at entry, branch, pre-call and post-call. Auditable by human inspection alone. Head-to-head ### CTIC vs the largest CPaaS incumbents. The largest hyperscaler-tied CPaaS incumbents were built for retail-app-developer distribution, not European wholesale telecoms procurement. The wholesale buyer's requirement set diverges from that model across the six pillars CTIC ships in one binary — and across the voluntary call-traceability plug-in that rides on top of them. Capability | CTIC (Aloaha) | Largest CPaaS incumbents EU Digital Identity Wallet verifier | Shipped, live | Not offered Browser-native SIP endpoint (RFC 7118) | Yes, WSS listener | Proprietary SDK only Database dependency | None — filesystem | Cloud database required Hosting model | Self-hosted on-prem or sovereign cloud | Vendor cloud only Wholesale-billable (clientRef on every event) | Yes, by design | Partner programme, not native Tenant isolation model | Per-domain partition on disk | Logical tenants in shared DB EU sovereignty / no US-CLOUD-Act exposure | EU-only if operator chooses | US parent, US-CLOUD-Act reachable Time to market against 2027 EUDI deadline | Weeks, verifier ships today | Vendor-dependent ZUGFeRD / XRechnung e-invoicing SDK | Included | Not offered Per-trunk call recording + transcription | Native, per-trunk toggle | Add-on service, extra billing Voluntary call-traceability plug-in (eIDAS-native) | Included in the six pillars | Not offered QES-sealed signatures (eIDAS QES) | Native pillar | Third-party integration Interoperable eForms | Native pillar | Not offered "Largest CPaaS incumbents" reflects the current public-market positioning of the top-tier CPaaS vendors in 2026. CTIC does not name any competitor by brand. Deploy in weeks, not quarters ### Two timelines. One EU 2027 deadline. The 2027 EU Digital Identity Wallet acceptance mandate is a hard, dated obligation. The operators who deploy against it early clear procurement conversations with retail partners; the ones who wait for their hyperscaler-tied CPaaS vendor to catch up will be scrambling in the last quarter of 2026. Two timelines against the 2027 deadline. On mobile the SVG scales down while preserving both timeline tracks — the deadline anchor stays visible at 380px widths. Frequently asked by wholesale procurement ### The eight questions wholesale buyers ask first. How does CTIC help telecoms fight unidentifiable-call fraud? CTIC ships a voluntary, industry-wide call-traceability plug-in that rides on top of its six pillars: the EU Digital Identity Wallet verifier, browser-native SIP-over-WebSocket telephony, the database-free self-hostable stack, QES-sealed signatures, interoperable eForms and XInvoice / XRechnung / ZUGFeRD e-invoicing. Because the same platform terminates per-trunk SIP-over-TLS, per-trunk SDES SRTP, per-tenant OIDC and RFC 4028 Session-Timer under one tenant boundary, it can attach a signed chain-of-trust attestation at each hop — originating carrier, wholesale interconnect, terminating retailer — so the terminating operator and the retail subscriber see a verified origin for the call. The plug-in is sovereign and eIDAS-native: it works without a regulatory mandate, without a separate KYC vendor, and without a separate signalling-protection vendor. This is the missing piece the wholesale-to-retail chain has been waiting for, and it lets any operator, MVNO, eSIM brand or retail carrier opt in on their own timeline. What are the six pillars of CTIC? CTIC ships six load-bearing pillars in one integrated binary: (1) EU Digital Identity Wallet verifier as-a-Service (eIDAS 2.0, OID4VP, HAIP, SD-JWT VC); (2) Browser-native SIP-over-WebSocket telephony (RFC 7118, RFC 5630 SIPS, RFC 4568 SDES/SRTP, RFC 4028 Session-Timer); (3) Database-free, self-hostable stack (NTFS atomic writes, per-tenant filesystem partition, disaster recovery is a folder copy); (4) QES-sealed digital signatures (eIDAS QES, ink-equivalent legal standing across the EU); (5) Interoperable eForms (structured PDF forms compatible with QES); (6) XInvoice / XRechnung / ZUGFeRD e-invoicing (EN 16931-aligned, Factur-X hybrid PDF, on-premise SDK). Each pillar is switchable per tenant, per trunk, per user. A voluntary call-traceability plug-in rides on top of the six pillars. What is CTIC? CTIC stands for CodeB Telecoms, Identity & Connectivity as-a-Service. It is a production-ready, self-hosted, six-pillar XaaS platform for wholesale telecoms from Aloaha Limited. The six pillars are the EU Digital Identity Wallet verifier, browser-native SIP-over-WebSocket telephony, the database-free self-hostable stack, QES-sealed digital signatures, interoperable eForms and XInvoice / XRechnung / ZUGFeRD e-invoicing. A voluntary call-traceability plug-in rides on top of them. CTIC targets European telecoms wholesale operators — MVNOs, eSIM brands, national carriers, distributors and datacentre operators — who need to satisfy the 2027 EU Digital Identity Wallet acceptance mandate on their own infrastructure. CTIC is Aloaha Limited's global innovation beacon for the EU telecoms sector. Is it EU Digital Identity Wallet ready? Yes. The CTIC EU Digital Identity Wallet verifier is production-shipped today. It implements the OpenID for Verifiable Presentations profile, the high-assurance interoperability profile, SD-JWT Verifiable Credentials, and the x509_hash Client Identifier Prefix mandated by HAIP 1.0 Final, plus the additional x509_san_dns OpenID4VP compatibility mode for legacy wallets. The verifier has been cited in ministerial-level correspondence about EU Digital Identity Wallet readiness. Can we run CTIC in our own datacentre? Yes — self-hosting is the default deployment model. CTIC runs on .NET Framework 4.8 on Windows Server. Storage is native NTFS with atomic File.Replace writes. There is no mandatory Aloaha-side data plane. Operators typically deploy inside their own datacentre, a sovereign-cloud region, or a colocation cabinet. How does wholesale billing work? Every meterable event that CTIC emits — call minutes, wallet verifications, transcription seconds, storage bytes, AI tokens, webhook fires — carries a clientRef attribute. The platform tenant bills its distributor tenants; the distributor bills its resellers; the reseller bills the end-customer. CTIC does not sit between an operator and their customer for billing; it emits the events, the operator reconciles. A LicenseGate stub allows every operation while commercial terms are being finalised, so pilots are never blocked by billing plumbing. What about NIS2 and DORA compliance? CTIC's design maps to the specific technical measures listed in NIS2 Article 21(2) — policies and procedures regarding the use of cryptography and, where appropriate, encryption — and to the DORA operational-resilience requirements for ICT third-party risk. The stack terminates SIP-over-TLS per RFC 5630, offers SRTP via SDES per RFC 4568, mints per-tenant Let's Encrypt certificates, and keeps every audit-relevant event as a greppable INF-level log line. GDPR Article 32, the EU Cyber Resilience Act (EU 2024/2847) and the EU AI Act readiness requirements are addressed at the architecture level and documented on the dedicated cyber-resilience page. What does the 2027 EU Digital Identity Wallet acceptance deadline actually require? The eIDAS 2.0 regulation (EU 2024/1183) obliges Member States to ensure that regulated services accept the European Digital Identity Wallet as a valid means of identification and authentication at the touchpoints covered by the acceptance mandate. For wholesale telecoms, this means the operator must be able to accept an EU Digital Identity Wallet presentation at SIM registration, eSIM activation, number portability and B2B account onboarding. The obligation lands during 2027 following the Member-State transposition schedule. Operators without a working verifier at that point face procurement pressure from their retail partners and, in several jurisdictions, direct regulatory attention. How is CTIC different from hyperscaler CPaaS? The largest CPaaS incumbents were designed for retail-app-developer distribution: their unit of sale is an SDK the developer embeds in a consumer application, and their operating model requires a hyperscaler-hosted control plane. CTIC is designed for wholesale telecoms operators: the unit of sale is a self-hosted deployment the operator runs inside their own datacentre, and the operating model gives every tenant its own domain, its own OIDC realm and its own credential store — full sovereignty end-to-end, distributor to retailer to end customer. The comparison table above lists the eight most load-bearing differences. What does deployment involve? Typical CTIC deployment takes six-to-fourteen weeks end to end. Weeks one to six install the platform on the operator's Windows Server infrastructure and stand up the first tenant. Weeks seven to ten integrate CTIC's REST and webhook surfaces with the operator's CRM, billing and SIM-provisioning systems. Weeks eleven to fourteen pilot with a controlled subset of subscribers and validate the wholesale metering feed. From week fifteen onwards the operator is live, twelve months ahead of the 2027 EU Digital Identity Wallet acceptance mandate. Next step ### Book a wholesale briefing. Ninety minutes with the CodeB team, walking through the architecture at the depth your procurement, network-architecture and general-counsel functions need. Bring your 2027 readiness questions. Leave with a scoped deployment plan and pricing calibrated to your subscriber volume. Sovereign SBC SIPS E-Invoicing SDK All features REST + webhook APIs Get your own tenant Compare =================================================================== # Get your own CodeB tenant · CodeB Sovereign Communications # Source: https://www.aloaha.com/get-your-tenant.html =================================================================== > Get your own CodeB Sovereign Communications tenant. Free during preview. 30-day no-limits grace. Early-adopter pricing locked in when public tiers launch. Self-hosted PBX, AI receptionist, browser meetings, OIDC identity provider and EU Wallet sign-in — on your own subdomain. ## Your own CodeB tenant in 24 hours. A complete sovereign communications stack on your own subdomain. PBX with AI receptionist, browser video meetings, OpenID Connect identity provider, EU Wallet sign-in — all from one install. Free during preview. 30-day no-limits grace period. No card required. Early-adopter pricing locked in when public tiers launch. - Your own subdomain on codeb.io — or bring your own. - Full feature access — meetings, SIP, Voice AI, OIDC IdP, EU Wallet. - Zero quotas for the first 30 days. We’ll send a usage summary before any limits apply. - Aloaha Limited (EU) as your data controller. No US transfer. No third-party telemetry. Request received — thanks! A claim link will arrive at the email you provided, typically within one business day. If you don’t see it within 24 hours, check your spam folder or email info@aloaha.com . ### Not sure yet? Talk to us first. No card. No commitment. Pick whichever channel suits you — a human will reply. ### Frequently asked questions What is a CodeB tenant? A CodeB tenant is a complete sovereign communications stack on your own subdomain. A tenant includes a PBX with AI receptionist, browser video meetings, an OpenID Connect identity provider and EU Wallet sign-in, all from one install. How much does a CodeB tenant cost? A CodeB tenant is free during the preview, and no card is required. Early-adopter pricing is locked in when public tiers launch. How long does it take to get a CodeB tenant? A CodeB tenant is typically set up within 24 hours. After you submit the request form, a claim link arrives at your email address, typically within one business day. If it has not arrived within 24 hours, check your spam folder or email info@aloaha.com. What is the 30-day grace period for a CodeB tenant? For the first 30 days a CodeB tenant has zero quotas and full feature access, including meetings, SIP, Voice AI, the OIDC IdP and EU Wallet. Aloaha sends a usage summary before any limits apply. Can I use my own domain for a CodeB tenant? Yes. A CodeB tenant starts on your own subdomain such as your-name.codeb.io, and you can switch to your own domain later. Who is the data controller for a CodeB tenant? Aloaha Limited, an EU company, is the data controller for a hosted CodeB tenant. There is no US transfer and no third-party telemetry. What do I need to request a CodeB tenant? To request a CodeB tenant you enter your name, an email address you can reach and a desired subdomain made of lowercase letters, numbers and dashes. A display name and a line on what you will use it for are optional and help prepare a sensible default setup. Can I talk to someone before requesting a CodeB tenant? Yes. You can email info@aloaha.com, send a question through the one-page contact form or call the office from your browser. A human replies, typically within one business day, and there is no card and no commitment. =================================================================== # CodeB Identity vs Okta, Auth0, Microsoft Entra ID, Keycloak · Sovereign IdP comparison # Source: https://www.aloaha.com/idp-comparison.html =================================================================== > Honest feature matrix comparing CodeB Identity (sovereign, self-hosted on IIS, EU Wallet ready) against Okta, Auth0, Microsoft Entra ID, and Keycloak. Includes pricing, deployment model, and which RFCs each one implements. Sovereign Identity ## CodeB Identity vs Okta, Auth0, Entra ID, Keycloak An honest, no-marketing-spin feature matrix. We tell you where we win, where we tie, and where the competition is still ahead. Every row is a verifiable RFC reference or a public docs link — no flag-planting. ### Feature matrix Verified 2026-06-11 against vendor public documentation. Empty cells are not implementations of any feature — they mean the row doesn’t apply. Feature | CodeB Identity | Okta | Auth0 | Entra ID | Keycloak Deployment & sovereignty Self-hosted on your IIS box No Java, no Docker, no container orchestration required. | Yes | No SaaS only | No SaaS only (Auth0 Private Cloud is hosted by Okta) | No Microsoft cloud only | Self-host JVM / WildFly Sovereign data — user records never leave your premises | Yes | No | No | No | Yes EU Cyber Resilience Act (Reg 2024/2847) compatible On-prem deployment removes vendor-managed-data complications. | Yes | Depends | Depends | Depends | Yes Standards compliance OpenID Connect (Core 1.0) Authorization Code + PKCE, RS256 ID token. | Yes | Yes | Yes | Yes | Yes RP-Initiated Logout 1.0 | Yes | Yes | Yes | Yes | Yes RFC 7662 token introspection | Yes | Yes | Yes | Yes | Yes RFC 7009 token revocation | Yes | Yes | Yes | Yes | Yes RFC 7523 JWT-bearer grant | Yes | Yes | Yes | Yes | Yes RFC 6749 OAuth 2.0 framework Authorization Code + PKCE; refresh tokens; client_credentials for confidential apps. | Yes | Yes | Yes | Yes | Yes RFC 7636 PKCE (S256) Required on every public client. Codes carry the hashed verifier. | Yes | Yes | Yes | Yes | Yes RFC 8414 Authorization Server Metadata /.well-known/openid-configuration + /.well-known/jwks.json . | Yes | Yes | Yes | Yes | Yes RFC 8176 amr values in tokens We emit amr: ["pwd"] / ["hwk","user"] / ["user"] per factor; RPs can require step-up. | Yes | Yes | Yes | Yes | Yes RFC 9068 JWT Profile for OAuth 2.0 Access Tokens Access tokens are RS256-signed JWTs with iss , sub , aud , scope , client_id . | Yes | Yes | Yes | Yes | Yes RFC 9101 JAR — JWT-Secured Authorization Request Used on the EU Wallet Verifier vp-request endpoint: ES256-signed JAR with x5c chain. | Yes | Yes | Yes | Yes | Yes Sign-in methods Username + password (HA1, never sees plaintext) | Yes | Yes | Yes | Yes | Yes Passkeys / FIDO2 / WebAuthn | Yes Per-tenant RP ID, COSE public key, counter-regression check, attestation=none. | Yes | Yes | Yes | Yes Magic-link sign-in (passwordless email) | Yes Shipped 2026-06-11. 15-min TTL, single-use JTI, no-enumeration envelope. | Yes | Yes | Yes | Yes EU Digital Identity Wallet (EUDI) sign-in OID4VP 1.0, HAIP 1.0, SD-JWT VC, both x509_hash + x509_san_dns Client Identifier Prefixes. | Yes | No Not yet generally available | No Not yet generally available | Preview EU Wallet preview programme | Plug-in Community plug-ins; no first-party Self-service password reset | Yes No-enumeration envelope, single-use JTI, browser-side HA1. | Yes | Yes | Yes | Yes Authenticator app (TOTP, RFC 6238) 6-digit, 30-second window, ±1 step tolerance. Per-tenant encrypted secret, single-use recovery codes, audit-logged. Email fallback for users who lose their device. Admin one-click reset in /register.html for the lost-everything case (audit-logged with both admin and target). Per-session brute-force lockout: 5 wrong codes kills the session. Enrolment in /account.html . | Yes | Yes | Yes | Yes | Yes Wallet-as-password-recovery RFC 7523 JWT-bearer grant with acr=eudi-wallet : sign in once with the wallet, the wallet IS the password-reset proof. No email loop. | Yes | No | No | No | No Per-request Client Identifier Prefix selection x509_hash + x509_san_dns chooseable per-request via query param. Pinned defaults per relying party while wallets converge. | Yes | No | No | No | No Three-method picker on one screen Password + passkey + EU Wallet equal-weight on /login.html . Magic-link email sign-in one click below. Relying parties deep-link with ?method= . No third login URL for end users to remember. | Yes | No | No | No | No Operations & ergonomics Per-tenant signing keys, hot rotation (no service restart) private-key.xml → private-key-previous.xml ; JWKS publishes both during overlap. | Yes | Yes | Yes | Yes | Yes Multi-tenant by domain (one IIS site per tenant, shared codebase) | Yes | Yes Hosted multi-tenant | Yes Hosted multi-tenant | Yes Hosted multi-tenant | Yes Realms Admin UI shipped with the product | Yes | Yes | Yes | Yes | Yes Audit logs UI | Yes Per-tenant browser UI — event / user / since filters, color-coded rows, tail-mode auto-refresh, CSV export. App_Data//logs/ remains the source of truth. | Yes | Yes | Yes | Yes Bundled with WebRTC meetings, SIP phone bridge, Voice AI, Outbound AI campaigns | Yes Same product, same admin, same per-tenant config. | No | No | Teams Only via separate Microsoft 365 subscription | No Single-process identity + comms One Windows process owns the OIDC IdP, the WebRTC signalling, the SIP bridge, the Voice AI -- no cross-process auth dance. | Yes | No | No | No | No EU jurisdiction Made in Malta. GDPR, NIS2, DORA, EU Cyber Resilience Act (Reg 2024/2847), eIDAS 2.0 aligned natively. No transatlantic data-residency mitigations needed. | Yes | EU region US-headquartered; EU data residency available | EU region US-headquartered; EU data residency available | EU region US-headquartered; EU data residency available | Yes Red Hat NL/EU presence; project itself jurisdiction-neutral Pricing model (public list, 2026) Pricing posture | One-off licence + maintenance No per-MAU fee. See pricing . | Per-MAU SaaS | Per-MAU SaaS | Per-user, with premium tiers | Free (you operate it) ### Where CodeB Identity is genuinely ahead #### EU Wallet, already live OID4VP 1.0 + HAIP 1.0 Verifier serving real wallet flows on www.aloaha.com today . Both x509_hash and x509_san_dns Client Identifier Prefixes supported. SD-JWT VC parse + claim relay through OIDC id_token + UserInfo. Hosted IdPs are still in preview programmes. #### IIS-native, no JVM Drop-in on the Windows Server + IIS box you already pay for. No Docker, no Java, no Kubernetes. ASP.NET .ashx handlers compile on first request. The bridge is a single .NET service. #### One product, three problems OIDC IdP + WebRTC meetings + SIP phone bridge + Voice AI receptionist + outbound AI campaigns + TURN server, all in one install. No three-vendor integration project. #### Sovereign by design Tenant data lives in App_Data// on disk you own. No telemetry pipeline phoning home. Compatible with EU CRA, NIS2 supply-chain expectations, and the basic GDPR principle of avoiding unnecessary processors. ### Who should pick CodeB Identity? - You already run IIS, want to add identity without standing up Java or containers. - You need EU Wallet (EUDI) sign-in today , not on a hosted vendor’s preview waitlist. - You also need meetings, SIP, or AI calls and would rather have one product than three subscriptions. - Data sovereignty is a hard requirement (regulated sector, public sector, EU Cyber Resilience Act mindset). - Per-MAU pricing on a hosted IdP doesn’t fit your budget at scale. ### Who should pick the others? - You need a huge catalogue of pre-built social and enterprise connectors. - You explicitly want someone else to operate the IdP for you (CodeB is a self-hosted product). - You’re deep in Microsoft 365 and want native Entra ID integration. ### Want to try CodeB Identity? No signup. The live IdP is on www.aloaha.com. Sign in with a passkey, EU Wallet, or password. Trademarks — Okta is a registered mark of Okta, Inc. Auth0 is a registered mark of Okta, Inc. Microsoft Entra ID is a registered mark of Microsoft Corporation. Keycloak is a project of Red Hat, Inc. Mentioned here for descriptive purposes only. ### Frequently asked questions What is CodeB Identity? CodeB Identity is a sovereign, self-hosted OpenID Connect identity provider that runs on Windows Server and IIS, made in Malta by Aloaha Limited. It supports password, passkey (FIDO2 / WebAuthn), magic-link, authenticator-app (TOTP) and EU Digital Identity Wallet sign-in. CodeB Identity ships in the same product as WebRTC meetings, a SIP phone bridge, a Voice AI receptionist and outbound AI campaigns. How does CodeB Identity compare to Okta? CodeB Identity is self-hosted on your own IIS server, while Okta is SaaS only. Both implement the core standards compared on this page, including OpenID Connect, PKCE, token introspection and revocation, and passkeys. According to the page's matrix, verified on 2026-06-11 against vendor documentation, CodeB already offers EU Digital Identity Wallet sign-in where Okta's is not yet generally available, and CodeB uses a one-off licence plus maintenance instead of per-MAU SaaS pricing. Okta is US-headquartered with EU data residency available and is more mature for SCIM provisioning, social login and a large connector catalogue. How does CodeB Identity compare to Auth0? CodeB Identity runs on your own IIS server, whereas Auth0 is SaaS only; Auth0 Private Cloud is still hosted by Okta. Both support OpenID Connect, PKCE, passkeys, magic links and TOTP. The page's matrix lists EU Digital Identity Wallet sign-in as available in CodeB and not yet generally available in Auth0, and contrasts CodeB's one-off licence plus maintenance with Auth0's per-MAU SaaS pricing. How does CodeB Identity compare to Microsoft Entra ID? CodeB Identity is self-hosted, while Microsoft Entra ID runs in the Microsoft cloud only. On EU Digital Identity Wallet sign-in, the page lists CodeB as live and Entra ID as part of an EU Wallet preview programme. Entra ID pricing is per user with premium tiers, and meetings come only via a separate Microsoft 365 subscription for Teams, whereas CodeB bundles meetings, SIP and Voice AI. Organisations deep in Microsoft 365 that want native Entra ID integration are better served by Entra ID. How does CodeB Identity compare to Keycloak? CodeB Identity and Keycloak are both self-hosted and keep user records on your own premises. Keycloak runs on a JVM / WildFly and is free if you operate it yourself, while CodeB Identity runs natively on IIS with no Java, Docker or container orchestration and is sold as a one-off licence plus maintenance. For EU Digital Identity Wallet sign-in, CodeB has first-party support, while Keycloak relies on community plug-ins. Does CodeB Identity support EU Digital Identity Wallet sign-in? Yes, CodeB Identity supports EU Digital Identity Wallet (EUDI) sign-in using OID4VP 1.0, HAIP 1.0 and SD-JWT VC, with both x509_hash and x509_san_dns Client Identifier Prefixes. The verifier serves real wallet flows on www.aloaha.com, and wallet claims are relayed through the OIDC id_token and UserInfo. A wallet sign-in can also act as password-recovery proof through the RFC 7523 JWT-bearer grant. Does CodeB Identity need Java, Docker or Kubernetes? No, CodeB Identity needs no Java, Docker or Kubernetes. It installs on the Windows Server and IIS box you already run, using ASP.NET .ashx handlers that compile on first request, and the bridge is a single .NET service. How is CodeB Identity priced? CodeB Identity is sold as a one-off licence plus maintenance, with no per-MAU fee. By comparison, the page lists Okta and Auth0 as per-MAU SaaS, Entra ID as per-user with premium tiers, and Keycloak as free if you operate it yourself. Current CodeB prices are on the pricing page. Where are Okta, Auth0, Entra ID or Keycloak ahead of CodeB Identity? The other identity providers are more mature than CodeB Identity for SCIM provisioning, broad social login and large catalogues of pre-built social and enterprise connectors. They also suit teams that want someone else to operate the IdP, since CodeB is a self-hosted product. Entra ID is the natural choice for organisations deep in Microsoft 365. How can I try CodeB Identity? You can try CodeB Identity without signing up on the live IdP at www.aloaha.com. You can sign in there with a passkey, an EU Digital Identity Wallet or a password. =================================================================== # Wallet OEM · embed the CodeB European Digital Identity Wallet backend in your native mobile app · CodeB Aloaha Malta # Source: https://www.aloaha.com/wallet-oem.html =================================================================== > OEM licensing for the CodeB Web Wallet backend. Embed 25 documented endpoints in your iOS + Android app: OID4VCI credential import (A, 10 endpoints), self-issue from OIDC identity (B, 2 endpoints), OID4VP presentation (C, 3 endpoints), wallet operations (D, 10 endpoints). Shared managed hosting on phone.aloaha.com with per-OEM OIDC client_id isolation, per-OEM subdomain, or on-premise. Wallet Attestation minting via /wallet-attestation.ashx. From Malta, EU-jurisdiction. Ready for European Digital Identity Wallet integrations. ## Embed the CodeB European Digital Identity Wallet backend in your native app. Twenty-five documented endpoints across four capability groups. Your iOS + Android app implements the client side with platform-native crypto (Secure Enclave, Android Keystore); the wire protocol is identical to the CodeB browser-based Web Wallet you can try today. Backed by a complete API reference , five native-integration cookbooks , an OpenAPI 3.1 spec , and a Postman collection . Contact info@aloaha.com for OEM licensing. ### What your app can do. The endpoint contract mirrors what the CodeB browser wallet does today. Every native OEM app maps to the same wire protocol; the differences are in local crypto and persistence. #### A. Credential import (10 endpoints) OID4VCI 1.0 FINAL holder side. Discover issuer metadata, handle both pre-authorized-code and authorization-code + PAR grants, sign the openid4vci-proof+jwt on-device, POST /credential for both dc+sd-jwt and mso_mdoc . Import from external issuers (issuer.eudiw.dev) and from our own vci.ashx. #### B. Self-issue from OIDC identity (2 endpoints) When CodeB is BOTH your identity provider and issuer, skip the OID4VCI ceremony: enumerate eligible VCs via ?available-attributes , mint bound to a fresh wallet key via ?issue-in-session . Two calls, no browser hop. #### C. Credential presentation (3 endpoints) OID4VP 1.0 FINAL holder side. Fetch JAR directly, resolve DCQL against local credentials, build SD-JWT KB-JWT or mDoc DeviceResponse, POST via direct_post or direct_post.jwt (JWE ECDH-ES + A128GCM). Attach the Wallet Attestation as OAuth-Client-Attestation header when the verifier requires it. #### D. Wallet operations (10 endpoints) Narrow session tokens, encrypted vault backup / load / delete (opaque to server), server-side mDoc verify with configurable trust anchors, tenant DID discovery, RP-initiated logout with Clear-Site-Data, member-facing self-offer mint, ARF 3.0 TS7 data-deletion and TS8 DPA-report. ### Pick the deployment that fits your risk profile. #### Shared managed phone.aloaha.com . Fastest to onboard: your OEM OIDC client_id is provisioned in days, isolation via the azp claim baked into the vault storage-key hash. Lowest ops burden for your team. #### Per-OEM subdomain .aloaha.com . Dedicated tenant with own DIDs, own CA, own branding. Suitable when your regulatory posture wants a named sub-processor with distinct data boundaries. #### On-premise Full CodeB stack on your Windows Server + IIS. No cloud dependency except optional QTSP timestamp lookup. For regulated industries or public sector deployments that require complete data residency. Dimension | Shared managed | Per-OEM subdomain | On-premise Onboarding | Days | Weeks | Weeks (deploy + train) Isolation | OIDC azp in storage-key hash | Separate tenant, separate keys | Separate infrastructure Custom branding | App-side only | Server + app side | Full Data residency | Malta (Aloaha) | Malta (Aloaha) | Your choice Ops burden | None | None | You run IIS ### Integrator deliverables. - API reference — wallet-api.html . Every endpoint with request/response shapes, auth badges, native-parity notes. - Five cookbooks with iOS Swift + Android Kotlin snippets — import , present , Wallet Attestation , vault sync , self-issue . - OpenAPI 3.1 spec — openapi/wallet-api.yaml . Codegen a client for your language of choice. - Postman collection + environment — collection , env template . QA-team-ready. - Direct access to the Aloaha technical team during integration. E-mail SLA one business day. ### HAIP-conformant runtime mint. The runtime mint at /wallet-attestation.ashx is HAIP §5.11 conformant. Each call binds the wallet's walletPublicJwk to the acting OIDC sub and returns a JWT with typ=wallet-attestation+jwt in the header, per-tenant HS256-signed, 24-hour expiry. Verifiers that check the JWT signature against the tenant's HMAC key accept it as evidence that the presenting client is a legitimate wallet. See the WA cookbook for the wire. ### EU jurisdiction. Real one. Aloaha Limited is based in Malta — an EU member state with an English-language legal system, GDPR applicability, eIDAS conformance and a LOTL-listed national trust list. Wallet Attestations minted from a Maltese tenant carry EU legal recognition under Regulation (EU) 910/2014. US-jurisdictional providers bring CLOUD Act reach and Schrems II complexity that many European OEM integrators actively avoid for identity-adjacent data. See EU ID Wallet software Malta for the broader positioning. ### Start OEM onboarding. Send an e-mail with your company details, technical contact, OIDC client name, and rough deployment scope. Aloaha's tech team responds within one business day and provisions your OEM client_id against the tenant of your choice. ### Frequently asked questions What is the CodeB Web Wallet OEM offering? A licensable European Digital Identity Wallet backend that OEM integrators embed in their own native mobile apps. Twenty-five documented endpoints across four capability groups: OID4VCI credential import (holder side, 10 endpoints), self-issue from the OIDC identity (2 endpoints), OID4VP credential presentation (holder side, 3 endpoints), and wallet operations (10 endpoints). Your native app implements the client side with the platform's Keychain / Keystore for on-device crypto; the wire protocol is identical to what CodeB's browser-based Web Wallet uses today, so the backend is battle-tested. Which hosting tiers are available? Three tiers. Shared managed hosting on phone.aloaha.com — fastest to onboard, per-OEM OIDC client_id isolates apps and the storage-key hash includes azp for cross-OEM vault isolation. Per-OEM subdomain (yoursubdomain.aloaha.com) — dedicated tenant with own DIDs, own CA, own branding. On-premise — you deploy our IIS stack in your own data centre, complete sovereignty. All three tiers use the same endpoint contract; upgrading between tiers is transparent to the app. How does OEM onboarding work? Lightweight KYB via email to info@aloaha.com: company legal name and registration, technical contact, OIDC client name and redirect URIs, deployment scope. Aloaha provisions a per-OEM OIDC client_id against the tenant of your choice within two business days. The Wallet Attestation mint works out of the box on the shared managed tier. What deliverables do OEM integrators receive? Human-readable API reference (wallet-api.html) documenting every endpoint with request/response shapes and native-parity notes. Five cookbooks with iOS Swift and Android Kotlin code samples: credential import (OID4VCI holder), credential presentation (OID4VP holder), Wallet Attestation, encrypted vault sync, self-issue from OIDC identity. OpenAPI 3.1 spec for machine-readable codegen. Postman collection with an environment template. Access to the Aloaha technical team for integration questions. Why Malta? Aloaha Limited operates from Malta — an EU member state with an English-language legal system, GDPR applicability, eIDAS conformance, and a LOTL-listed national trust list. Wallet Attestations minted by us carry EU legal recognition under Regulation 910/2014. US-jurisdictional providers bring CLOUD Act and Schrems II risks that many European OEM integrators actively avoid for identity-adjacent data. How is cross-OEM isolation enforced? On the shared managed tier: (1) every OEM's app has its own OIDC client_id; (2) the OIDC access token carries the client_id in the azp claim; (3) our wallet-backup handler hashes storage keys over sub|tenant|azp, so two OEMs on the same tenant whose users share a sub cannot collide on the same vault blob. Per-OEM subdomain and on-premise tiers use full tenant separation instead — separate App_Data/tenant directories, separate signing keys, separate DIDs. What is the state of Wallet Attestation? The runtime mint at /wallet-attestation.ashx is HAIP §5.11 conformant: JWT with typ=wallet-attestation+jwt in the header, walletPublicJwk bound to the acting OIDC sub, 24-hour expiry, per-tenant HS256 with a symmetric HMAC key. Verifiers that check the JWT signature against the tenant's HMAC key accept the WA as evidence that the presenting client is a legitimate wallet. Is on-premise sovereignty possible? Yes. The full CodeB stack is deployable as an on-premise IIS deployment. Requirements: Windows Server 2019+, IIS 10+, .NET Framework 4.8. No cloud dependency except the qualified timestamp lookup at the QTSP for signing operations (and that QTSP endpoint is configurable). The wallet backend endpoints are contained entirely within your deployment. =================================================================== # CodeB Features — sovereign CPaaS with live EU Wallet sign-in · BYOC SIP · WhatsApp Business Cloud API # Source: https://www.aloaha.com/features.html =================================================================== > Every CodeB feature in one breakdown: browser meetings, BYOC SIP, AI receptionist, REST + webhooks, OIDC IdP, EU Wallet (OID4VP 7662/7009 + RP-Initiated Logout), passkeys (FIDO2/WebAuthn), transcripts, live OID4VP 1.0 EU Wallet sign-in (SD-JWT VC + DCQL, x509_hash mandated by HAIP 1.0 Final (wallet-preferred), plus x509_san_dns as an additional OpenID4VP compatibility mode), and a self-hosted WhatsApp Business Cloud API bridge (Meta Graph API v20, per-tenant credentials, message templates with placeholders, 24-hour customer service window UI, template-bound API keys, per-day new-chat abuse quota). Self-hosted. ## The full breakdown — every feature, in production today. For buyers: this page reads like a changelog. If you want the short version — the ten reasons that matter without the engineering detail — jump to Top 10 reasons → . For engineers / evaluators: the list below is the entire feature set as of today, organised by area. The product runs entirely on your own Windows + IIS server — for organisations that already own their telephony and don’t want to send their calls through a SaaS cloud just to add browser meetings. ### The meeting itself. Video, audio and screen — the table stakes. Built directly on the browser's WebRTC stack with mesh topology, no media server involved. #### HD video + audio 1280×720 native; per-track audio echo cancellation, noise suppression and AGC enabled by default. Camera and microphone pickers in settings. #### Screen sharing Full desktop, single window or browser tab. Auto-spotlights the sharer; auto-reverts to camera when stopped. #### Consent-gated remote support A helper can take over the shared PC's mouse and keyboard — but only after the user clicks Allow , or with a short access code the user creates and gives out. A bar always shows who has control; Ctrl + Alt + F12 stops it instantly. The controlled side needs Aloaha RDPLauncher on Windows. #### Front / back camera flip Mobile-only toggle. Switches between selfie and rear camera on iPhone / Android with a single tap. Other participants see the change seamlessly. #### Spotlight one tile Click the expand icon on any tile → it goes large, others become a thumbnail strip. Auto-spotlight on local screen share. Auto-revert on stop. #### Picture-in-picture (both kinds) Standard PiP — single video pops out. Plus Document PiP on Chrome 116+ — the entire meeting UI (grid + chat + controls) floats as a resizable window. #### Mesh topology Up to ~6 participants in a single full-mesh call. Every browser sends to every other browser directly; no server in the data path; bandwidth scales with N-1. ### Talk, type, point, share, react. Once the call is up, everything else flows over WebRTC data channels — encrypted end-to-end, never relayed by any server. #### In-meeting chat Side panel on desktop, full-screen on phone. Markdown-safe text rendering. Coloured pills per author. Unread badge. End-to-end encrypted alongside the audio and video. #### Local team chat with groups and files Direct messages, group channels, and file sharing up to 20 MB — all served from your own tenant. Real-time delivery over WebSocket, OIDC-authenticated, per-tenant isolation. No third-party messaging gateway. Open /chat.html or integrate via the REST + WS API . In-meeting chat now uses the same unified bubble style as standalone chat so the surfaces feel like one product. #### Meeting chat archive when you sign in Signed-in participants get an automatic, per-day, per-room record of what they said in the in-meeting chat — browseable from /chat.html under “Meeting archives”. Guests stay ephemeral: no session, no server-side retention. Each archive is tenant-scoped and private to the user who wrote it. Retention defaults to 90 days per tenant (override via Chat:MeetingArchiveDays ); a per-tenant janitor prunes older day-directories opportunistically. #### P2P file transfer Drag-and-drop into chat; chunked over the data channel; live progress bar; receiver downloads a real file. Up to 1 GB per file. Never touches the server. #### Remote pointer Move your cursor over any tile; everyone else sees a labelled arrow at the same spot. Click flashes a ripple. Touch supported. Tile-local; no input injection. #### Sticky notes on screen share Double-click any tile in sticky mode → colored note appears at that spot. Editable, author-tagged, timestamped. Synced across all peers. #### Reactions + raised hand Six emoji reactions float up over the sender's tile and dissolve. 🤚 raise-hand sets a waving badge with auto-announce in chat. #### Local meeting recording Composite canvas of all tiles + AudioContext-mixed audio → WebM (VP9 + Opus). Saved straight to the recorder's machine. Nothing uploaded. #### Shared whiteboard Fullscreen canvas overlay everyone can draw on — pen, eraser, five colours, undo, clear. Strokes sync over the same chat data channel; no extra server endpoint. #### Breakout rooms Host splits the room into 2–4 groups for 2–30 minutes. Each peer reconnects to their assigned sub-room. Switch between groups or return to main with one click. Late joiners can pick from a live list. ### What makes this a CodeB product. The codeb.io thesis applied to conferencing: no third-party cloud, no telemetry, no data ever leaves the customer's network unless the customer explicitly routes it externally. #### End-to-end DTLS-SRTP Media keys are negotiated peer-to-peer at call setup. The server cannot decrypt; even a TURN relay only sees ciphertext. #### Lockable rooms + knock-to-join Lock the room → new joiners are held in pending. Existing participants admit or deny. Strangers never reach the call without explicit consent. #### Forensic-grade signed recording Every recording ships with a sidecar JSON: SHA-256 of the file, ECDSA-P256 signature, participants list, speaker-turn timeline. Tamper-evident. #### Recording-consent gate Click Record and every other peer gets an Allow / Deny prompt. The recording can't start until everyone agrees. Each decision is logged into the ECDSA-signed sidecar — cryptographic proof of who consented when. #### Verified by CodeB badge Participants who sign in before joining show an amber CodeB shield next to their name. Visible identity attestation in the meeting itself — anti-impersonation, no third-party identity provider required. #### Time-limited TURN credentials If the relay is in play, credentials are minted per session and expire automatically after one hour. No static password is ever embedded in the page source for an attacker to harvest. #### On-prem Windows TURN The TURN relay runs as a Windows Service on the customer’s LAN, integrated into the SIP bridge process. No Docker, no Linux dependency. Stays on-prem; air-gap deployable. #### Triple-transport relay Strict-firewall callers always get a working path. The TURN relay listens on three transports in parallel — UDP/3478 (lowest latency), TCP/3478 (when UDP is blocked outbound), and TLS/5349 using the turns: scheme (when only TLS-shaped traffic is permitted). Optional fourth bind on TCP/443 for the strictest corporate networks — configurable, off by default to avoid clashing with the IIS site. #### Auto-rotating TLS certificate For the turns: endpoint the bridge auto-discovers a certificate from the Windows LocalMachine\My store by matching the public hostname against Subject CN and SAN. Picks the candidate with the latest expiry, so a freshly renewed Let’s Encrypt cert wins automatically. Refreshes hourly — rotations happen without a service restart. ### Small things that add up. The hundred details that make the difference between a meeting tool you use because you have to, and one you actually enjoy. #### Auto-spotlight on speaker Whoever speaks loudest auto-becomes the spotlight tile. Short cooldown prevents flicker. Toggleable. #### Connection-quality bars Per-tile signal bars track round-trip time, packet loss and bitrate. Colour-coded so you can spot a struggling peer at a glance. #### Auto-reconnect If the network blips, the call recovers itself: a brief “Reconnecting…” banner appears, peer connections are re-established, and the meeting resumes without anyone needing to rejoin. ICE restart fires automatically on transport failure with a five-attempt back-off, sized for cellular UDP blackouts that can last 30–60 seconds. #### Self-healing video path Several recovery layers run in parallel. Outbound video uses an adaptive bitrate ladder (720p → 480p → 360p → 240p) so the picture stays alive on slow uplinks instead of going to audio-only. After every ICE restart a fresh keyframe is forced so the peer’s decoder picks up the new stream immediately. If a peer sees the other side’s video freeze, it asks that side to recycle its sender. Audio rarely drops; video typically resumes in under a second. #### Mobile keepalive bundle iPhone & Android tabs survive screen-lock, app-switch and background suspension during AI calls: screen wake-lock, silent audio-context sink, server-side WS heartbeat at a fast cadence on mobile UAs, plus comfort-noise dithering on the model audio so WebRTC keeps the stream “active.” Layered defenses, no permission prompts. #### Adaptive AI audio buffering the cloud AI Voice Engine occasionally generates audio at 2–3× realtime in bursts. The bridge detects silent pauses in the model output and pre-compresses them on the way to the listener — queue stays small, latency stays low, no audible cutoffs even when the model talks faster than realtime. #### Audio elevator brake Sudden volume spikes on any remote stream are softened automatically and the speaker's tile gets a discreet ?! badge so nobody is blown out of the call. #### Per-tile volume sliders Hover any remote tile → small vertical slider top-right. Independent volume per participant, 0–200%. Local to your tab, doesn't change anyone else's audio. #### Idle camera dim When your tab loses focus, your outbound video drops to a low bitrate. It comes back full-quality the moment you return. Saves bandwidth for everyone else without a manual mute. #### Responsive layout Single tile, 2-column, 3-column grids based on participant count. Phone-friendly controls. Safe-area-inset aware for the notch. #### QR code join The landing page generates a live QR for the room URL as you type. Generated locally in the page — no third-party service involved, works fully offline. #### Keyboard shortcuts M mute · V camera · S share · C chat · E spotlight · H hand · P PiP · Space push-to-talk. #### Persistent preferences Name, device picks, mirror, push-to-talk, auto-spotlight, pointer, blur, join-muted, join-cam-off — all remembered across browser sessions. Stored locally; never sent to any server. #### Background blur On-device segmentation: you stay sharp, your background goes soft. Runs entirely in the browser; no image ever leaves your machine for processing. #### Live device + name rename Switch microphone, camera or your display name mid-call without dropping the connection. Peers see a system message and updated tile label. #### Bandwidth adaptive ladder Outbound video steps down per recipient through 720p → 480p → 360p → audio-only as link quality demands. Each peer gets the best tier their connection can carry — the slowest person doesn't pull everyone else down. #### Route + quality badge Each remote tile carries a tiny chip — LAN · 1080p , P2P · 720p or Relayed · 480p — so you can confirm the link is truly peer-to-peer (or see when it's not) at a glance. ### Phones are first-class participants — over your own carriers. A self-hosted WebRTC ↔ SIP gateway with full Bring Your Own Carrier (BYOC) support: turn a meeting room into a callable destination — or a phone number into a meeting participant — using the SIP trunks you already pay for. Drop a Call-us button on any web page; the recipient picks up on their normal phone and lands in a CodeB meeting alongside everyone else. No telephony reseller in the path. #### WebRTC ↔ SIP bridge A small on-prem service that registers as a SIP extension on your PBX or trunk provider. When the bridge dials a number, the answering phone joins the meeting as a normal audio-only participant. Standard codecs on both sides; no third-party transcoding service. #### SIP over WebSocket (RFC 7118) — bring your own browser softphone Any standards-compliant browser softphone library — SIP.js, JsSIP, sipML5, Linphone-WS — can register against your CodeB tenant over wss:// and place calls without an extension, native installer or per-seat upcharge. RFC 7118 has been a published standard since January 2014. We’ve noticed that several of the most widely deployed soft-PBX platforms still don’t ship it as a first-class feature; we don’t pretend to understand why, but we listened to customer demand and built it in. Two installable PWA demos live on the site ( SIP.js , JsSIP ) — credentials in browser localStorage, real dialpad with DTMF, “Add to Home Screen” on mobile. #### Browser softphones are full-duplex citizens A WebSocket-registered softphone is not a second-class endpoint. It can DIAL anything — another extension, a PSTN number through your trunk, an AI agent on a virtual number — and it can also RECEIVE calls from any of those places. A trunk-side INVITE for an extension that’s logged in via the browser rings the browser tab natively; the AI agent can transfer the caller to a registered colleague mid-conversation; either party can hang up and the signalling reaches the other side cleanly within a few hundred milliseconds. Same auth, same call detail records, same lawful-interception path as a hardphone. Read the full SIP-over-WebSocket page → #### SIPS — encrypted SIP signalling per RFC 5630 Hardphones and trunks that require TLS-encrypted signalling land on dedicated TLS ports — TCP 5061 trunk-side and TCP 6061 as the public listener — mirroring the existing UDP topology so adopting SIPS does not rearchitect routing. Each handshake selects the per-tenant certificate by SNI from the operator’s existing Windows certificate store; adding a new tenant means installing one more LE cert via /acquire-cert — no SAN list to maintain. Per-trunk opt-in: flip the TLS checkbox in trunk admin and the bridge re-registers with sips:user@host:5061;transport=tls . Defence-in-depth shared with the TURN media plane: the same acl.html rules block SIPS traffic from blacklisted IPs / CIDRs, a per-IP TLS handshake-fail auto-blacklist drops repeat scanners at the socket layer (15 failures / 5 min → 1 h block, CGNAT-tolerant), and a 15 s handshake timeout shuts down slow-loris peers before they consume thread-pool slots. SIPS calls that bridge to plain SIP legs proceed with the call and emit one structured WRN per downgrade — never silent, never blocked. Read the full SIPS page → #### SRTP via SDES — encrypted media on the trunk leg (RFC 4568) Per-trunk SRTP keying via SDES (RFC 4568) protects audio between the bridge and your SIP carrier. When the toggle is on, outbound INVITEs offer RTP/SAVP with a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:… ; inbound INVITEs answer SDES whenever the peer offers it — asymmetric, safe-by-default. If the peer rejects the offer the call ends — no silent plaintext fallback. Pair it with the per-trunk TLS (SIPS) toggle and both planes — signalling and media — are encrypted on the carrier leg. The bridge terminates SRTP so AI receptionist, signed recording, transcription and lawful-intercept hooks keep working; the WebRTC browser leg keeps its own DTLS-SRTP. Default OFF per trunk so existing trunks are unchanged. Read the SRTP / SDES section → #### Per-trunk live transcription — bring your own key A per-trunk toggle in the admin console streams the call audio to Google Gemini Live’s automatic-speech-recognition side-channel and writes a timestamped, speaker-attributed transcript into the tenant’s own App_Data//gemini-transcripts/ tree. Each trunk carries its own model override and its own API key, so a shared carrier trunk feeding multiple tenants keeps every tenant on their own key, their own model tier, and their own upstream billing quota. An optional per-trunk recipient list emails the finished transcript through your local SMTP pickup directory the moment the call ends — no third-party mail relay, no vendor console to log into, no transcript ever leaving your infrastructure other than to the mailboxes you named. Pair it with per-trunk call recording and every conversation lands in your IIS filesystem as both a stereo WAV and a searchable transcript, ready for the compliance archive. #### Session-Timer — mid-call liveness on the trunk leg (RFC 4028) Per-trunk RFC 4028 Session-Timer adds a defensive mid-call liveness check between the bridge and your SIP carrier. When the toggle is on, outbound INVITEs advertise Session-Expires + Min-SE + Supported: timer ; if the carrier acknowledges the extension the bridge sends periodic UPDATE refreshes at half the negotiated interval and tears the dialog down via BYE if a refresh is missed past the grace window. Carriers that don't implement RFC 4028 simply ignore the advertisement and the call falls back to the RTP-watchdog already in place. Inbound calls answer the peer's Session-Timer request regardless of the flag — the per-trunk toggle controls only what the bridge advertises on outbound. Defaults OFF so existing trunks are byte-identical until an operator opts in. #### RTP watchdog — no ghost calls, no ghost minutes Some carriers stop sending media when the remote party hangs up but never emit a SIP BYE. CodeB’s RTP watchdog notices the silence: fifteen seconds without inbound audio and the bridge synthesises the hangup, tears the dialog down cleanly, closes the CDR, and stops the meter. Your invoice reflects the call that actually happened, not the one the trunk left half-open. Runs on every bridge leg — carrier inbound, outbound-AI campaigns, WSS softphones, mid-call transfers — so a silent-carrier outage on any leg is turned into a clean, auditable dialog end within a bounded window rather than a stuck session on the operator’s bill. #### Forwarded-call caller identity — the mobile sees who is really calling When an inbound call is forwarded to a mobile or external number, CodeB preserves the original caller’s display name on the outbound leg so the person answering the phone sees who is actually calling — not the switchboard, not the trunk’s default identity, not a blank string. If the incoming call carries no display name at all, the caller’s number itself becomes the display so a recognisable string still lands on the mobile. Works out of the box on any InboundRoute that forwards to an E.164 number, so a receptionist who has to jump on a bus never has to guess who is on hold. #### Per-trunk SIP call recording — included, no add-on A per-trunk toggle in the admin console turns on stereo call recording for any SIP carrier or hardphone trunk. Caller ends up on the left channel, callee on the right, in a standard .wav file — the format every transcription tool, DAW and forensic-audio workstation already opens. Peak normalisation is on by default so faint carrier audio comes back at a useful playback level without clipping. Recordings land under the tenant’s own App_Data tree on your IIS server — one directory per day, no shared bucket, no third-party storage, no minute-priced add-on bill. An admin-only recordings.html page lists, plays and downloads them in the browser; only the tenant’s administrators or the on-host super-user can reach the page or the files. Useful for sales-call review, dispute evidence, training transcripts, regulator audit packs, and any conversation where the operator’s lawyer wants a contemporaneous record. #### Shared-trunk recording & transcription fan-out When one SIP carrier trunk feeds multiple tenants — the classic BPO / call-centre outsourcer topology — each tenant’s Record and Transcribe rules fan out independently. Every tenant with a matching rule receives its own copy of the recording and transcript into its own App_Data// tree; tenants never see each other’s audit material. Every regulator gets a complete archive without ever crossing the isolation line. #### One-click call from any web page Drop a single URL on a support page, contact form or signature: when the visitor opens it, the bridge dials your team's phone automatically and the visitor joins the same meeting room from their browser. No installs, no plugins, no third-party redirect. Perfect for “Talk to sales now” buttons. #### Secret alias IDs keep real numbers off public pages Call buttons use direct dial strings — the office extension ?dial=610 or an E.164 number like ?dial=+49301234567 . No per-page configuration. The destination is whatever the bridge resolves at call time. #### Bring Your Own Carrier (BYOC) — any SIP trunk works True BYOC: works with any standards-compliant PBX or trunk provider — consumer routers, on-prem PBX appliances, hosted ITSPs, Tier-1 SIP wholesalers. Credentials live in the bridge's local config; nothing routes through a third-party intermediary. Your call records belong to your carrier, your minutes are billed on your existing agreement, and you can switch carriers without changing CodeB. #### Multi-trunk with priority & failover Define multiple trunks, give each a priority. A dial uses the highest-priority trunk that has free capacity; if the chosen trunk is busy or unreachable, the bridge transparently switches to the next. Per-trunk concurrent-call caps let single-line residential trunks and high-density SIP-trunk providers coexist in the same setup. #### Per-number routing rules Define rules like “extension 610 always dials via the office PBX” or “everything in +356 goes via the Malta trunk”. Wildcards and E.164 prefixes both supported. Useful when different destinations need different carrier paths for compliance or cost. #### Per-call dial prefix per trunk Each trunk has an optional dial prefix (e.g. *31# on European carriers) prepended automatically to E.164 destinations. Use it for per-call caller-ID suppression, premium-route opt-out codes, or any carrier-specific dial signal you want applied uniformly on every outbound call through that trunk. Internal extensions are never prefixed. #### Strict number whitelist The bridge only dials numbers explicitly enumerated by the operator. An attacker who finds a dial URL still can't redirect it to a premium-rate destination — the whitelist is the gate, the alias ID is just a shortcut to a row in it. #### Geographic prefix restriction Operator-configurable E.164 prefix allowlist. Ship a deployment that can only dial European destinations (or any subset you define). Plus a blocklist for premium-rate ranges that always wins, even if a whitelist entry accidentally includes one. #### Per-call fraud caps Hard limits on concurrent outbound calls, max call duration, daily call-count per room and per requester IP. Even with the whitelist breached, an attacker can't run up an unbounded carrier bill before the cap stops them. #### Per-trunk rolling 24-hour cap Optional ceiling on outbound dials per SIP trunk over any rolling 24-hour window — not a calendar day, an honest 24-hour look-back so a compromised credential can’t reset itself at midnight. Set 200/day on a wholesale trunk and the bridge refuses dial #201 fail-closed across every outbound path: SoftPhone-to-PSTN B2BUA, AI receptionist transfers, scheduled outbound AI campaigns, and SIP-trunk-to-SIP-trunk bridging. Operator sees a live used / cap counter beside each trunk in the trunks admin form , refreshed every 30 seconds, and every refusal is logged with tenant, trunk, count, cap and window for post-incident audit. Counter is in-memory by design — restarting the bridge is the explicit reset. #### E.164 + PBX extensions both work Dial an international number, a residential-router internal extension, or a PBX dialplan number. The bridge normalises the format and applies the right SIP user-part for the chosen trunk — one consistent dial syntax regardless of carrier. #### Text-to-speech auto-reply Answer specific inbound callers with a pre-recorded message instead of ringing the CodeB Webphone. Define rules in config: blacklist a nuisance number with “this line is closed, goodbye”, send an after-hours greeting on a specific DID, or play any canned response. The bridge handles the SIP answer, plays the message, and hangs up — no human picks up. #### Country-aware language responses Match callers by country code — ISO-2 ( CN , DE , IL ), country name ( China ), or raw E.164 prefix ( +86 ). Play a different language per country: “I do not speak Mandarin” for +86 callers, German hours announcement for +49 , English fallback for everyone else. Numbers without an international prefix don't match country rules, avoiding false positives on domestic-format caller IDs. #### Local TTS engine, no cloud Uses the on-premise AI Voice Engine by default — no API key, no external service, no data leaves the host. Voices are configurable per deployment; install the German voice pack and your “Anrufer nicht verfügbar” sounds native. The auto-reply pipeline pre-renders every rule to G.711 at startup, so the very first matching call answers in milliseconds with zero per-call TTS latency. #### Bounded, abuse-resistant playback Each auto-reply has a hard per-rule duration cap, counts against the global concurrent-call limit, sends 180 Ringing before answering so carriers' jitter buffers warm up, prepends a configurable lead-in silence so no syllable gets clipped, and bails immediately on caller CANCEL. A flood of blacklisted callers can’t monopolise the trunk — cap hits, carrier rolls to voicemail / next-step cleanly. ### A voice AI that actually picks up. Point a number at CodeB, pick the real-time voice mode, paste a system prompt. The next inbound call is answered by a real-time voice AI that speaks any language, follows the script, takes messages, transfers to a human SIP phone when the caller asks, and emails you the transcript when the call ends. Sample industry: hospitality — one front desk, three personas (reception, restaurant, spa), 24 hours a day. Browse every virtual number configured on this host in the virtual numbers directory . #### Try it — talk to our AI receptionist now. Calls vnum 1234 — the CodeB Sovereign Communications virtual assistant. Browser-only, voice-only, no signup, no install. Ask about features, meetings, pricing — the AI speaks any language and transfers to a human SIP phone when you ask. #### Real-time, not record-and-respond Full-duplex audio over the SIP leg the caller dialled. Hears the caller as they speak, can be interrupted mid-sentence, replies with sub-second latency. No “please wait while I think” pauses. The real-time voice backend is pluggable per deployment. #### Any language, on the fly Detects the caller’s language and replies in kind. Switches mid-call if the caller switches. The script can pin a default greeting language or let the model decide. #### One persona per number Each virtual number gets its own system prompt, voice, opening line, and warm-up delay. A hotel can run reception, restaurant and spa on three numbers — same AI engine, three personalities, one deployment. #### Whitelisted transfer to a human The receptionist decides when to transfer using a structured transfer_to_user tool. Registered SoftPhones go direct via SIP REFER; external phone numbers are gated by the per-tenant number whitelist and refused fail-closed when off-list. FraudGuard re-checks on the loopback for defence-in-depth. #### Self-terminating — with reason A hangup tool lets the model end the call itself with a logged reason (caller said goodbye, abusive, voicemail loop). Reasons land in the transcript and CDR so you can spot patterns — useful when tuning a prompt against real call data. #### One room per caller Browser dial-in URLs can use room=random to mint a fresh isolated room name per session. Two visitors landing on the same link never share a room, so the AI never accidentally hears the previous caller’s side of the conversation. #### Delegate prompt editing Each virtual number lists an editors address book and exposes a per-number editor URL you can share with that team. The duty manager rewrites the script for the night without touching admin, the maître d’ tweaks the restaurant persona. Visibility — admin / signed-in / anonymous — controls who can see the row in the public directory . #### Transcript + summary by email Every call ends with a full transcript and a one-paragraph summary, sent to the per-number recipient list. Reads like a human took notes. Nothing else is retained on the server by default — no silent recordings. #### Always answers — TTS fallback If the configured provider credentials are missing or the model is unreachable, the bridge auto-falls back to a server-side TTS auto-reply so the caller never hits dead silence. The CDR records the fallback so you know it happened. Full feature page with the hospitality sample setup, configuration walkthrough and FAQ → ai-receptionist.html #### Catch anonymous & withheld callers Route calls with no caller-ID — CLIR, *31# prefix, Privacy: id header, or anonymous@anonymous.invalid From URI — straight to a virtual number running an AI screener. Unknown numbers reach an AI that asks “who’s calling and what’s this about?” before the call ever bothers a human. Set FromNumber = anonymous on any inbound route to turn it on. ### The AI calls them — on time, with retries, with humans on standby. The other half of voice AI: outbound. A signed-in admin opens the outbound-ai-call form, types a number and a system prompt (or a single word that loads prompts/.txt ), optionally picks a schedule and a retry plan. The bridge dials over your own SIP trunks at the chosen moment, the AI agent greets the callee the instant they pick up, transfers to a real human when asked, and emails a transcript after every attempt — even the failed ones. Built for feedback calls, appointment reminders, no-show follow-ups, customer-care callbacks — anything where a human-quality voice on the line beats an SMS. #### Bridge-owned routing Outbound calls and transfers pick their own trunk per the per-tenant OutboundRouteRules . A B2BUA splice means the bridge stays in the middle — cross-trunk transfers (callee on one carrier, target on another) just work, with no dependency on the upstream PBX honouring SIP REFER. Failover is automatic on quick-fail. #### Schedule for any future moment Pick a time on the bridge’s clock and the call fires then. Cached past times clamp to now + 1 minute on load, quick-set chips cover “tonight 20:00” / “tomorrow 09:00” / “+5 minutes.” The deferred dial is persisted to disk and survives a bridge restart — queued calls reload automatically when the service comes back up. Long-fuse campaigns up to 30 days, reboot-safe. #### Automatic retries on no-answer Set retry count and minute interval. The bridge retries on no-answer, busy, decline, trunk-error, all-trunks-failed, ai-error and silent cancellation. It explicitly does NOT retry when the callee actually engaged — not-now , wrong-person , voicemail , off-topic , abuse stop the campaign. Every attempt sends its own status email with the running “attempt N of M” tag. #### Whitelisted hand-off to a real human The AI can transfer mid-call to one of a fixed list of human targets (extensions or PSTN numbers, configured in the prompt). The bridge places a fresh outbound call to the target, splices RTP both ways, hangs up the AI side — no PBX REFER required, works across trunks. If a target line doesn’t answer the AI offers the next one. Anything off the whitelist is refused fail-closed. #### Prompt by name, edit live Type a single bare word ( callagent , shortletsmalta ) in the System Prompt field and the bridge loads prompts/.txt from the tenant’s prompts directory at dial time. Edit the prompt file between attempts and the next retry picks up the new content automatically — the same prompt store powers inbound AI receptionists . #### One email per attempt Every attempt ships the operator a transcript email with subject “completed”, “transferred”, or “FAILED — reason ,” tagged with the running attempt count and a body line saying whether a further retry is scheduled. Successful transfers are classified as successes, not as cancellations. Auditable across the whole campaign in plain text. #### Speaks first — no awkward silence The instant the callee picks up, the bridge sends the voice AI a synthetic trigger turn so the model generates its opening line immediately. No more “hello? hello?” while the AI waits for input audio. Same latency as the inbound receptionist path. #### FraudGuard + whitelist + OIDC admin Outbound dials honour the per-tenant whitelist; the admin form auto-appends the callee number to it. FraudGuard counters apply per-IP and per-room so a rogue API key can’t spin up unlimited dials. The form itself sits behind OIDC admin sign-in — only members of the admin role can trigger a campaign. #### Live campaign monitor & admin controls A live status board shows every scheduled, in-flight and recently-finished outbound AI call in colour-coded rows — scheduled, dispatching, in-flight, completed, retry pending, failed, cancelled. Updates every five seconds. Per-row Cancel button kills a parked campaign before it dials; Delete clears ended rows. Reset FraudGuard counters in one click when a test campaign hit a daily cap. #### Survives a server restart The outbound AI schedule is persisted to disk atomically on every queue change. If the bridge service restarts — Windows update, redeploy, power cut — the queue reloads automatically. Past-due calls dispatch immediately, future-due calls re-arm their timer. You do not lose a single planned dial. Use cases: post-stay feedback calls, appointment reminders, no-show follow-ups, payment reminders, courtesy callbacks, customer health checks, churn outreach. Anywhere a human-quality voice on the line beats an SMS or email. — 15 concrete outbound AI workflows → ### One curl away from your own system. CodeB ships with a small, focused REST surface and an HMAC-signed webhook system — the two halves of a self-hosted CPaaS . Initiate outbound AI calls, list virtual numbers, fetch transcripts, watch call lifecycle events stream in real time. Every endpoint has a single-line curl example. Bearer-token auth, JSON in and out, zero SDK needed. #### REST API v1 — the integrator surface POST a phone number + a system prompt to /api.ashx/v1/calls and CodeB dials the target, attaches a real-time voice AI session, and emails you the transcript when the call ends. GET to fetch active + recent calls, virtual numbers, full transcripts. POST to terminate an in-flight call. Pagination, error envelopes, no-cache responses — the platform behaves the way OAuth and Stripe taught the web to behave. Full reference: api-docs.html . #### Webhooks — events that find you Subscribe to call.ended , transcript.saved , outbound-ai.finished and seven other lifecycle events. The bridge POSTs an HMAC-SHA256-signed JSON payload to your URL within milliseconds of the event firing. Three retries with exponential backoff on failure; auto-pause after 20 consecutive failures so a broken endpoint doesn’t fill the queue. Test-fire button validates your endpoint before any real event flows. Configure subscribers from the admin dashboard. #### BYOC + AI + REST = self-hosted CPaaS The classic CPaaS pitch — programmable calling, SMS-free, no per-minute SaaS markup — runs entirely inside your IIS server. Your SIP trunks, your tenant’s data, your control over every prompt. The REST API and webhooks let you drop a voice-AI campaign into a CRM with a couple of lines of curl. Compare against Twilio, Vonage, Plivo on the CPaaS landing page . ### A phone that lives in the browser. Beyond ad-hoc meeting rooms, the same stack powers a registered identity that rings on incoming calls — from teammates or the PSTN trunk. Install it as a desktop app, leave it open, pick up calls all day. The phone you actually use, not a webpage you forget about. #### Three installable PWAs — one for each job CodeB ships three independent Progressive Web Apps on Windows, macOS, Chromebook and Android. Each one is a standalone window with its own dock/taskbar icon, its own home-screen tile, its own update cycle — no tab clutter, no browser involvement after install. - CodeB SoftPhone — handset icon. Your registered desk phone. Rings on incoming calls, lives in the dock, picks up PSTN and intra-team calls all day. Stays alive across browser tab discards. - CodeB Admin — gear icon. The operator console. Trunks, virtual numbers, webhooks, transcripts, REST API keys, weblogs — one tap from the home screen, no URL to remember. - CodeB Outbound AI — outbound-arrow icon. Schedule and dispatch AI voice campaigns. Per-call prompt, persona, retry policy, transcripts emailed on completion. All three coexist cleanly via service-worker scopes — install the ones you need, leave out the ones you don't. Self-updating: when a new build ships, each PWA notices, shows an "Update available" chip, one click rolls forward. Mid-call updates are deferred. #### Self-updating When a new build ships, the open phone notices within minutes and shows a small “Update available — reload” chip. One click rolls forward to the new version with no manual cache clears or admin involvement. Mid-call updates are deferred until the user is ready. #### Inbound calls ring your tab Register as a user (“anna”, “sales”, “reception”, …); the SIP bridge routes incoming PSTN calls and teammate calls to your tab with a familiar ringer, OS-level notification and accept/decline. Pick up — the meeting room opens with the caller already there. #### Browser-to-browser direct calls Type a name in the Call widget → that teammate's phone rings, peer-to-peer, no SIP trunk, no carrier minute. Type a number instead → the bridge dials through your configured trunks. One control, two backends, no mode switch. #### Auto-recovery from trunk loss If a PBX or SIP trunk reboots or drops off the network, the bridge notices, tears down the stale registration and re-registers within roughly a minute. Inbound calls resume without restarting the service. Surfacing in the trunk-log so operators can see exactly what happened. #### Operator visibility Built-in admin views show recent inbound and outbound calls, who routed where, and live trunk REGISTER state — useful when a caller says “I rang and no-one picked up” and you need to confirm whether it ever reached the bridge. All on-prem, no external dashboard required. ### Dial a camera. See and speak. An ONVIF security camera registered with the bridge appears in the CodeB Phone Call widget under a friendly name. Dial it — the camera streams its live feed straight to your browser, and the talkback button pushes your microphone back down the camera’s built-in speaker. Useful for door stations, reception cameras, warehouse intercoms, livestock and remote-site monitoring. Camera dial-ins require a signed-in user — anonymous connections are rejected at the signaling layer. Try the live demo: create an account (or sign in if you already have one), open CodeB Phone , then dial camera — that’s our public test alias pointing at a real ONVIF camera. You’ll see the live feed and can try talkback through its built-in speaker. Anonymous sessions cannot dial cameras. #### Call a camera by name Configure each camera with a short alias (“camera”, “reception”, “loadingbay”) in your bridge config. Type that name into the Call widget → live H.264 video opens in a dedicated viewer window, no extra app, no plugin. Our public demo is reachable simply as camera — sign in first, then dial it from the CodeB Phone. Camera names are reserved system-wide — nobody can register a CodeB Phone identity that would shadow a camera route. #### Two-way audio via ONVIF backchannel On cameras that expose the ONVIF backchannel profile (most Reolink, Hikvision, Dahua, Axis indoor units with built-in speakers), a single click on the talkback button routes your microphone back through the camera’s speaker. Push-to-talk through a door station, calm a barking dog, give a delivery driver instructions — without leaving the browser. #### Direct media, server stays out of the path The IIS signaling endpoint proxies only the SDP offer/answer exchange so the camera’s HTTP credentials never reach the browser. Once the call is up, WebRTC media flows directly between the browser and the on-prem camera relay — no transcoding service, no third-party relay, no per-minute media bill. The server CPU stays at idle even with several cameras live. #### Works with standards-compliant cameras Cameras connect via RTSP / ONVIF — the same protocols every prosumer IP camera already speaks. No vendor SDK, no cloud account, no firmware lock-in. Tested with Reolink and Hikvision; any camera that streams a Main/Sub RTSP profile with H.264 video and (optionally) AAC or G.711 audio fits in. #### Camera credentials never leave the server The bridge holds the camera’s HTTP Basic credentials in its local config and signs every upstream call itself. The browser only ever sees a friendly name and an SDP answer — never an RTSP URL, never a password, never a hostname. Rotate camera passwords on the device, update one config entry, done. #### Same surface as your phone calls You don’t learn a new tool. The camera viewer reuses the CodeB Phone’s end-call button, microphone mute, speaker mute, and ICE handling. Open and close cameras as casually as picking up the desk phone — same muscle memory, same look, same on-prem privacy guarantee. #### Sign-in required — no anonymous viewers Camera dial-ins are gated behind a CodeB Sovereign Communications account. A visitor who hasn’t signed in cannot dial camera , reception or any other camera alias — the signal handler rejects the call before the bridge is ever contacted. Every camera viewing is attributable to a named identity in the audit log, and operators can revoke a user’s access by disabling the account — no per-camera ACL maintenance required. ### What runs where. A handful of small pieces. Most are optional. None of them ever sees your video. #### IIS signaling A small WebSocket endpoint on the IIS side relays room joins, SDP offers/answers, and ICE candidates. The server stays out of the media path — it only helps peers find each other. #### CodeB SIP bridge (optional) A Windows Service that registers as a SIP extension on your PBX/trunks, bridges between WebRTC browsers and the carrier audio path, and keeps itself alive through reboots and network drops. STUN/TURN relay is built in — visitors behind strict firewalls or symmetric NAT connect through the same on-prem service; no extra tool to install, no third-party relay involved. Only needed if you want to talk to phones; without it the platform is pure browser-to-browser. #### CodeB camera relay (optional) A small RTSP → WebRTC translator that runs on the same host as the bridge and connects to your IP cameras over the LAN. Only needed if you want to call cameras from the phone surface; without it the platform is purely people and phones. #### Browser only — no client install Every participant joins from a regular HTTPS page. Camera, mic, screen share, file transfer, recording — all happens in the user agent. Optional install for the always-on phone surface; everything else is just a URL. ### Many tenants, one install. Operators run a single CodeB instance and host many independent customers on it. Tenant identity is the request domain — no shared accounts, no cross-tenant routing, no per-customer rebuild. Add a tenant by pointing a new hostname at the same host. #### Tenant = request domain A request for phone.acme.com routes to the Acme tenant; phone.contoso.com to Contoso. The signaling endpoint, the SIP bridge and the CDR writer all key off the Host header. No shared user table, no cross-tenant collisions. #### Per-tenant everything SIP credentials, trunks, FraudGuard caps, AutoReply rules, CDR files, registered SIP phones — all scoped to the tenant key. Tenant A’s misconfigured trunk can’t accidentally bill Tenant B; Tenant A’s rooms can’t be joined from Tenant B’s URL. #### Drop-in tenants Stand up a new customer by adding a hostname — DNS A record + IIS host binding + tenant config block. No schema migration, no restart of other tenants, no downtime for the existing customer base. The instance keeps serving the others while the new one warms up. #### Hosting-friendly economics One Windows host, one IIS site, one SIP bridge process — many tenants behind it. The marginal cost of adding a customer is the cost of a hostname. #### No accidental cross-talk Storage paths are tenant-prefixed: App_Data//appsettings.json , App_Data//logs/ , App_Data//logs/cdr/ , App_Data//sip-credentials/ . A bug or misconfiguration in one tenant can’t reach into another tenant’s data — the prefix is enforced at the file-system layer, not just convention. ### Single sign-on, built in. A full OpenID Connect identity provider runs inside CodeB. Sign-in lives on every page: a Sign in with CodeB button on the landing form prefills the participant name and stamps the in-call tile with a verified badge; the same button on the SoftPhone PWA auto-registers the right SIP identity; admin pages and any third-party RP (Nextcloud, custom apps) all federate against the same user database. See the OIDC details → #### OpenID Connect Core 1.0 Authorization Code flow with PKCE (S256), RS256-signed JWTs, discovery per RFC 8414, JWKS per RFC 7517. Anything that speaks OIDC plugs in — point it at /.well-known/openid-configuration and go. #### Cookie-free by design No session cookie. No tracking cookie. The login form mints the auth code directly, the callback exchanges for tokens, and the tokens live in per-tab sessionStorage — gone when the tab closes. If you advertise cookie-free, you stay cookie-free. #### One credential store Sign-in reuses the same HA1 hash your SIP phones use. Plaintext password never reaches the server — the browser hashes it before posting. One user record drives both voice and identity. #### Per-tenant RSA keys Each tenant gets its own 2048-bit signing key, generated on first need at App_Data//oidc/private-key.xml . Tokens minted for tenant A do not verify against tenant B. Rotate by deleting the file and recycling the app pool. #### Roles, server-enforced Three roles out of the box: admin , user , siponly , guest . The role travels in the JWT as a custom claim and a standard groups entry. Admin pages re-check the role on every server request — client-side checks are UI only. #### Integration guide Adding CodeB sign-in to any app that speaks OIDC takes about 10 minutes. Generic OIDC guide · Nextcloud · WordPress . #### Self‑service password reset Users who forget their password can reset it themselves via /recover.html — enter the email on file, click the one‑time signed link delivered to that mailbox (15‑minute TTL, single‑use JTI), set a new password. The MD5 HA1 digest is computed in the browser exactly like the regular login form, so the cleartext password never reaches the server. No‑enumeration design: all recover‑start outcomes return the same envelope, so attackers cannot probe which emails have accounts. Rate‑limited per IP and per email. ### Sign in with the EU Digital Identity Wallet. CodeB is integrating the EU Digital Identity Wallet (EUDI Wallet, eIDAS 2.0) into the OIDC identity provider that already ships with every tenant. The verifier endpoints are live today — both x509_san_dns and x509_hash client‑identifier schemes are accepted, and verified claims relay through OIDC userinfo. The customer‑facing "Sign in with EU Wallet" button goes live as soon as interop with the EUDI reference wallets completes and OIDF self‑certification opens. Per‑presentation metering and license‑gating are wired in. #### Sign in with EU Wallet Citizens with a national EU Digital Identity Wallet sign in, sign up and subscribe on every CodeB tenant using their wallet — verified identity, no password, no manual email round‑trip. The OID4VP 1.0 verifier runs SD‑JWT VC + DCQL queries with end‑to‑end JWE response encryption (ECDH‑ES + A128GCM), and supports BOTH Client Identifier Prefix schemes — x509_hash (mandated by HAIP 1.0 Final, OID4VP 1.0 §5.9.3) plus x509_san_dns (additional OpenID4VP compatibility mode, not HAIP 1.0 Final) — the caller of vp‑start picks per request. A spec‑compliant test wallet round‑trips against both prefixes today, returning verified PID claims and a signed SSO assertion. Wider real‑wallet interop lands as the EU Wallet ecosystem stabilises. See the proof of work → · Verifier API docs → · Free EU Wallet training (dial 1844) #### Verifier discovery endpoint The OID4VP 1.0 / HAIP 1.0 Verifier metadata is served from /oidc.ashx?action=verifier-metadata — client_id_scheme=x509_san_dns , ES256, SD‑JWT VC, ECDH‑ES encrypted responses. Enabled by default on every tenant so wallets and OIDF self‑certification tooling can discover us out of the box; operators set Vc:Verifier:Enabled=false only if they want to hide the capability. #### Per‑tenant ES256 keys Each tenant has its own P‑256 (ES256) keypair plus a self‑signed x5c chain with SAN bound to the tenant hostname — intended for development, testing and non‑HAIP OpenID4VP flows. Auto‑generated on first need — no operator setup — same install‑and‑run pattern as the OIDC RS256 key. Operators drop a production eIDAS‑issued PKCS #12 at the same path to override; the previous file is preserved as a .backup via NTFS atomic write. HAIP 1.0 Final production note. For HAIP 1.0 Final production deployments the verifier's request‑signing certificate MUST NOT be self‑signed — it MUST be issued by a Certificate Authority whose root is on the tenant's LOTL / trust anchor list. For European Digital Identity Wallet Relying Party operations, the certificate MUST be a Wallet‑Relying‑Party Access Certificate issued by the responsible Member State registrar. Operator‑supplied PKCS #12 replacement is the intended production path. #### Verified‑claim relay Wallet‑verified attributes (given_name, family_name, email, age‑over‑18, nationality) attach to the CodeB identity and flow automatically to every federated application via the standard OIDC userinfo response under a vc namespace. Nextcloud, custom backends, third‑party SaaS — all inherit verified identity without integrating wallet code themselves. One CodeB integration, every connected app benefits. #### Standards‑based OID4VP 1.0 (Final, July 2025), HAIP 1.0 high‑assurance interop profile, SD‑JWT VC credential format only, DCQL credential query language only (no PEX shim). Non‑qualified Electronic Attestation of Attributes scope — the built-in issuer mints tenant-membership credentials and, for demonstration and integration testing, PID-shaped credentials using the ARF-defined urn:eu.europa.ec.eudi:pid:1 credential type. These are not government-issued PID; genuine PID is reserved for Member State-notified providers with the required identity-proofing infrastructure and trust-anchor recognition. #### mso_mdoc / ISO 18013-5 credential verification CBOR‑decoded DeviceResponse with COSE_Sign1 issuer signature, trust‑anchor pinning, MSO validity check, DeviceAuth possession proof per OID4VP Annex B SessionTranscript. Requires operator‑loaded issuer certificates. #### HAIP §5.11 Wallet Attestation + PoP challenge Wallet Attestation JWT + PoP challenge — ES256/384/512 signature verification against a per‑tenant wallet‑provider anchor list; strict aud / nonce PoP with ±60 s iat window. Optional per‑tenant enforcement. #### OID4VP 1.0 FINAL — DCQL parity DCQL with claim_sets , claims[*].values filter, credential_sets.required=false , mDoc intent_to_retain audit; wallet attestation advertising in JAR. #### ARF‑native PID, Email, Address VCTs Issuer mints urn:eu.europa.ec.eudi:pid:1 (bundled given_name + family_name + birth_date + age_over_18 + age_in_years + age_birth_year per ARF §5.6.1), urn:eu.europa.ec.eudi:email:1 , urn:eu.europa.ec.eudi:address:1 . Refuses mint honestly when profile lacks mandatory ARF fields. #### Wallet‑side visual credential verification The web wallet re‑verifies every mDoc card in‑browser before display — CBOR decode, COSE_Sign1 signature, digest recomputation against nameSpaces , MSO validity. Tampered or expired cards render with a red badge. Verification runs against operator‑loaded issuer certificates; unknown issuers surface as “unverified” rather than green. #### LOTL-shaped trust store — full x5c chain‑to‑anchor validation The SD‑JWT VC issuer chain gate walks the full x5c chain up to an anchor in the tenant's operator‑loaded LOTL-shaped local trust store (a directory of X.509 anchors modelled on the ETSI TS 119 612 shape — not an official EU List-of-Trusted-Lists fetched from a Member State-notified endpoint), with basic path validation and expiry checks. Strict mode returns HTTP 400 on chain failure; non‑strict falls through to prior iteration behaviour. See the glossary for how this differs from the official EU LOTL. Requires the local trust store to have been populated at least once. #### mDoc cnf holder‑key binding OID4VCI mDoc mint now embeds a genuine cnf holder key inside the MSO — extracted from the wallet’s presented public JWK, converted to COSE_Key. Presentation‑time DeviceAuth proofs bind to that exact holder key. No more placeholder / self‑issued key. #### RSA holder‑key support in web wallet Wallet users can opt‑in to RSA‑2048 or RSA‑3072 holder keys for environments that require RSA (legacy HSMs, certain Member‑State PID stacks). ES256 remains the default — smaller keys, smaller signatures, wider EUDI ecosystem support. #### Split trust‑anchor overlays Per‑tenant trust overlays are now split by credential family — App_Data//trust/vc-issuers/ for SD‑JWT VC issuers, trust/mdoc-issuers/ for ISO 18013‑5 mDoc issuers. Operators enable each family independently. Legacy shared‑overlay path still works as a fallback (with a warning trace). #### Tenant‑issued credentials A future expansion will issue tenant credentials — "Member of tenant X", "Admin of tenant X" — that wallets store and present elsewhere. Non‑qualified EAA scope, SD‑JWT VC format, revocable via OAuth Status List. ### Sovereign WhatsApp Business Cloud API — bidirectional bridge, templates, abuse guard. A per‑tenant bridge to Meta’s WhatsApp Business Cloud API (Meta Graph API v20) — your Meta App, your Phone Number, your Access Token, every message and every media blob on your own IIS filesystem under App_Data//chat-whatsapp/ . Full chat.html integration both directions, message templates with live placeholder preview, template lifecycle admin, API‑key‑gated external send with optional template binding, a per‑day new‑chat abuse quota, and a live 24‑hour customer service window pill in the chat UI. See the WhatsApp Business landing page for the full write‑up. #### Bidirectional chat.html bridge Every inbound WhatsApp message from a customer creates (or joins) a per‑remote‑number group gc-wa- . Outbound replies typed in chat.html forward to Meta via a cross‑ .ashx loopback. Per‑user routing lets admins pick which internal users see WA groups — noise stays out of the wrong inboxes. #### Message template send with live placeholder preview Meta‑approved message templates are selectable from a picker in chat.html ’s new‑conversation modal. Each {{n}} placeholder gets its own input; the rendered preview updates as you type. Same flow works for cold outreach and for reopening an expired 24‑hour window. #### Template lifecycle admin /whatsapp-admin.html lists APPROVED, PENDING, IN_APPEAL and PAUSED templates from Meta, with per‑template Delete, a “Submit new template” form that validates placeholder count against example values before Meta’s review, and a preset button for the Brochterbeck‑host hospitality template as a working example. #### Template status toasts over WebSocket Meta’s message_template_status_update webhook events flow through as WebSocket toasts to every routing user’s chat.html . APPROVED renders green and auto‑dismisses; REJECTED, PAUSED and DISABLED render sticky red with Meta’s exact reason string so operators can act without opening the admin console. #### API‑key‑gated external send endpoint POST /whatsapp.ashx?action=send-external with header X-CodeB-WhatsApp-API-Key . Keys are 40 chars in the shape wa_live_<32 hex> , minted once (the plaintext value is shown once at generation, then masked forever), compared in constant time, and every auth failure returns a uniform 401 — no oracle on which field was wrong. #### Template‑bound API keys Each API key can optionally be pinned to one approved template plus a language. A bound key can ONLY send that template — free‑form is refused with 403 template-required , other templates with 403 template-mismatch , wrong language with 403 template-language-mismatch . Blast radius from a leaked key is exactly one Meta‑reviewed template. #### External template list endpoint GET /whatsapp.ashx?action=templates-list-external under the same API‑key auth. A bound key sees only its pinned template; an unrestricted key sees every APPROVED template. Third‑party integrations query it to render their own template pickers without holding Meta credentials. #### 3‑placeholder cap with placeholder metadata Templates are capped at 3 {{n}} placeholders per body (constant WA_TEMPLATE_MAX_PLACEHOLDERS ). Enforced at BOTH creation ( HandleCreateTemplate returns 400 too-many-placeholders for >3, plus 400 placeholder-gap when the indices aren’t sequential from {{1}} ) AND at send‑time ( HandleSendInternal + HandleSendExternal return 400 too-many-parameters for >3 body parameters). Both templates-list and templates-list-external now emit a per‑template placeholders: {count, indices, bodyText, exampleValues} object plus a top‑level maxPlaceholders: 3 , so callers build their parameters array without parsing {{n}} themselves. Meta accepts more but larger templates hurt WABA sender quality rating. #### Per‑day new‑chat abuse quota Configurable newChatsPerDayLimit (default 10, cap 10000, 0 = unlimited). Enforced atomically at send time on distinct outbound recipients per calendar day (UTC). Same‑day replies to open conversations don’t count. Applies to both send-external and the chat.html new‑chat flow. Per‑tenant counter file under App_Data//chat-whatsapp/ . #### Live 24‑hour customer service window pill Every WA group’s header shows a live pill: green “Window open · Xh Ym left” (measured from the customer’s last inbound OR your last successful template send) or amber “Window closed · template required” . Ticks every 60 seconds. Hover reveals whether the current window opened from an inbound message or from a template. #### Compose bar auto‑swaps to template picker When the 24‑hour window is closed, the normal text input is replaced by a template picker, per‑placeholder inputs and a live rendered preview above a Send button. Meta’s rule that free‑form is blocked outside the window is never a surprise — the UI never lets you type a message Meta would reject. When the customer replies, the input flips back over WebSocket without a reload. #### Routing users auto‑receive inbound as email Every routing user’s profile.email from the tenant’s sip‑credentials directory is auto‑added to the inbound‑forward list, deduped with the explicit CSV list operators have already configured. Adding a user to WA routing puts them on the email fan‑out automatically — no re‑typing team addresses. #### Expandable per‑event activity feed Each row in the “Recent activity” panel on /whatsapp-admin.html is a native
element. Click to see the full audit JSON — parsed request body, Meta response envelope, wamid , Meta error codes, kind ( text vs template ), template name. A Copy JSON button per row makes bug reports one click. Outbound rows now stamp the actual text sent OR the template name, so admins see WHAT was sent, not just Meta’s response envelope. #### wa.me click‑to‑chat as customer‑initiated entry The recommended customer‑initiated entry point is a wa.me/ click‑to‑chat link on your website or email footer. The customer’s message opens a fresh 24‑hour customer service window with no template required — the cheapest way to start a conversation. Documented on the WhatsApp Business landing page next to the template alternative. #### Multi‑tenant safe throughout Each tenant has its own Meta App credentials, its own API keys, its own per‑day quota counter file, its own audit trail — everything under App_Data//chat-whatsapp/ . Nothing crosses tenant boundaries, and deleting a tenant directory deletes every WhatsApp conversation and every secret with it. GDPR‑friendly by construction. ### Sign in with TouchID, FaceID, Windows Hello, or a hardware key. Every CodeB tenant supports passkeys end‑to‑end. Users register one from their account page on any modern OS (Apple iCloud Keychain, Android / Chrome, Windows Hello, hardware security keys), then sign in without a password — the private key never leaves the device, and the credential is bound to the tenant's domain so it cannot phish across sites. Per‑registration metering and license‑gating are wired in. #### Sign in with a passkey One-tap sign-in from any device that carries the credential. The flow is FIDO2 / WebAuthn end-to-end: the browser presents the user with whatever authenticator the OS prefers (TouchID, FaceID, Windows Hello, a hardware key on USB / NFC / Lightning), the device signs the WebAuthn challenge with the private key, and CodeB verifies the assertion against the public key it stored at registration. No password ever touches the wire; no one-time code; no shared secret. The dedicated sign-in page is at /loginpasskey.html and there's a "Sign in with passkey" button on the regular login page too. #### Tenant‑scoped credentials Per Phase 0 D‑8, every passkey is bound to the tenant hostname — the WebAuthn Relying Party ID (rpId) is the tenant FQDN (e.g. www.aloaha.com ), so a credential registered on one tenant cannot sign anyone in on another tenant served from the same CodeB install. The rpIdHash check inside the AuthenticationFacade is the cryptographic enforcement; the credential index is per‑tenant on disk. Phishing across look‑alike domains is impossible. #### User‑verification required (UV) Per Phase 0 D‑4, CodeB requires the User‑Verified (UV) flag on every registration and every assertion. That means the authenticator must actually verify the human — biometric or PIN — before signing. Mere presence (UP) is not enough. Authentication Method Reference is ["hwk", "user"] and Authentication Context Class Reference is urn:codeb:acr:hwk‑mfa , so downstream OIDC relying parties can demand strong-authentication via acr_values . #### Manage from the account page Users register, list and revoke passkeys from /account.html . Each credential shows a friendly name (defaults from the device User‑Agent — "iPhone", "Windows Hello on Stefan-Surface"), registration date, last-used date, backed-up state. Multiple passkeys per account — one per device — so losing a phone never locks you out as long as a second credential exists. #### Standards‑based FIDO2 / WebAuthn Level 3, CTAP 2 authenticators, COSE ES256 + RS256 algorithms, discoverable credentials (resident keys) for username‑less sign-in. Attestation is intentionally set to none so user privacy is preserved — we never collect the AAGUID to identify the user's device model. #### Choose at login: password · passkey · EU Wallet The login page offers all three side‑by‑side. Password keeps SIP phone compat (HA1). Passkeys give phishing resistance and modern UX. EU Wallet (when the verifier interop completes) gives government‑rooted verified identity. Whichever the user picks, downstream apps that consume our OIDC bearer see a consistent amr / acr claim and can apply policy uniformly. ### Frequently asked questions What features does CodeB include? CodeB includes browser meetings, real-time collaboration tools, a BYOC SIP bridge with click-to-call, an AI Digital Receptionist, outbound AI campaigns, a REST API with webhooks, a browser desk phone, ONVIF camera calling, multi-tenancy, an OIDC identity provider, EU Wallet sign-in, a WhatsApp Business Cloud API bridge and passkeys. The whole feature set runs on your own Windows and IIS server. How many participants can join a CodeB meeting? A CodeB meeting runs as a full-mesh peer-to-peer call for up to about six participants, with every browser sending directly to every other browser and no server in the data path. The CodeB comparison page adds that larger rooms are auto-promoted to a self-hosted SFU inside your own bridge, lifting the limit to around 30 active participants. Are CodeB meetings end-to-end encrypted? Yes. CodeB media uses DTLS-SRTP with keys negotiated peer-to-peer at call setup, so the server cannot decrypt the media and even a TURN relay only sees ciphertext. In-meeting chat and P2P file transfer run over encrypted WebRTC data channels and are not relayed by a server. Can I record a CodeB meeting? Yes. CodeB local meeting recording saves a WebM file (VP9 and Opus) straight to the recorder's machine, with nothing uploaded. A recording-consent gate asks every other participant to allow or deny before recording starts, and each recording can carry a forensic-grade sidecar with a SHA-256 hash, an ECDSA-P256 signature, the participants list and the consent decisions. Does CodeB work with any SIP trunk or PBX? Yes. CodeB supports true Bring Your Own Carrier with any standards-compliant PBX or trunk provider, from consumer routers to Tier-1 SIP wholesalers. Credentials stay in the bridge's local config, and multiple trunks can be defined with priority and automatic failover. You can switch carriers without changing CodeB. Can I use my own browser softphone with CodeB? Yes. Any standards-compliant browser softphone library, such as SIP.js, JsSIP, sipML5 or Linphone-WS, can register with a CodeB tenant using SIP over WebSocket (RFC 7118). A browser softphone can both place and receive calls, including PSTN calls through your trunk and calls to AI agents on virtual numbers. Does CodeB encrypt SIP signalling and media on the carrier leg? Yes, per trunk. CodeB supports SIPS (RFC 5630) on TLS ports TCP 5061 trunk-side and TCP 6061 public, with per-tenant certificates selected by SNI. SRTP via SDES (RFC 4568) encrypts audio between the bridge and the carrier, is off by default per trunk, and ends the call rather than falling back to plaintext if the peer rejects it. How does CodeB protect against toll fraud? CodeB only dials numbers on an operator-defined whitelist, supports an E.164 geographic prefix allowlist with a premium-rate blocklist, and applies per-call caps on concurrent calls, duration and daily call counts. An optional per-trunk rolling 24-hour cap refuses further outbound dials once reached, and every refusal is logged for audit. What does the CodeB AI Digital Receptionist do? The CodeB AI Digital Receptionist answers inbound calls with real-time, full-duplex voice AI that detects the caller's language and follows a per-number script. Each virtual number has its own prompt, voice and opening line. The receptionist can transfer to a whitelisted human, end the call with a logged reason, and email a transcript and summary after every call; a TTS fallback answers if the AI provider is unreachable. Can CodeB make outbound AI phone calls? Yes. A signed-in admin can schedule outbound AI calls up to 30 days ahead over your own SIP trunks, with automatic retries on no-answer or busy. The AI can transfer to a whitelisted human, and a transcript email is sent after every attempt. The schedule is persisted to disk and survives a server restart. Does CodeB have a REST API and webhooks? Yes. The CodeB REST API v1 has 7 endpoints, including POST /api.ashx/v1/calls to start an outbound AI call, with Bearer-token auth and JSON in and out. Webhooks deliver HMAC-SHA256-signed events such as call.ended and transcript.saved, with three retries and auto-pause after 20 consecutive failures. Can one CodeB install host multiple tenants? Yes. In CodeB the tenant is identified by the request domain, so one Windows host, one IIS site and one SIP bridge process can serve many customers. Settings, trunks, logs, CDRs and SIP credentials are stored under tenant-prefixed paths, and a new tenant is added with a DNS record, an IIS host binding and a tenant config block. Does CodeB include an OpenID Connect identity provider? Yes. CodeB runs a full OpenID Connect Core 1.0 identity provider with Authorization Code flow and PKCE (S256), RS256-signed JWTs and a per-tenant 2048-bit signing key. The IdP is cookie-free, stores tokens in per-tab sessionStorage, and enforces roles server-side. Adding CodeB sign-in to an OIDC-capable app takes about 10 minutes. Does CodeB support passkeys? Yes. Every CodeB tenant supports passkeys end-to-end with FIDO2 / WebAuthn Level 3, including TouchID, FaceID, Windows Hello and hardware security keys. Each passkey is bound to the tenant hostname, user verification (biometric or PIN) is required, and attestation is set to none so the device model is not collected. Can users sign in to CodeB with the EU Digital Identity Wallet? The CodeB OID4VP 1.0 verifier endpoints are live and accept both the x509_hash and x509_san_dns client identifier schemes, with SD-JWT VC and DCQL. Verified claims flow to connected apps through OIDC userinfo. The customer-facing Sign in with EU Wallet button goes live once interop with the EUDI reference wallets completes; PID-shaped test credentials from the built-in issuer are not government-issued PID. Does CodeB support WhatsApp Business? Yes. CodeB provides a per-tenant bridge to Meta's WhatsApp Business Cloud API, with messages and media stored on your own IIS filesystem. Features include two-way chat in chat.html, message templates with live placeholder preview, template-bound API keys, a per-day new-chat quota and a live 24-hour customer service window indicator. Can I call an ONVIF security camera from CodeB? Yes. An ONVIF camera registered with the CodeB bridge can be dialled by name from the CodeB Phone, opening its live H.264 feed in the browser, and cameras with an ONVIF backchannel support two-way talkback. Camera calls require a signed-in user, and camera credentials never leave the server. Does CodeB offer live call transcription? Yes, as a per-trunk option. When enabled, CodeB streams call audio to Google Gemini Live's speech-recognition channel using your own API key and writes a speaker-attributed transcript into the tenant's own storage. Transcripts can be emailed through your local SMTP pickup directory when the call ends. =================================================================== # Purchase CodeB · self-hosted licence or managed tenant # Source: https://www.aloaha.com/purchase.html =================================================================== > Try CodeB free, then choose self-hosted licence or managed private tenant. EU Wallet sign-in, BYOC SIP, AI receptionist, NIS2 / DORA. ## Take CodeB Sovereign Communications for yourself. Two ways to own a CodeB Sovereign Communications deployment that no third party can read, throttle, or shut down. Buy a perpetual on-premise license and run it on your own Windows Server. Or let us host it for you under your own domain. Either way, no analytics, no cloud middleman, no surprise SaaS lock-in. ### Run it on your own server. IIS · Windows Server · LAN or DMZ The complete codebase deployed onto a Windows Server you control. Signaling, TURN relay, recording sink and static assets all live behind your firewall. Air-gappable for regulated environments — defence, healthcare, manufacturing, public sector. Once installed, the deployment is yours; it keeps working whether or not you renew anything. - What ships: the static frontend (incl. the installable CodeB Phone PWA surface), the ASP.NET signaling handler, the on-prem TURN relay, an optional SIP bridge Windows Service for connecting to your PBX or trunk providers, deployment scripts and an install runbook. - Where it runs: any modern Windows Server with IIS and the .NET runtime. One small VM is enough for a department. - Operational ownership: your DNS, your TLS cert, your TURN secret, your SIP trunk credentials, your access logs. We never see your meetings. - Updates: source-available with versioned releases. Apply when you choose, including never. The PWA self-updates client-side on the next reload. - Best for: organisations with a "no cloud" rule, with a sensitivity profile that demands traffic stay inside the LAN, or who already operate Windows Server fleets. ### We host. You use your own domain. meet.yourcompany.com · fully managed We operate a dedicated deployment for you on CodeB infrastructure, fronted by your own domain (a CNAME or A-record you point at us). Your users see meet.yourcompany.com , not www.aloaha.com. The same privacy posture applies — your media never touches anyone's data lake, we don't add analytics, and your room logs are isolated to your tenancy. Zero operations burden on your side. - Custom domain: bring any subdomain you control. We supply the TLS certificate and renewal. - Isolated tenancy: separate IIS site, separate TURN credentials, separate logs. No shared signaling state with other customers. - SLA & uptime monitoring: 24/7 monitoring with named technical contacts. Standard SLA is 99.5%; higher tiers available. - Best for: organisations that want a private meeting tool but don't want to run a server themselves. ### The same product. The same posture. Both options deliver the full feature set of CodeB Sovereign Communications exactly as you've seen it on this site — no stripped-down "community edition", no upsell tier hidden behind a separate enterprise gate. Whether you buy the license or the managed hosting, you get: - Browser-based video, audio and screen sharing — Chrome, Edge, Firefox, Safari iOS 14+, Android Chrome - End-to-end DTLS-SRTP encryption between browsers — the server never sees plaintext media - Chat, file transfer, raise-hand, reactions, spotlight, picture-in-picture, document PiP - Local meeting recording with ECDSA-P256 signed evidence sidecars (forensic grade) - Recording-consent gate — every peer must Allow before recording starts, consent logged into the signed sidecar - Shared whiteboard everyone can draw on (pen, eraser, colours, undo) — synced over the chat data channel - Breakout rooms — split 2–4 groups, switch between them, late joiners can pick which to enter - Per-peer bandwidth adaptive ladder (720p → 480p → 360p → audio-only) — quality follows each link, not the slowest - Virtual background blur, per-tile volume sliders, audio "elevator brake", idle-camera dim - Knock-to-join for locked rooms, sticky notes on shared screens, Verified-by-CodeB badges - QR-code landing for one-scan mobile join - Built-in CodeBTurn relay for the ~10–20% of calls that need NAT traversal help - CodeB Phone desktop app (PWA) — installs from the browser, registers as a user, rings on incoming calls from teammates and the PSTN, self-updates client-side when you ship a new build - Browser-to-browser calling between teammates — direct, no SIP, no carrier minute - Optional SIP bridge — connect to your PBX or trunk providers; click-to-call from any web page; multi-trunk with priority and automatic failover; recovers from PBX reboots without service restart - Strict number whitelist + geographic prefix restriction + per-call fraud caps on outbound dialling - Built-in operator dashboards — live trunk-register state, inbound/outbound call logs — all on-prem, no third-party telemetry - Zero trackers, zero analytics, zero third-party JS in the call path — see the privacy manifesto - Source-available codebase — you can audit every byte before it ships For the full capability catalogue see the features page . For how the bytes actually move see the data flow page . ### Deployment tiers. Three shapes the product ships in. Pick the one that matches how your IT runs, then ask us for a quote — pricing depends on user count, deployment shape, custom branding, and whether you want our support attached. Run it on your own Windows Server. Talk to us — we’ll quote against your situation. Up to 10 CodeB Webphone users. Perpetual license. Includes the SIP bridge service. - Full source-available codebase - On-prem TURN relay included - Email support, 1 year - Optional maintenance subscription for updates — quoted with the license For organisations with a real PBX. Talk to us — we’ll quote against your situation. Up to 50 CodeB Webphone users. Perpetual license. SIP bridge + multi-trunk failover + REGISTER for external SIP phones. - Everything in Starter - Priority email + chat support, 1 year - One install assistance session - Optional maintenance subscription for updates — quoted with the license We operate it under your domain. Talk to us — we’ll quote against your situation. Single-tenant deployment on CodeB infrastructure, fronted by meet.yourdomain.com . Zero ops burden on you. - Custom domain + TLS we manage - Isolated tenant (no shared signaling) - 99.5% standard SLA, higher tiers available - Walk away with your data any time Pricing depends on user count, deployment shape, and any branding work. Drop us a note via info@aloaha.com describing your situation and we’ll come back with a fixed quote within one business day. ### Tell us what you need. Pricing depends on user count, deployment shape (on-prem vs hosted), domain configuration and any branding work. Send us a short note describing your situation and we'll come back to you with a fixed quote — usually within one business day. Direct line — no sales chatbot. Replies from a real engineer, usually within a business day. #### Want to talk through specifics first? If you'd rather discuss requirements live — compliance constraints, sizing, custom feature work, integration with your existing identity provider — drop the same line to info@aloaha.com and ask for a 30-minute technical call. Time-zone friendly across Europe, the Middle East and North Africa. ### Frequently asked questions How much does CodeB cost? CodeB does not publish list prices; every deployment is quoted individually. Pricing depends on user count, deployment shape (on-premise or hosted), domain configuration, branding work and whether support is attached. Send a short note to info@aloaha.com and Aloaha Limited replies with a fixed quote, usually within one business day. What are the ways to buy CodeB? There are two options. Option A is a perpetual on-premise license that you run on your own Windows Server. Option B is a managed deployment that Aloaha Limited hosts for you on CodeB infrastructure under your own domain. Is the CodeB on-premise license perpetual? Yes. The CodeB self-host Starter and Team tiers are perpetual licenses, and once installed the deployment keeps working whether or not you renew anything. Updates are available through an optional maintenance subscription quoted with the license, and you apply releases when you choose. What is included in the CodeB on-premise license? The CodeB on-premise license ships the static frontend including the CodeB Phone PWA, the ASP.NET signaling handler, the on-prem TURN relay, an optional SIP bridge Windows Service for your PBX or trunk providers, deployment scripts and an install runbook. The codebase is source-available with versioned releases. What server do I need to run CodeB? CodeB runs on any modern Windows Server with IIS and the .NET runtime, in your LAN or DMZ. One small VM is enough for a department, and the deployment is air-gappable for regulated environments. What does the CodeB hosted option include? With the hosted option, Aloaha Limited operates a dedicated CodeB deployment on CodeB infrastructure, fronted by a subdomain you control. Aloaha supplies the TLS certificate and renewal, and the tenancy is isolated with a separate IIS site, TURN credentials and logs. The standard SLA is 99.5% with 24/7 monitoring, and higher tiers are available. What CodeB deployment tiers are there? CodeB ships in three tiers plus an enterprise option. Self-host Starter covers up to 10 CodeB Webphone users, Self-host Team covers up to 50 users with multi-trunk failover and REGISTER for external SIP phones, and Hosted by us is a single-tenant deployment under your domain. Enterprise with source access covers more than 50 users, air-gapped install runbooks or custom integrations. Do the self-hosted and hosted CodeB options have the same features? Yes. Both options deliver the full CodeB Sovereign Communications feature set, with no stripped-down community edition and no upsell tier behind a separate enterprise gate. What support is included with a CodeB license? The CodeB Self-host Starter tier includes email support for 1 year. The Self-host Team tier includes priority email and chat support for 1 year plus one install assistance session. Enterprise agreements usually include source and support for the territories you operate in. Can I try CodeB for free before buying? Yes. You can try CodeB free and then choose a self-hosted licence or a managed private tenant. The CodeB homepage describes a free evaluation tenant with no card, no contract and no auto-billing. Can I leave the CodeB hosted service and keep my data? Yes. The Hosted by us tier states that you can walk away with your data at any time. The on-premise deployment is yours once installed and keeps working without renewal. How do I buy CodeB? Email info@aloaha.com describing your situation, or call directly; replies come from an engineer, usually within one business day. If you want to discuss compliance constraints, sizing, custom features or identity provider integration first, ask for a 30-minute technical call. =================================================================== # CodeB Business Intelligence — run your entire short-let business from one dashboard # Source: https://www.aloaha.com/business-intelligence.html =================================================================== > CodeB Business Intelligence is the 5-in-1 platform for short-let & vacation-rental operators. Unifies Hostaway, RentalsUnited & Channex into one reservation pool; per-property marketing websites & hotel room types; Nuki smart-lock PINs; free channel rate calculator; owner P&L; offline-first. Built in Malta by Aloaha Limited. ## Run your entire short-let business from one dashboard. CodeB Business Intelligence unifies every channel, every apartment and every euro — live operations, revenue insight, guest communication and your own booking website, all in one place. Offline-first, so you never stop working. Built in Malta by Aloaha Limited . ### One platform for your whole operation From this morning’s check-ins to this quarter’s owner statements — every part of a short-let business, working together and reconciling to the cent. #### 📈 Live operations board Today’s arrivals, departures, stay-overs, new bookings and same-day turnovers — the whole day at a glance, refreshed live. #### 💴 Revenue intelligence & Finances hub Revenue, cash-flow, forecast, ADR & occupancy, weekly pick-up and full owner P&L. A Finances hub pulls invoices, expenses and P&L together per property, per booking and per period. #### 🔌 Every channel, one pool Hostaway , RentalsUnited and Channex merge into a single reservation pool. Hostaway-compatible and RentalsUnited-compatible facade APIs let existing partner integrations point at you unchanged. #### 🏘 No channel manager? No problem Run a property entirely in-app as its own Local channel — details, categories, rooms & bed sizes, photos, rates with a minimum floor, cleaning & linen fees, taxes, reviews and invoices, all synced to your booking website. #### 🏠 Your own booking website & grouped storefronts A white-label storefront with live availability, enquiries and two-way iCal sync — take direct, commission-free bookings. Add grouped storefronts on their own domain, each showing a hand-picked set of properties from any channel, while the main storefront stays untouched. #### 🎨 Per-property marketing websites Built-in website builder with themes, a visual text editor, a media library, rotating hero images, blog posts, gallery, per-room pages and an availability search. Update a theme once and every site follows without a rebuild. Live example: brochterbeck.com . #### 🏨 Hotels & room types One property, many bookable rooms with live per-room availability & prices, rate plans, per-room-type ARI , whole-hotel and derived rates, and a Channex /HomeAway-shaped export to distribute to OTAs. #### 🔑 Smart locks — Nuki keyless entry CodeB pushes a unique keypad PIN to the Nuki lock for every booking, time-limited to the stay. The code opens just before check-in, self-expires after check-out and is removed automatically. Stay-extend re-times the same code in one click. Guests see the PIN in their check-in portal; staff read the live code on the Check-ins dashboard. #### 🏷 Promo & discount codes Percentage or fixed discounts on direct bookings, scoped to chosen properties, with validity dates, minimum nights or spend, and usage limits — validated live on your storefront. #### 🧾 Free channel rate calculator Public, no login. Enter your target payout and get the nightly price to charge on Booking.com, Airbnb, Vrbo and HomeToGo after commissions, bank fees and guest fees. pms.brochterbeck.com/rate-calculator → #### 💬 Unified guest inbox & AI calling Every guest conversation in one inbox, plus AI-assisted outbound calls with full transcripts — never miss a message or a check-in call again. #### 🧹 Housekeeping & turnovers A 30-day turnover board with same-day back-to-backs, cleaning tasks and required items — cots, high chairs, extra beds — so nothing is missed. #### 📈 Reviews, pricing & pace All-channel reviews, a per-listing pricing & availability calendar, and a pace report that shows how the coming months are filling up. #### 🌐 SEO & GEO built-in Seven languages — German, English, Maltese, Dutch, French, Italian, Spanish — with hreflang, JSON-LD, per-page titles & meta, SEO-named alt-tagged images and auto sitemaps. #### 📜 Online check-in & German Meldeschein Online guest check-in captures guest IDs and produces a signed German Meldeschein per BMG §§29–30 , multi-traveller and printable. #### 💾 Your-own-cloud backups Scheduled backups of all data to your own Nextcloud or WebDAV , admin-gated and offline-first — data never leaves your infrastructure. #### 🛡 Offline-first & secure Every dataset is cached locally, so the portal keeps running even when a channel or the internet drops. SSO sign-in, role-based access and GDPR pages included. #### 🔧 Open API & integrations API-first. Exposes Hostaway -compatible and RentalsUnited -compatible APIs so partners integrate unchanged, plus an open REST API with a published OpenAPI spec. #### 👤 Access, door codes & teams Property addresses, GPS and door codes flow to the right people, with staff roster, contacts and inventory. Meldeschein and Nuki access ride on the same dashboard. ### Live in days, not months Connect what you already use and CodeB does the rest — quietly, in the background, all day. ##### Connect your channels Link Hostaway , RentalsUnited and Channex with a few keys, or run the Local channel in-app. ##### Data syncs itself Properties, bookings, guests and calendars flow in and cache offline-first. ##### Run the day Operations, housekeeping and guest messages — all from one screen. ##### Grow revenue Forecast, price and report — and take direct bookings on your own site. ### Free channel rate calculator — no login Enter your target payout and get the nightly price to charge on Booking.com, Airbnb, Vrbo and HomeToGo — after commissions, bank fees and guest fees are factored in. Public, no sign-up, no strings. Commissions are calculated on the total booking value including the cleaning fee: Booking.com ~15%, Airbnb ~15.5%, Vrbo 5% + 3% payment processing, HomeToGo ~15% (or 3% split). ### Everything CodeB can do — a plain-English tour A quick reference to every feature. Full step-by-step docs live in the guide . ### Who it’s for ##### Short-let & holiday-let operators Portfolios from a handful to hundreds of units. Multi-property, multi-owner, multi-channel — with a public website that never drifts from the operational data. ##### Boutique hotels & B&Bs All the operational modules you need without the enterprise-PMS price tag. The AI receptionist answers overflow at 3 a.m. in the guest’s language. ##### Property-management companies Onboard each owner as a sub-tenant, invoice them via owner statements, and give them a login into their own slice of the dashboard. ##### Vacation-rental franchises One codebase, one comms stack, dozens of tenant subdomains. Central brand, local operators, per-tenant isolation. ### Built on the CodeB platform — not a fresh stack Business Intelligence is not a separate product with its own database, its own login and its own phones. It is a top-level view on the same tenant that runs the phone system, the AI receptionist, the SBC and the identity broker. That is why the Meet button just works, why the Chat sidebar shares one bubble style with /chat.html , and why a call from “Call Personal” is a normal CodeB SIP call with the usual recording, transcription and CDR. #### Comms Meet uses the CodeB SFU — up to hundreds of participants per room, TURN with SDES-SRTP, RFC 5630 SIPS and RFC 4028 Session-Timer under the hood. #### Identity OIDC sign-in via /oidc.ashx . Every write in Operations, Team and Properties is stamped with the OIDC subject and lands in History. #### AI Guest calls to your vnum route through the CodeB AI receptionist with live reservation context from the same platform — opening hours, arrival codes, unit numbers. #### Recording & transcript Any call — guest inbound, front-desk outbound, or the “Call Personal” button — can be recorded with per-tenant retention and live transcription. #### Channel managers Hostaway , RentalsUnited and Channex plug in via first-party connectors. Reservations, guests and property data sync both directions. Source-picker in the top-right dropdown. #### API + webhooks Full REST + webhook surface documented alongside the rest of the CodeB API. Automate housekeeping tickets, owner reports, arrival notifications. ### Frequently asked What is CodeB Business Intelligence? A web-based, all-in-one platform for short-let and vacation-rental operators. It brings live operations, revenue analytics, every booking channel, guest communication and your own booking website into one dashboard — and works offline-first, so your team keeps running even if a channel or the internet drops. Which channels and systems does it connect to? It unifies Hostaway , RentalsUnited and Channex into a single reservation pool, and exposes Hostaway-compatible and RentalsUnited-compatible facade APIs so partners integrate with you unchanged. Calendars sync both ways over iCal. Does it work when a channel or the internet is down? Yes. Every dataset is cached locally offline-first, so pages keep serving the last good data and reconcile automatically once the connection returns. Is it secure and GDPR-compliant? Yes. Access is behind single sign-on with role-based permissions, guest data is protected, and the platform ships GDPR and imprint pages plus an EU image proxy. Only the public marketing and help pages are open — everything else requires a login. Do I have to use a channel manager? No. You can run a property entirely in-app as its own Local channel — property details, categories, rooms & bed sizes, photos, rates with a minimum floor, cleaning & linen fees, taxes, reviews and invoices, all synced to your booking website. If you already have Hostaway , RentalsUnited or Channex , plug them in and CodeB reads reservations from them alongside the Local channel. A dropdown at the top-right of the dashboard lets you flip between sources. Is there a free channel rate calculator? Yes — public, no login. Enter your target payout and get the nightly price to charge on Booking.com, Airbnb, Vrbo and HomeToGo after commissions, bank fees and guest fees. pms.brochterbeck.com/rate-calculator . How much commission do Booking.com, Airbnb & Vrbo charge? Booking.com around 15% , Airbnb around 15.5% , Vrbo 5% + 3% payment processing, HomeToGo around 15% (or a 3% split model). Commissions are calculated on the total booking value including the cleaning fee. Use the free rate calculator to see the exact net payout for your own numbers. Can I build a website for each property? Yes. A built-in website builder gives each property its own marketing website with themes, a visual text editor, a media library, rotating hero images, blog posts, a gallery, per-room pages and an availability search. Update a theme once and every site follows without a rebuild. Live example: brochterbeck.com . Which languages does it support? Seven languages out of the box: German, English, Maltese, Dutch, French, Italian, Spanish . Public pages ship hreflang, JSON-LD, per-page titles & meta, SEO-named alt-tagged images and auto sitemaps. Does it work for hotels, not just apartments? Yes. One property can have many bookable rooms with live per-room availability & prices, rate plans, per-room-type ARI , whole-hotel and derived rates, and a Channex /HomeAway-shaped export to distribute to OTAs. Can guests check in online (German Meldeschein)? Yes. Online guest check-in captures guest IDs and produces a signed German Meldeschein per BMG §§29–30 , multi-traveller and printable. Does it support keyless entry & smart locks (Nuki)? Yes. CodeB pushes a unique keypad PIN to the Nuki lock for every booking, time-limited to the stay. The code opens just before check-in, self-expires after check-out and is removed automatically. Stay-extend re-times the same code in one click. Guests see the PIN in their check-in portal; staff read the live code on the Check-ins dashboard. Does CodeB have an API? Yes. CodeB is API-first. It exposes Hostaway -compatible and RentalsUnited -compatible facade APIs so partners integrate with you unchanged, plus an open REST API with a published OpenAPI spec, secured with API keys or SSO tokens. What does “multi-tenant” mean here? Each customer gets their own CodeB tenant on their own subdomain, with their own data directory under App_Data// , their own users, their own OIDC realm, their own recordings and their own audit log. Nothing crosses. A property-management company can also run nested tenants for each owner they manage. Where is the data hosted? EU by default. You can also self-host on your own IIS with the CodeB bridge alongside — the same install serves this platform, the phone system, the SBC and the OIDC identity broker. Data never leaves your VM. How does the AI receptionist see live reservations? The Voice AI vnum reads the same platform via the same tenant scope. A guest asking “what’s my check-in code?” gets the answer for their reservation on their unit, not a generic script. See the AI receptionist page for the plumbing. Does Meet / Chat / Call really share the phone system? Yes. Meet opens /room.html with your OIDC session, Chat opens /chat.html as the same signed-in user, and “Call Personal” dials via the CodeB SIP softphone. Signed-in participants get their in-meeting chat auto-archived to their own chat history — the archive lives in the same tenant as the rest of the data. Who builds it? CodeB Business Intelligence is developed by Aloaha Limited in Malta. ### Ready to run everything from one place? See the platform your team will actually enjoy using. We can bring up a fresh CodeB tenant for you, wire the channel-manager integration, and give you a walk-through of the dashboard — usually in an afternoon. No lock-in, no per-property surcharge for the comms stack, no separate website contract. =================================================================== # CodeB OIDC — OpenID Connect + EU Wallet sign-in, x509_hash live Sovereign Communications # Source: https://www.aloaha.com/oidc-features.html =================================================================== > Built-in OpenID Connect identity provider with OID4VP 1.0 EU Wallet sign-in. x509_hash mandated by HAIP 1.0 Final (OID4VP 1.0 §5.9.3, wallet-preferred), plus x509_san_dns as an additional OpenID4VP compatibility mode (not HAIP 1.0 Final). Cookie-free, PKCE-only, RS256, per-tenant RSA keys. ## Single sign-on, built in. CodeB ships with its own OpenID Connect identity provider. Sign-in lives on every page: a button on the landing form gives joiners a verified-in-call badge, the same button on the SoftPhone PWA auto-registers their SIP identity, and admin + third-party apps (Nextcloud, custom RPs) all federate against the same per-tenant user database. Cookie-free, PKCE-only public clients or confidential clients with a secret — pick what fits. Built by Aloaha Limited — a Malta-based European sovereign-tech vendor. The IdP + wallet-verifier stack, from RS256 tokens to OID4VP direct_post , is written in-house against published RFCs. No third-party EUDI SDK anywhere in the dependency tree; the code stays inspectable and the release cadence stays ours. 2026-07-18 · Passed all 35 tests of the OpenID Foundation Basic OP Certification Profile (suite 5.2.0) with zero failures, zero warnings . See the conformance page → OIDC is on by default. Discovery URL: https:///.well-known/openid-configuration Adding it to your own site? → Read the integration how-to · See the data flow ### What you get #### EU Wallet sign-in LIVE The OID4VP 1.0 verifier substrate is shipped. Any spec-compliant EU Digital Identity Wallet (EUDI Wallet) can sign in, sign up or subscribe on a CodeB tenant. ES256-signed Authorization Requests, DCQL queries, JWE-encrypted responses, SD-JWT VC selective disclosure — relayed through the OIDC userinfo your relying parties already consume. Feature overview · Try it · Proof of work · API docs · Free training (dial 1844) #### Three methods, one screen Password, passkey (FIDO2 / WebAuthn) and EU Wallet (EUDI) sign-in live side-by-side on the same /login.html — equal weight, no hierarchy, no third URL to remember. Magic-link email sign-in is one click below. Relying parties can deep-link a specific method with ?method=passkey / ?method=eu-wallet / ?method=password so Nextcloud, WordPress and other OIDC clients can route users straight to the right flow. Try the picker · Passkey flow · EU Wallet flow #### Standards-based OpenID Connect Core 1.0, Authorization Code flow with PKCE (S256), RS256-signed JWTs. Discovery per RFC 8414, JWKS per RFC 7517. Any RP that speaks OIDC will work. #### Cookie-free, honestly No cookies anywhere — not session, not tracking. Sign-in across multiple RPs uses a signed, 30-minute, same-origin assertion in localStorage at the IdP origin: never sent to other sites, never used for cross-site tracking, cleared on logout. Per-tab access & refresh tokens live in sessionStorage and vanish when the tab closes. Full design on the data-flow page . #### One credential store Sign-in reuses the same HA1 digest your SIP phones use. No plaintext password ever reaches the server — the browser hashes it before posting. One user record drives both voice and identity. Why HA1 specifically: CodeB uses SIP-compatible HA1 digests so the same user record drives both the SIP phone (which requires digest-auth per RFC 3261) and OIDC sign-in. HA1 is treated as a password-equivalent secret and stored with the same care. #### Per-tenant keys Each tenant gets its own 2048-bit RSA signing key, generated on first need and persisted to App_Data//oidc/ . Tokens minted for tenant A never verify against tenant B. #### Roles, not just identities Four roles out of the box: admin , user , siponly , guest . The role travels in the JWT as a custom claim and as a standard groups entry. Per-user custom groups can be set in the admin UI to feed Nextcloud / RP membership directly into the token. Admin pages enforce role === "admin" server-side on every request. #### Verified-in-call badge Sign in on the landing page before joining and your conference tile shows the amber CodeB shield to every participant. Anti-impersonation for free, no third-party identity provider, no Zoom-style verified-name extension required. #### Passwordless email-link sign-in Users who'd rather not type a password (or who forgot it on a phone they're handed) tap “Email me a sign-in link instead” on the login screen, enter their email, and a one-time link arrives in their inbox. Click it — signed in. Single‑use, 15-minute TTL, no enumeration on the start envelope. AMR ["user"] and ACR urn:codeb:acr:email-link mark it as a weaker factor than password so RPs can require step‑up for sensitive operations. #### One passkey, every app Register a single FIDO2 credential (TouchID/FaceID/Windows Hello/hardware token) on the CodeB IdP once. From then on every relying party — Nextcloud, WordPress, GitLab, your CRM, custom apps — gets phishing‑resistant authentication for free, because they all just do the standard OIDC dance against your CodeB host. The RP never touches the passkey, never sees the credential, never has to implement WebAuthn. It consumes a signed ID token with amr: ["hwk","user"] and acr: urn:codeb:acr:hwk-mfa , and that's it. Compounding effect: - One credential to manage — one revoke if the laptop is lost, RP-Initiated Logout signs the user out of every connected app. - Any RP can demand step-up by checking the acr claim — sensitive operations require passkey, casual ones accept password. - Adding a new app to your stack costs zero auth work; it inherits the existing factor matrix. - If you also store EU Wallet verified claims at the IdP, those flow through too — the RP sees given_name , family_name , birthdate from a government‑rooted source without any wallet-specific code. #### Authenticator app (TOTP) Users who don't want to register a passkey can still strengthen password sign-in with a standards-compliant time-based one-time password (TOTP, RFC 6238). Scan the QR code in /account.html with any authenticator app — Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden, Authy — and the login form asks for a 6-digit code after the password. 8 single-use recovery codes are generated at enrolment for the “phone in the washing machine” case. An email fallback can send a short-lived 6-digit code to the address on file. The shared secret lives encrypted in App_Data//users//totp.json , never on a vendor's server. Enrol, verify and disable are all audit-logged to the same OIDC audit feed as everything else. Passkey and EU Wallet sign-ins skip the TOTP step — they are already strong factors on their own. For the “lost everything” case — authenticator gone, recovery codes lost, email unreachable — an admin can clear a user's TOTP enrolment from the /register.html user-edit popup with one click. The override is audit-logged with both the admin and the target user. Brute-force protection: every failed verify bumps a per-session attempt counter, and the session is destroyed after 5 wrong codes — the attacker has to start a new password+TOTP flow from scratch, not just keep guessing the same session. #### Authentication factor in the token Every id_token + access_token carries amr (RFC 8176) and acr . RPs see the actual factor — ["pwd"] for password, ["hwk","user"] for FIDO2 passkey — and can require step-up auth where it matters. #### Hot key rotation Two signing keys can be active at once. Rename private-key.xml → private-key-previous.xml ; the next request generates a fresh active key. JWKS publishes both, the kid in each token pins it to the right one. No IIS recycle, no dropped sessions. #### Token revocation (RFC 7009) POST a refresh token to /oidc.ashx?action=revoke to end a session immediately on the IdP side. Confidential clients authenticate with their secret; public clients revoke without auth. Always returns 200 to prevent token-validity enumeration. #### Integration guide Adding CodeB sign-on to your own app takes a config block. The OIDC how-to walks through discovery, PKCE, token validation and refresh, with copy-paste samples in vanilla JS and Node/Express. ### The endpoints Standard OIDC URLs. RPs typically only need the discovery URL — everything else is auto-discovered. Endpoint | Purpose /.well-known/openid-configuration | Discovery document. RFC 8414. Lists every other endpoint and the supported algorithms. /.well-known/jwks.json | JSON Web Key Set. RFC 7517. The tenant’s RSA public key, so any RP can verify signatures. /oidc.ashx?action=authorize | Authorization endpoint. Redirects to the login form, then back to the RP with an auth code. /oidc.ashx?action=token | Token endpoint. Exchanges the auth code (with PKCE verifier) for an access token, ID token, and refresh token. /oidc.ashx?action=userinfo | UserInfo endpoint. Returns the signed-in user’s sub, role, profile claims. /oidc.ashx?action=end_session | RP-Initiated Logout 1.0 (OIDC). Clears tokens client-side, redirects to post_logout_redirect_uri after validating it against the client's registered list. /oidc.ashx?action=passkey-signin-start | Passkey (FIDO2 / WebAuthn) sign-in — mints a PublicKeyCredentialRequestOptions JSON for the browser to feed to navigator.credentials.get() . No bearer required: the passkey itself is the authentication. /oidc.ashx?action=passkey-signin-finish | Receives the signed WebAuthn assertion, verifies it (rpIdHash, signature, counter regression check), and emits the same shape as /login — {ok, redirect, user, role, sso_assertion, sso_max_age} . AMR ["hwk","user"] , ACR urn:codeb:acr:hwk-mfa . /oidc.ashx?action=recover-start | Self‑service password recovery, step 1. POST {email} . Always returns the same 200 envelope regardless of whether the email matches a user (no enumeration). If found, mints a one‑time JWT ( typ=recover , single‑use JTI, 15‑minute TTL) and emails the reset link. Rate‑limited per IP and per email. /oidc.ashx?action=recover-finish | Self‑service password recovery, step 2. POST {token, new_ha1} . Verifies the JWT (sig/exp/iss/typ), atomically claims the JTI in _usedRecoverJtis (single‑use), rejects the all‑zeros HA1 sentinel, then calls UpdateUserHa1Atomic . Returns {ok, redirect: "/login.html?recovered=1"} . ### Wire up an RP in three lines Any OIDC-compliant relying party works. Point it at the discovery URL, use the public client ID codeb-admin , and you’re done. The discovery document fills in authorization_endpoint , token_endpoint , jwks_uri , id_token_signing_alg_values_supported and the rest automatically. ### What the ID token looks like RS256-signed JWT. Standard OIDC claims plus a tenant-scoped role and any profile fields the admin filled in for that user. ### Cookie-free, by design OIDC implementations typically lean on a session cookie at the IdP to keep the user "signed in" across /authorize calls. CodeB doesn’t. The login form parses the original authorize URL, validates the PKCE challenge and redirect URI server-side, mints the auth code directly, and posts it back as JSON. The browser navigates to the RP’s callback without ever bouncing through a cookie-bearing redirect. That keeps the privacy posture honest: no cookies anywhere on the CodeB site , OIDC included. If you advertise cookie-free, you stay cookie-free. ### EU Digital Identity Wallet sign-in CodeB’s OIDC layer accepts the EU Digital Identity Wallet (EUDI Wallet) as a first-class sign-in method. The verifier substrate — OID4VP 1.0 with the HAIP 1.0 client_id scheme, DCQL credential queries, ECDH-ES + A128GCM JWE-encrypted responses, SD-JWT VC parsing with KB-JWT holder binding — was shipped on 2026-06-08. The verifier passed the OpenID Foundation-hosted OID4VP 1.0 Final + HAIP 1.0 Final alpha suite on 2026-07-19 (9 tests, 0 fail, 0 warn) against a spec-compliant test wallet. Interop with additional real-wallet builds is tracked in the per-Member-State matrix . For relying parties this changes nothing: the verified credential claims are relayed through the same /oidc.ashx userinfo endpoint and ID token your application already consumes. A user sign-in via password, smart card, or EU Wallet looks identical at the RP layer — the amr claim tells you which factor was used. From December 2027, private-sector relying parties that are required by Union law, national law or contractual obligation to use strong user authentication for online identification — and qualifying very large online platforms under the Digital Services Act — must accept the EU Digital Identity Wallet when the user voluntarily chooses it (eIDAS 2.0 Article 5f). Microenterprises and small enterprises are excluded from the mandatory-acceptance scope. Named sectors include banking, financial services, transport, energy, social security, health, postal services, digital infrastructure, education and telecommunications. CodeB tenants have the verifier live today; on the day the rule turns on, the stack is already in place. Full feature overview → · Try the live flow → · Verified proof of work → · Public verifier API → What’s in scope today, honestly: the verifier walks the full x5c chain of the SD‑JWT VC issuer up to an anchor in the tenant's operator‑loaded LOTL-shaped local trust store (a directory of X.509 anchors modelled on the ETSI TS 119 612 shape — not an official EU List-of-Trusted-Lists fetched from a Member State-notified endpoint). Trust anchors for issuer families the operator has vetted live under App_Data//trust/vc-issuers/ (SD‑JWT VC) and trust/mdoc-issuers/ (ISO 18013‑5). Production high‑assurance identity proofing still requires a notified national wallet issuing PID. OpenID Foundation self‑certification for OID4VP 1.0 + HAIP 1.0 is in progress. ### Wallet Attestation, DCQL FINAL & mDoc verification Beyond the OID4VP protocol substrate above, the verifier now advertises: - HAIP §5.11 Wallet Attestation JWT + PoP challenge — ES256/384/512 signature verification against a per‑tenant wallet‑provider anchor list; strict aud / nonce proof‑of‑possession with a ±60 s iat window. Enforcement is opt‑in per tenant — when off the JWT is validated but never required. - OID4VP 1.0 FINAL — full DCQL parity — claim_sets , claims[*].values filter, credential_sets.required=false , and mDoc intent_to_retain audit trail. Wallet Attestation is advertised inside the JAR request object. - mso_mdoc / ISO 18013‑5 credential verification — CBOR‑decoded DeviceResponse with COSE_Sign1 issuer signature, trust‑anchor pinning, MSO validity check, DeviceAuth possession proof per OID4VP Annex B SessionTranscript . Requires operator‑loaded issuer certificates under trust/mdoc-issuers/ ; otherwise the endpoint returns HTTP 501 mdoc_verify_not_configured rather than silently accepting. - Wallet‑side visual credential verification — the browser wallet re‑verifies each mDoc card before rendering, so tampered or expired cards surface with a red badge and unknown issuers surface as “unverified” rather than green. - ARF‑native VCT issuance — the built‑in issuer mints urn:eu.europa.ec.eudi:pid:1 , :email:1 , and :address:1 per ARF §5.6.1. Missing mandatory fields cause an honest mint refusal. - mDoc cnf holder‑key binding — the wallet’s public JWK is converted to COSE_Key and embedded in the MSO, so presentation‑time DeviceAuth proofs bind to the real holder key. - RSA holder‑key opt‑in — the web wallet still defaults to ES256, but users can select RSA‑2048 or RSA‑3072 for environments that require it. ### Multi-tenant from day one Tenant identity is the request domain — same as the rest of CodeB. A user signing in at phone.acme.com hits the Acme RSA key and the Acme SIP credential file; a user at phone.contoso.com hits the Contoso key and the Contoso credentials. The two tenants share no state. Adding a new tenant means adding a hostname. The first request to /oidc.ashx generates that tenant’s RSA key and persists it at App_Data//oidc/private-key.xml . No schema migration, no restart, no downtime for the other tenants. ### Operator notes Question | Answer How are passwords stored? | As HA1 digests: MD5(user:realm:password) per RFC 2617, the format SIP phones already use. Plaintext password never reaches the server — the login form hashes it in the browser. HA1 is treated as a password-equivalent secret. Where do user accounts live? | App_Data//sip-credentials/.json . Manage them from the Register admin page. Where does the private key live? | App_Data//oidc/private-key.xml . Plain XML, not committed to source. Back it up with the rest of App_Data . How do I rotate the key? | Delete the file and recycle the IIS app pool. The next request regenerates a fresh key with a new kid . RPs re-fetch JWKS automatically. Is there an audit log? | Yes — App_Data//logs/codeb-oidc-YYYY-MM-DD.log (JSONL), and a parallel feed into the Windows Event Log under source CodeBOIDC . How long do tokens live? | Access tokens 1 hour. Refresh tokens 7 days. ID tokens 1 hour. Auth codes 60 seconds, single use. Want the rest? All features → ### Run your own OIDC IdP this week. Wire it to Nextcloud / WordPress / Grafana / your own apps. We'll walk the integration with you. Developer cookbooks: OIDC sign-in - JWT validation - M2M API keys - Webhooks ### Frequently asked questions What is CodeB's OpenID Connect identity provider? CodeB ships with a self-hosted, standards-compliant OpenID Connect identity provider. It implements Authorization Code with PKCE (S256), RS256-signed JWTs, per-tenant RSA keys, RFC 8414 Discovery, RFC 7517 JWKS, RFC 7009 token revocation, and RFC 7662 token introspection. Every relying party that speaks OIDC works out of the box. Does CodeB support EU Wallet sign-in? Yes. As of 2026-06-08, CodeB ships a live OID4VP 1.0 verifier substrate. Any spec-compliant EU Digital Identity Wallet (EUDI Wallet) can sign in, sign up or subscribe on a CodeB tenant. The pipeline runs ES256-signed Authorization Requests, DCQL credential queries, JWE-encrypted responses, SD-JWT VC selective disclosure with KB-JWT holder binding, and relays verified claims through the standard OIDC userinfo endpoint. Is CodeB's OIDC really cookie-free? Yes. No cookies anywhere — not session, not tracking. Sign-in across multiple relying parties uses a signed, 30-minute, same-origin assertion in localStorage at the IdP origin: never sent to other sites, never used for cross-site tracking, cleared on logout. Per-tab access and refresh tokens live in sessionStorage and vanish when the tab closes. Which OID4VP profile does CodeB implement? OID4VP 1.0 with the HAIP 1.0 client_id scheme — ES256-signed JAR Authorization Requests, x509_san_dns client_id, DCQL credential queries, JWE-encrypted responses with ECDH-ES + A128GCM, SD-JWT VC with KB-JWT holder binding. Is CodeB EUDI-certified? No. EUDI certification is reserved for notified national wallet schemes and qualified trust service providers under eIDAS 2.0. CodeB is a verifier (relying party), not a wallet issuer, and is careful not to claim certification it does not hold. OpenID Foundation self-certification for OID4VP 1.0 + HAIP 1.0 is in progress. From when does my business need to accept the EU Wallet? From December 2027, every regulated EU private-sector business — banks, telcos, insurers, large platforms, healthcare, government suppliers — is legally required to accept the EU Digital Identity Wallet as a customer login under eIDAS 2.0 Article 5f sub 2. How are passwords stored? As HA1 digests — MD5(user:realm:password) per RFC 2617, the format SIP phones already use. Plaintext password never reaches the server; the login form hashes it in the browser. HA1 is treated as a password-equivalent secret. Pure web/OIDC deployments without SIP can opt into Argon2 / scrypt instead. Can I rotate signing keys without downtime? Yes. Two signing keys can be active at once. Rename private-key.xml to private-key-previous.xml; the next request generates a fresh active key. JWKS publishes both, the kid in each token pins it to the right one. No IIS recycle, no dropped sessions. =================================================================== # Telecoms · CodeB EU Wallet verifier for SIM, eSIM and MSISDN trust # Source: https://www.aloaha.com/telecoms.html =================================================================== > Mobile operators, MVNOs and eSIM brands: a self-hosted EU Digital Identity Wallet verifier for SIM and eSIM registration, verified phone-number trust and anti-fraud workflows. Built for the 2027 eIDAS 2.0 acceptance window. ## EU Wallet verifier for SIM, eSIM and verified phone-number trust. Mobile operators, MVNOs, eSIM brands and telecom retailers face a 2027 acceptance window for the EU Digital Identity Wallet. CodeB is a self-hosted verifier that drops into SIM registration, eSIM activation, number portability and B2B account workflows — without a national-identity-cloud middleman. ### Why identity is the new bottleneck. #### KYC is fragmented & expensive Prepaid SIM registration relies on a patchwork of in-store document checks, document uploads and third-party video-ID. Video-ID has high abandonment rates — and in 2026 is increasingly spoofable with generative AI (face-swap and voice-clone deepfakes on a webcam feed). Manual checks scale linearly with headcount. #### SIM-swap fraud bleeds margin Account takeover via SIM swap remains a leading channel for financial-account fraud. Operators carry reputation cost, regulator scrutiny and reimbursement disputes — even when the original ID check was technically valid. #### eSIM amplifies the problem Remote profile download removes the natural friction of a shop visit. Without a high-assurance identity step in the activation flow, you trade onboarding ease for fraud exposure. #### 27 wallets, not one Each Member State issues variations of the wallet — different trust registries, PID schemas, local implementations. Maintaining 27 integrations in-house is a never-ending cost line. ### One verifier endpoint. Every compliant wallet. #### Wallet verifier substrate OID4VP 1.0 + HAIP — the same protocol the EU reference wallet implementation speaks. Selective disclosure via SD-JWT VC. Verifier-attestation JAR signed with ES256. The wallet talks to your server, not a vendor cloud. #### SIM & eSIM activation hook Pre-built attribute request profiles for prepaid, postpaid, eSIM, business SIM and number portability. Verified PID lands in your CRM/BSS via webhook before activation completes. Audit row stored locally. #### MSISDN binding Once the operator can verify wallets, it can also bind a verified MSISDN to a wallet identity — the foundation for future phone-number-as-credential issuance. Slot reserved in the verifier substrate; not yet a billable feature. #### Retail + remote modes In-store: shop assistant shows a QR on a tablet; the customer scans with their wallet; verified attributes flow to the till. Remote: same flow inside the operator app or web onboarding journey. ### An eSIM brand serving travellers across the EU. A travel-eSIM operator offers prepaid data packs across 12 countries. Today, identity is collected via document upload + selfie video, processed by an external KYC vendor. Per-activation cost is high; conversion suffers on mobile; fraud catches a small but visible long-tail. - Customer picks a data pack on the operator's app, taps Verify with EU Wallet . - Wallet presents the requested attributes — given name, family name, date of birth, country of residence — with selective disclosure so nothing extra leaves the wallet. - The CodeB verifier validates the SD-JWT VC chain, returns the verified fields to the operator's activation backend. - Backend issues the eSIM profile QR within the same session. No document upload, no human review queue, no third-party KYC bill. - Audit row stored: which attributes were requested, which were returned, policy version, timestamp — nothing that wasn't strictly necessary. Activation latency falls from minutes to seconds. Cost per activation drops. Fraud surface narrows. The carrier didn't change. ### Seven concrete telecom workflows. #### Prepaid SIM registration Replace document-upload or in-store ID checks with a wallet QR. Verified PID flows to your activation system. Compliance-grade audit trail without storing scanned passports. #### eSIM onboarding Add a high-assurance identity step to remote activation. Issue the eSIM profile only after the wallet presentation succeeds. Zero-touch end-to-end. #### Number portability Confirm the requestor is the rightful subscriber via wallet PID before initiating an outbound port. Cuts port-out fraud and reduces customer-care escalations. #### SIM-swap re-authentication Before swapping a SIM, re-verify the subscriber's PID through the wallet. Hard limit on social-engineered store-floor swaps. #### Age-gated content For operators acting as ISPs or content hubs, request a wallet attestation of "over 18" without collecting the actual birth date. Selective disclosure reduces GDPR scope. #### Account-recovery Wallet-as-recovery: a subscriber locked out of their account presents their wallet, receives a one-time password-reset link. No call-centre identity quiz. ### The 2026/2027 runway is short. #### Late 2026 Member States are expected to issue wallets to citizens and residents. Real users start carrying the wallet on their phones. Pilot-only flows are no longer enough. #### 2027 Article 5f acceptance kicks in for large telecom service providers required by law or contract to use strong user authentication. Operators that haven't integrated by then face commercial & reputational exposure on top of regulatory exposure. #### 2028 onward The market shifts from compliance to monetisation: phone-number trust credentials, wallet-mediated B2B identity, cross-border KYC reuse, anti-fraud APIs. Operators that integrated early own the customer experience. #### Now — Q4 2026 The window where you pilot, integrate with your CRM/BSS and shake out the store flows. CodeB's verifier ships today; the issuer module is a future expansion so you don't have to rip it out later. ### Three paths — sized to the operator. #### MVNO / eSIM brand One server alongside your activation API. Lightweight tenant. No telco-grade HA required for pilot. Production after 4–6 weeks of integration. #### Telecom retailer Tablet at the till runs a thin shop-assistant UI; the verifier runs in the back office. Per-store rollout without changing the retail till stack. #### Tier-1 operator On-premises gateway behind your IAM. Tenants per brand, per country, per BSS region. Issuer module on the same substrate when MSISDN credentials go live. #### Sovereign & local Windows + IIS on your own hardware. No third-party identity cloud handles the presentation. Audit row, policy version and verified attributes stay on premises. ### Telecom-grade pilot in weeks, not quarters. Tell us about your activation flow, the wallet pilots you're already tracking, and the regulator you answer to. We'll map which pieces of CodeB you need to turn on first — and which can wait. Related: For whom is CodeB? EU Wallet verifier API Identity Proof of work AI-call privacy Buy / host ### Talk to a real telecoms engineer. SIP trunk shape, BYOC, EU Wallet sign-in flows for carriers — we ship answers, not brochures. ### Frequently asked questions Why do mobile operators need an EU Wallet verifier? Under eIDAS 2.0 Article 5f, large private relying parties that are required by law or contract to use strong user authentication for online identification — explicitly including the telecommunications sector — must accept the EU Digital Identity Wallet. The practical compliance window is treated as 2027. Operators that wait until the deadline miss the integration runway with their CRM, BSS and activation systems. What telecom workflows does it replace? Document-upload KYC, in-store ID checks and third-party video-ID for prepaid SIM registration; manual ID checks for eSIM activation; passport scans for number portability requests; document chains for B2B SIM fleets and corporate-account changes. Does this work with eSIM? Yes. The verifier sits in front of activation. A customer scans a QR code, the wallet presents the requested attributes over OID4VP, the verifier returns the verified fields to your activation system, and only then is the eSIM profile or QR-code issued. Zero-touch remote onboarding with a high-assurance identity step in the middle. Can the operator issue credentials too — not just verify? That is a logical follow-on. Once an operator can verify wallets it can also issue wallet-readable credentials — for example a credential asserting that a given wallet holder controls a given phone number. CodeB's verifier substrate is built so an issuer module can be added alongside without a re-architecture. Is the wallet verifier self-hosted? Yes. The whole CodeB stack runs on a Windows + IIS server you control. No third-party identity cloud handles the wallet presentation. Audit trail and policy decisions stay on premises, which matters for sector regulators and GDPR scope. =================================================================== # EU ID Wallet Software · Malta · Aloaha Web Wallet — Browser-based EUDI Wallet (HAIP §5.11) # Source: https://www.aloaha.com/web-wallet-explainer.html =================================================================== > EU ID Wallet software built in Malta. The Aloaha Web Wallet is a browser-based, self-hostable European Digital Identity Wallet (PWA) with OpenID4VCI issuer support, OID4VP presentation, SD-JWT VC format, HAIP §5.11 Wallet Attestation, PBKDF2-encrypted recovery vault, and optional zero-knowledge cloud sync. Made in Malta by Aloaha Limited. No app-store install, no camera required. ## An EU-Wallet holder that lives in your browser . EU ID Wallet software, built in Malta. A hosted, browser-based European Digital Identity Wallet holder for the many Europeans who cannot or will not install a native app: older users, corporate devices without app-install rights, phones already at storage capacity, or people who simply prefer opening a URL. Runs as a Progressive Web App on desktop and mobile, uses WebCrypto for all key operations, backs up an end-to-end encrypted vault to our OIDC server so you can recover on a new device. Made in Malta by Aloaha Limited — a Malta-registered software company shipping self-hostable EU ID Wallet software for EUDIW-conformant issuers and verifiers. ### Why a browser wallet at all? #### Reach every user App-install friction is the biggest single reason EU-Wallet uptake will stall. A browser holder reaches the users who never install anything. Same standards, same claims, no store review. #### Corporate desktops Fleet-managed corporate laptops rarely permit app installs. A browser wallet works within the existing browser sandbox and passes standard IT policy. #### Instant onboarding Verifier flow can bootstrap a wallet in the same tab: user has no wallet → click the "Sign in with EU Wallet" button → wallet UI opens → they finish the flow. No app-store detour. #### Cross-device by design Sign in on a new laptop, restore the vault via passkey or passphrase, all your credentials are back. Zero-knowledge backup means Aloaha holds only ciphertext. ### How you sign in The wallet is gated by our own OIDC provider — the same sign-in that protects every other admin surface. There is no separate "wallet account"; there is one identity per tenant. When you open /web-wallet.html you are prompted to sign in (WebAuthn, TOTP, or password, per tenant policy) and every request the wallet makes to /wallet-backup.ashx carries an OIDC bearer token. Two layers, each doing its own job. Authentication (OIDC, "who are you") gets you access to the encrypted vault blob. Vault decryption (passphrase or WebAuthn passkey PRF, "what unlocks your credentials") is independent of authentication and never leaves your browser. Zero-knowledge is preserved: the server knows who you are but still cannot decrypt your credentials. ### Multi-factor recovery (from day one) Losing your device shouldn't mean losing your credentials. The wallet stores an end-to-end encrypted vault that can be unlocked by any single registered recovery factor. #### Factor 1 — Recovery passphrase (mandatory) PBKDF2-SHA256 with 600 000 iterations (OWASP 2023) derives a key-encryption-key from your passphrase. The passphrase never leaves your browser. Write it down — it is the cold-storage fallback for the worst case. #### Factor 2 — WebAuthn passkey (recommended) Register a passkey with the WebAuthn PRF extension. The PRF derives a deterministic key-encryption-key per authenticator. On modern browsers (Chrome, Edge, Safari 17+, Firefox 122+) the passkey syncs via iCloud Keychain / Google Password Manager / Windows Hello, so a new device recovers your wallet with just the passkey ceremony — no passphrase entry needed. #### Factor 3 — Multi-device passkeys (belt-and-braces) Register additional passkeys on other browsers or devices. Each factor wraps its own copy of the vault's data-encryption-key. Add, remove, or replace factors at any time without re-encrypting the vault. ### Zero-knowledge server backup The wallet syncs its encrypted vault blob to your tenant's /wallet-backup.ashx endpoint (OIDC-bearer gated). Our server stores ciphertext only. We literally cannot decrypt your vault, use your keys, or help you if you lose every recovery factor. That is by design (zero-knowledge) and stated plainly in the setup wizard. Envelope encryption: a random 256-bit data-encryption-key (DEK) encrypts your credentials with AES-256-GCM. The DEK is wrapped once per registered factor using AES-KW (RFC 3394). Passphrase factor: DEK wrapped under PBKDF2-derived key. Passkey factor: DEK wrapped under an HKDF-SHA256 derivation of the WebAuthn PRF output. Any surviving factor unwraps the DEK and decrypts the vault. ### Supply-chain resilience: Aloaha-owned code A live credential issued, held, and verified end-to-end on the Aloaha-owned stack — no third-party EUDI library on the critical path. Click either image to enlarge. The entire EUDI protocol layer — SD-JWT VC parsing, KB-JWT signing, OID4VP presentation, OID4VCI credential import, wallet attestation, WebAuthn PRF integration, envelope encryption — is written line-by-line by Aloaha Limited in Malta. Zero eudi-lib-* dependencies in the tree. Zero openid4vc-* library adapters. Generic infrastructure libraries used elsewhere in the platform are well-established open-source components documented in our SBOM; the EUDI protocol layer is 100% ours. Why this matters under the Cyber Resilience Act. Regulation 2024/2847 calls SBOM the minimum — “at the very least the top-level dependencies”. The Log4Shell-class of attacks lives in transitive dependencies that a standard SBOM does not surface. Our architectural response was to remove the supply chain for the parts that matter: a Log4Shell in the EUDI stack requires an EUDI supply chain to exploit, and we deliberately do not have one. Machine-readable SBOM: /sbom.spdx.json . Full rationale: cyber-resilience.html § 01 . ### Share-QR — scan-and-verify without installing a wallet The wallet holder taps Verify (QR) on any credential. The full SD-JWT VC is POSTed to a per-tenant relay /vshare.ashx , which stores it under a 128-bit random opaque id and returns a short link. The QR encodes only that short link (~120 bytes), so it scans reliably from a phone screen across the room. The verifier fetches the credential by id, parses it in the browser, and shows a physical-mimic ID card with the disclosed attributes and a green VALID / red INVALID cryptographic status. Anyone with a phone camera can verify; no wallet app required. #### Configurable TTL 1 minute (shop counter, single scan) through 15 minutes (default), 1 hour, 1 day, 7 days, 30 days, 1 year, up to 2 years (public demo QR on LinkedIn / blog / conference badge). Filename-encoded expiry, sweep-on-write, hard clamp at the handler. #### Portrait via URL PID + mDL credentials carry a portrait_url claim covered by the issuer signature. The verifier renders the portrait via pulling directly from the tenant's /portrait.ashx?id=… . Signature covers the URL string, so swapping the URL breaks the credential. #### No installed wallet needed Verifier is a static page with WebCrypto. Fetches issuer JWKS via /.well-known/jwt-vc-issuer . Same page verifies PID, mDL, EHIC, mVRC, and any tenant-defined VCT. #### Try it now — scan or click Two live demo credentials. Scan a QR with your phone camera, or click it if you’re on a laptop. No wallet app required — the verifier opens in your browser and cryptographically checks the SD-JWT VC. ##### John CITIZEN EU Digital Identity Wallet — Identity Card (PID) Instead of scanning you can also click the QR to open the verifier directly. ##### Erika Mustermann EU Digital Identity Wallet — Identity Card (PID) Instead of scanning you can also click the QR to open the verifier directly. ### Standards + interoperability #### OID4VP 1.0 FINAL HAIP 1.0 Final mandates x509_hash . x509_san_dns is supported as an additional OpenID4VP compatibility mode for legacy wallets and is not part of HAIP Final. Presentations use JWE ECDH-ES A128GCM/A256GCM envelopes. #### OID4VCI Pre-authorized_code flow with dynamic vct resolution and holder-binding via cnf.jwk . #### SD-JWT VC Draft 07-compliant parsing + selective disclosure + KB-JWT with sd_hash. #### W3C VCDM 2.0 JSON credential + @context , JOSE envelope typ=vc+jwt , ES256 signed. Issuer at /vcdm.ashx?action=issue , verifier at ?action=verify . Ships alongside SD-JWT VC. #### W3C DID Core 1.0 Tenant publishes did:web: at /.well-known/did.json . Resolver at /did.ashx?did=… handles did:key, did:jwk, did:web, did:webvh with SSRF-guard. #### W3C Bitstring Status List v1.0 Compressed gzipped bitstring with multibase- u encoding, published as a signed VC-JWT with 7-day freshness. Bit-flip requires admin bearer. #### ETSI TS 119 602/612 Trusted List Tenant publishes its own LoTE at /.well-known/trust-list.xml , XMLDSig enveloped ECDSA-SHA256, exclusive C14N. Plus a JSON mirror. #### HAIP §5.11 Wallet Provider Metadata JWT at /.well-known/wallet-provider.jwt . Mints WUA (12-month Unit Attestation) + WIA (24-hour Instance Attestation) for attest_jwt_client_auth . #### ISO/IEC 18013-7 mDoc online-presentation profile advertised in vp_formats_supported.mso_mdoc.iso18013-7_profile_supported . #### WebAuthn Level 3 PRF Passkey-based key derivation per draft-ietf-webauthn-prf. #### WebCrypto only All crypto via window.crypto.subtle . Non-extractable keys where possible. No JavaScript polyfills. #### Same-origin CSP Wallet page enforces strict CSP so no third-party script can exfiltrate the vault DEK during its brief in-memory window. ### How it fits alongside the native EUDI Wallet When the government-notified EUDI Wallet Instance for a Member State ships, users who want LoA-High and hardware-anchored PID belong there. This browser holder complements it, not competes with it. Use it for the audience the native app doesn't reach: older users, corporate desktops, first-touch onboarding, sector-specific credentials where LoA-Substantial is fit-for-purpose, or as a fallback when the native app isn't installed yet. ### Read next - Verifier live demo (OID4VP 1.0 FINAL) - HAIP conformance evidence - Age verification demo - Verify a wallet credential (Share-QR public verifier) — scan a wallet-holder's Verify-QR from any phone camera; checks signature + expiry + disclosures + status-list bit entirely in the verifier's browser. - Membership cards cookbook — tenant playbook for issuing member VCs into wallets and verifying them at the door. - Machine-readable /openapi.json ### Frequently asked questions What is the Aloaha Web Wallet? The Aloaha Web Wallet is a browser-based, self-hostable European Digital Identity Wallet holder that runs as a Progressive Web App. It receives credentials via OpenID4VCI, presents them via OID4VP, stores them in SD-JWT VC format and uses WebCrypto for all key operations. It is EU ID Wallet software made in Malta by Aloaha Limited. Is the Aloaha Web Wallet my country's official EUDI Wallet? No, the Aloaha Web Wallet is not the EUDI Wallet Instance, which is the government-notified native app issued by each Member State. The Aloaha Web Wallet is a companion holder for audiences a native app does not reach, such as older users, managed corporate desktops or first-time onboarding. Users who need LoA High and hardware-anchored PID belong in the national wallet once it ships. What eIDAS level of assurance does the Aloaha Web Wallet have? The Aloaha Web Wallet does not claim an eIDAS assurance level. It is designed for use cases targeting Level of Assurance Substantial, subject to deployment configuration and a formal conformity assessment, and Aloaha does not self-assign an assurance level in the absence of that assessment. Do I need to install an app to use the Aloaha Web Wallet? No, the Aloaha Web Wallet needs no app-store install and no camera. It opens from a URL in the browser and can be installed as a Progressive Web App on iOS, Android, Windows, macOS and Linux. That makes it usable on fleet-managed corporate laptops that do not permit app installs. Which standards does the Aloaha Web Wallet support? The Aloaha Web Wallet implements OID4VP 1.0 Final presentation with x509_hash (as mandated by HAIP 1.0 Final) plus x509_san_dns as a compatibility mode, and OpenID4VCI with the pre-authorized_code flow. Credentials use SD-JWT VC with selective disclosure and KB-JWT, and the stack also supports W3C VCDM 2.0, W3C DID Core 1.0, W3C Bitstring Status List v1.0 and HAIP §5.11 Wallet Attestation. The mDoc online-presentation profile of ISO/IEC 18013-7 is advertised in the verifier metadata. How do I sign in to the Aloaha Web Wallet? The Aloaha Web Wallet is gated by the tenant's own OIDC provider, so there is no separate wallet account. When you open /web-wallet.html you sign in with WebAuthn, TOTP or password, depending on tenant policy. Signing in only grants access to the encrypted vault blob; unlocking the credentials is a separate step that happens in your browser. What happens if I lose the device with my Aloaha Web Wallet? The Aloaha Web Wallet keeps an end-to-end encrypted vault that any single registered recovery factor can unlock on a new device. A recovery passphrase is mandatory and is stretched with PBKDF2-SHA256 at 600,000 iterations; a WebAuthn passkey with the PRF extension is recommended and can sync via iCloud Keychain, Google Password Manager or Windows Hello. Additional passkeys on other devices can be registered as further factors. Can Aloaha read the credentials in my Web Wallet? No, the Aloaha Web Wallet backup is zero-knowledge: the server stores only ciphertext of the vault. Credentials are encrypted with AES-256-GCM under a random data-encryption key that is wrapped per recovery factor, and the passphrase and passkey output never leave your browser. The flip side is that Aloaha cannot help you if you lose every recovery factor. How can someone verify a credential from the Aloaha Web Wallet without installing a wallet? The Aloaha Web Wallet has a Share-QR feature: tapping Verify (QR) on a credential stores it on a per-tenant relay under a random id and shows a QR code with a short link. Anyone with a phone camera can scan it; the verifier page checks the SD-JWT VC signature, expiry, disclosures and status in the browser and shows a VALID or INVALID result. The link lifetime is configurable from 1 minute up to 2 years, with 15 minutes as the default. Can I sign PDFs with the Aloaha Web Wallet? Yes, the Aloaha Web Wallet can sign PDFs through a Cloud Signature Consortium (CSC) v2 subset. Signatures are PAdES-B-T with an RFC 3161 timestamp, use a per-user EC P-256 certificate enriched from your OIDC profile, and work with encrypted PDFs (RC4-128 and AES-128). These are Advanced Electronic Signatures only, not qualified signatures. Does the Aloaha Web Wallet use third-party EUDI libraries? No, the Aloaha Web Wallet's EUDI protocol layer is written by Aloaha Limited in Malta with no eudi-lib-* or openid4vc-* library dependencies. This covers SD-JWT VC parsing, KB-JWT signing, OID4VP presentation, OID4VCI import, wallet attestation, WebAuthn PRF integration and envelope encryption. Generic infrastructure libraries used elsewhere in the platform are listed in the machine-readable SBOM at /sbom.spdx.json. =================================================================== # EU ID Wallet Software · Malta · Build for the European Digital Identity Wallet — CodeB / Aloaha # Source: https://www.aloaha.com/eu-wallet-integrations.html =================================================================== > EU ID Wallet software from Malta. Verifier, issuer, wallet-provider, and trust-anchor integration guides for the European Digital Identity Wallet ecosystem. Copy-paste snippets for OID4VP and OID4VCI. Built by Aloaha Limited, Malta. ## Build for the European Digital Identity Wallet with CodeB. EU ID Wallet software, built in Malta by Aloaha Limited. Whether you are a Relying Party asking for a presentation, a public authority issuing credentials, a wallet vendor publishing your Wallet Attestation trust anchors, or an operator running a national trust list — the endpoints, snippets, and drop-in scripts below hook straight into the European Digital Identity Wallet ecosystem. Self-hostable, sovereign, Malta-registered. The upstream reference is docs.eudi.dev ; nothing on this page is endorsed by the European Commission. Honest scope. CodeB ships OID4VP FINAL, OID4VCI 1.0 Final, SD-JWT VC, mso_mdoc, and HAIP section 5.11 Wallet Attestation today. ### Pick your role #### Verifier / Relying Party Ask for a presentation from a holder's wallet. Poll for completion, read claims. #### Issuer Mint SD-JWT VC or mso_mdoc credentials for holders via OID4VCI credential offers. #### Wallet provider Publish Wallet Attestation JWKS / PEM so verifiers can enforce HAIP §5.11. #### Trust-anchor operator Supply LOTL, SD-JWT-VC issuer, or mDoc issuer certificates to the verifier trust store. ### Verifier setup Every verifier flow uses the same three moves against the CodeB tenant: vp-start to open a presentation session, render the returned deep link (QR or native invocation), then poll vp-status until the wallet completes it. #### 1. Open a session #### 2. Render the deep link Convert deep_link to a QR code for desktop flows, or invoke it directly on mobile. The deep link uses the openid4vp:// scheme (or haip:// when the tenant is configured for HAIP). #### 3. Poll for completion #### 4. Copy-paste JS The vanilla-JS snippet handles the render + poll cycle. It exports one function: A React hook variant lives at verifier-react-hook.jsx . Framework-scoped wrappers for Vue and Angular ship on the verifier integration cookbook . ### Issuer setup The issuer flow follows OID4VCI 1.0 Final (dedicated Nonce Endpoint, Notification Endpoint, credentials[] response shape; the Draft-15 scalar credential field is preserved as a backward-compat fallback). You declare which credential types your tenant supports, mint a credential offer per holder, and hand the wallet a openid-credential-offer:// deep link. #### 1. Declare supported VCTs Drop VCT metadata JSON files under App_Data//vci/ , or use the vci-admin UI. Each VCT declares its credential format ( vc+sd-jwt or mso_mdoc ), claims, and cryptographic constraints. #### 2. Mint a credential offer #### 3. Ready-to-copy credential offer JSON Two sample offers ship in /downloads/eu-wallet/ : - issuer-credential-offer-sample.json - SD-JWT VC with pre-authorized-code grant (single-use bearer, no PIN). - issuer-credential-offer-mdoc-sample.json - mso_mdoc PID with authorization_code flow. ### Wallet-provider setup Wallet providers publish the public keys that sign HAIP section 5.11 Wallet Attestation JWTs, so RPs can enforce that a presentation actually came from a specific wallet product. #### 1. Publish your JWKS Static file at https:///.well-known/wallet-provider.jwks.json . A shape sample lives at wallet-provider-jwks.json . #### 2. Deposit at the tenant The tenant operator drops the JWKS (or the equivalent X.509 PEM) under: #### 3. Enforce Wallet Attestation Set Oidc:WalletAttestationRequired=true on the tenant to reject presentations that lack a valid HAIP §5.11 attestation JWT. The testscripts/wallet-attestation-smoke.py probe exercises the full path. ### Trust-anchor setup Verifier tenants need three distinct trust stores: the EU List of Trusted Lists (LOTL) for eIDAS certificate chains, an SD-JWT VC issuer set, and an mDoc issuer set. Each stores its inputs under App_Data//trust/ as PEM / JSON / DER. The end-to-end operator walk-through, including nightly reconciler + wacs cert refresh, lives on the dedicated HAIP operator setup page. This section is intentionally short: the operator page is the source of truth. ### Integrate in minutes Copy-paste against your own tenant — replace your-tenant.example with your CodeB host. These call the same public endpoints documented in the EU Wallet verifier API and the OIDC provider. No SDK required. #### Verify an EU Wallet presentation — OID4VP 1.0 ``` # 1) Start a presentation request and keep its session cookie (OID4VP 1.0 / HAIP) curl -s -c cj 'https://your-tenant.example/oidc.ashx?action=vp-start&client_id_prefix=x509_hash' # -> { "id": "...", "deep_link": "openid4vp://...", "expires_in": 300, "status": "pending" } # 2) Render deep_link as a QR (desktop) or open it on the phone. # The EUDI wallet fetches the signed request and posts an encrypted SD-JWT VC. # 3) Poll with the same cookie until the user finishes (about every 2 s) curl -s -b cj 'https://your-tenant.example/oidc.ashx?action=vp-response&id=' # waiting -> HTTP 202 { "ok": false, "status": "pending" } # verified -> HTTP 200 { "ok": true, "status": "completed", "user": "...", # "claims": { ... }, "sso_assertion": "" } ``` #### Sign in with OpenID Connect — Authorization Code + PKCE ``` # 1) Discover endpoints curl -s https://your-tenant.example/.well-known/openid-configuration # 2) Send the user to sign in (PKCE) # https://your-tenant.example/oauth2/v1/authorize?response_type=code # &client_id=&redirect_uri=&scope=openid%20profile%20email # &code_challenge=&code_challenge_method=S256&state=&nonce= # 3) Exchange the code for tokens curl -s -X POST https://your-tenant.example/oauth2/v1/token \ -d grant_type=authorization_code -d code= -d redirect_uri= \ -d client_id= -d code_verifier= # -> { "access_token": "...", "id_token": "...", "expires_in": 3600 } # 4) Read claims curl -s https://your-tenant.example/oauth2/v1/userinfo -H 'Authorization: Bearer ' ``` Register your client first in the tenant admin (OIDC clients). Full walkthrough: OIDC sign-up how-to . #### Issue a credential to a wallet — OID4VCI ``` # Mint a credential offer in the issuer admin (see Issuer setup above), # then share the offer URI as a QR for the wallet to scan: curl -s 'https://your-tenant.example/vci.ashx?action=offer&id=' # -> openid-credential-offer://?credential_offer_uri=... ``` Formats: SD-JWT VC ( dc+sd-jwt ) and ISO 18013-5 mdoc. See Issuer setup . #### Hand it to your coding assistant No SDK to learn — paste this prompt into your coding assistant and let it scaffold the integration against your stack: ``` Integrate my app with a CodeB / EUDI identity tenant at https://your-tenant.example. - Sign-in: OpenID Connect, Authorization Code + PKCE. Read endpoints from /.well-known/openid-configuration (authorize/token/userinfo under /oauth2/v1/). - Verify an EU Digital Identity Wallet presentation: GET oidc.ashx?action=vp-start, render the returned deep_link as a QR, then poll oidc.ashx?action=vp-response&id= until it returns HTTP 200 with ok:true and the verified claims (HTTP 202 while pending). Keep the session cookie set by vp-start and send it on every poll. - Credentials are SD-JWT VC (dc+sd-jwt) and ISO 18013-5 mdoc, OID4VP 1.0 / HAIP. - Handle the pending, expired and invalid_vp_token states. Generate the server and client code in . Spec reference: docs.eudi.dev. ``` ### Deep-link builder (test harness) Build a quick openid4vp:// or openid-credential-offer:// URL for wallet interop testing. Nothing here is sent to a server — this is a pure client-side helper. The same logic lives in openid4vp-deep-link-builder.js . Reference: docs.eudi.dev for upstream EU Digital Identity Wallet reference implementations and protocol profiles. Developer cookbooks: OIDC sign-in - JWT validation - M2M API keys - Webhooks See also: wallet interoperability matrix · glossary . ### Frequently asked questions Which specs does CodeB implement for European Digital Identity Wallet integration? OpenID for Verifiable Presentations (OID4VP) FINAL, OpenID for Verifiable Credential Issuance (OID4VCI) Draft 15, SD-JWT VC (draft-ietf-oauth-sd-jwt-vc), ISO/IEC 18013-5 mso_mdoc, and the High Assurance Interoperability Profile (HAIP). Upstream reference: docs.eudi.dev. Do you ship official EU Commission endorsement? No. CodeB is not endorsed by the European Commission. These integration guides implement public EUDI-ecosystem specifications and reference the upstream docs at docs.eudi.dev. Does the verifier flow enforce Wallet Attestation? Optional per tenant. Set Oidc:WalletAttestationRequired=true on the tenant to require HAIP section 5.11 wallet attestation on every presentation. =================================================================== # EU Digital Identity Wallet Registration — verifier trust anchor | CodeB Sovereign Communications # Source: https://www.aloaha.com/eudi-registration.html =================================================================== > This tenant is a registered Wallet Relying Party on the European Digital Identity Wallet reference registry (registry.serviceproviders.eudiw.dev). Live-fetched proof, the WRP signing certificate, entitlements, and supported credential formats — verify us end-to-end from your browser. ## Registered Wallet Relying Party on the European Digital Identity Wallet reference registry This service is listed as a Wallet Relying Party in the EU reference registry that ships with the European Digital Identity Wallet architecture (ARF 3.0). Below is the live registration record, the JAR-signing certificate we present to wallets, and a link that lets you verify the listing directly on the EU registry with no CodeB systems in the loop. ### Registration status across registries A Wallet Relying Party can register on any number of EUDIW Registrars — each Registrar publishes its own trust anchor + issues its own certificates. We hold registrations independently on each. If your wallet ships one anchor bundle and not the other, this table tells you which side of the trust boundary we are visible on today. Data sources: registry.serviceproviders.eudiw.dev/wrp and sandbox.eudi-wallet.org/api/wrps . Match is a case-insensitive substring lookup on our tradeName ("aloaha" / "codeb") — if either registry lists us under a different name, edit _ourNameHints in this page. ### Live proof from the EU reference registry Server-side fetch of registry.serviceproviders.eudiw.dev/wrp , filtered to this tenant. Cached 5 minutes. ### Registry-issued JAR-signing certificate The registry issued a PKCS#12 to this tenant during Wallet Relying Party enrolment. Every OpenID for Verifiable Presentations JAR we sign against a wallet carries this certificate in its x5c header. The public half is below. ### Verify with an EU-issued PID Prove the round-trip works with a credential we did not issue. Get a PID from dev.issuer.eudiw.dev using the EU Reference Wallet (Android / iOS), then run the interoperability self-test below. Our verifier accepts the third-party PID, decodes selective disclosures, verifies the KB-JWT holder binding, and shows a per-check HAIP report you can screenshot. ### What a successful presentation looks like Screenshot from the EU Reference Wallet immediately after presenting a PID (SD-JWT VC) to this verifier. The green verified badge next to CodeB / Aloaha Limited is drawn by the wallet from the tradeName + certificate the EU registry holds against our entry — a substring of the family name is redacted for privacy. EU Digital Identity Wallet (reference build, Android) · PID (SD-JWT VC) shared with this verifier · captured 2026-08-09 on the live phone.codeb.io tenant. ### Other verified Wallet Relying Parties on the same registry Two live sources, merged: registry.serviceproviders.eudiw.dev/wrp (EU reference registry — unmarked rows) and sandbox.eudi-wallet.org/api/wrps (German national Sandbox Registrar — rows tagged DE registrar ). We hide test / demo / fake entries and dead-domain records (policyURI on an unreachable host) so the list reflects real, contactable Wallet Relying Parties only. Filter is a heuristic pass (tradeName / URL substrings) plus an explicit blacklist maintained by our operators. ### What this actually means Wallet Relying Party (WRP). The European Digital Identity Wallet architecture treats every verifier — the party that asks a wallet to present a credential — as a Wallet Relying Party. The EU Reference Wallet ships with an inbuilt list of registered Wallet Relying Parties and will show your users which entitlements each one has claimed before they consent to share attributes. Trust anchor. The WRP entry above is what the EU Reference Wallet consults when it validates an OpenID for Verifiable Presentations request from this service. The signing certificate we display in the second card is the same certificate the wallet checks the JAR signature against. If either changes, wallets stop trusting the request. There is no shortcut, no self-declaration, and no honour system. Verify without our help. Click Verify yourself on the EU registry to open registry.serviceproviders.eudiw.dev/wrp directly. The list is a base64-encoded JSON payload — the same one this page fetches on your behalf — and you can decode it locally with any base64 tool. The tenant tradeName, entitlements, supported formats and privacy policy URL should match what you see here. Registered honestly. The entitlements list — Service_Provider , PID_Provider , Non_Q_EAA_Provider — matches what we actually ship: OID4VP verification, PID issuance, and non-qualified EAA issuance (EHIC, mVRC, mDL). We are not a qualified trust service provider; the entitlement URIs make that explicit. Supported credential formats dc+sd-jwt , mso_mdoc , jwt_vc are declared on the registry record; each one has a live issuer + verifier path in this deployment. Independent proof surfaces. Alongside the reference registry entry, this deployment publishes an OpenID Federation entity statement at /.well-known/openid-federation , a DID document at /.well-known/did.json , an EU Trusted List at /.well-known/trust-list.xml , a Wallet Provider attestation at /.well-known/wallet-provider.jwt , and a machine-readable relying-party metadata document at /.well-known/eudi-relying-party.json . Third parties can pick whichever trust surface they prefer. Why our peer list is shorter than the raw registry. The reference registry at registry.serviceproviders.eudiw.dev/wrp is a permissionless developer sandbox: any team can POST a registration and the entry persists until manually removed. To make the peer view useful we apply reachability and validity filters before rendering the table above: (a) entries whose policyURI uses an IANA-reserved documentation TLD (per RFC 2606 §3), (b) entries whose policyURI resolves to a loopback or private address, (c) entries with a missing or non- http(s) policyURI , (d) entries whose tradeName is empty, (e) entries whose hostname does not respond, and (f) entries with no declared providesAttestations (nothing to actually verify against). We deliberately do not enumerate the individual entries we filter — the raw registry is public and anyone can diff our peer list against the source themselves. The raw and filtered counts are both shown in the "Live proof" card above so the delta is visible, and both counts refresh whenever a WRP joins or leaves the registry. ### For journalists, auditors, DPOs Nothing on this page is a claim. Everything is either a live fetch from the EU reference registry, or a public field of the WRP certificate the registry issued. If the registry drops us or a certificate expires, the cards above turn empty automatically — there is nothing static or cached for us to bluff about. Contact for verification. The tenant Data Protection Officer contact is published in the DPIA . The Records of Processing Activities are at /ropa.html . The Supervisory Authority listed in our registry record is the Information and Data Protection Commissioner of Malta. ### Frequently asked questions Is this deployment really registered on the EU Reference Registry? Yes. The Live proof card on this page fetches the entry from registry.serviceproviders.eudiw.dev/wrp in real time. The tradeName is CodeB / Aloaha Limited (VATMT14814406). You can cross-check the entry independently by opening the registry URL directly. What is a Wallet Relying Party (WRP)? Under the EU Digital Identity Wallet architecture, every verifier that asks a wallet to present a credential is a Wallet Relying Party. The EU Reference Wallet ships with a registered-WRP list; entries on that list are permitted to signal their tradeName and entitlements to the wallet consent screen. What is the wrp.p12 signing certificate for? wrp.p12 is the PKCS#12 the EU Reference Registry issued to this tenant via EJBCA. Every OpenID4VP authorization request JAR is signed with the corresponding private key. Wallets verify the JAR signature against the certificate the registry holds; without it, wallets fall back to warning the user or refusing the request. How does the wallet decide to trust our request? The wallet walks the x5c chain in the JAR header against the LOTL (List of Trusted Lists) anchor that comes with the registry cert. When the chain roots at a trusted CA and the leaf matches the WRP entry, the wallet renders our tradeName + verified badge on its consent screen. Are we a Qualified Trust Service Provider? No. Our registered entitlements are Service_Provider, PID_Provider and Non_Q_EAA_Provider (non-qualified EAA). Qualified signature or seal services require a separately notified QTSP; the entitlement URIs on our registry entry make our non-QTSP scope explicit. How do I verify without our help? Click Verify yourself on the EU registry above. It opens registry.serviceproviders.eudiw.dev/wrp directly. The payload is base64-encoded JSON; decode it locally with any base64 tool and confirm the tradeName, entitlements and privacy policy URL match what this page shows. =================================================================== # Wallet API for OEM integrators · European Digital Identity Wallet backend · native mobile-app integration · CodeB Aloaha Malta # Source: https://www.aloaha.com/wallet-api.html =================================================================== > OEM integrator API reference for the CodeB Web Wallet backend on CodeB Sovereign Communications. 25 endpoints across four capabilities: OID4VCI credential import (A, 10 endpoints), self-issue from OIDC identity (B, 2 endpoints), OID4VP credential presentation (C, 3 endpoints), and wallet operations (D, 10 endpoints). Auth via OIDC Bearer with per-OEM client_id; Wallet Attestation (WA/WIA) minting per HAIP §5.11. Shared managed hosting on phone.aloaha.com. Native-parity notes for WebCrypto and IndexedDB substitutions on iOS Keychain / Android Keystore. Ready for European Digital Identity Wallet integrations. ## Wallet API — embed the CodeB Web Wallet backend in your native mobile app. Twenty-five documented endpoints across four capability groups (A: 10, B: 2, C: 3, D: 10). OEM integrators building native iOS and Android applications call the same backend that powers our browser-based European Digital Identity Wallet (web-wallet.html) — the difference is that the native app implements the client-side crypto with the platform Keychain / Keystore instead of WebCrypto, and manages its own persistence instead of IndexedDB. The wire protocol is identical. ### A. Credential import — OID4VCI holder side Fetching a credential from an issuer (either an external one like issuer.eudiw.dev , or our own vci.ashx ). Ten endpoints wrap the OID4VCI 1.0 FINAL flow with pre-auth grant, authorization-code grant + PAR + PKCE, and RFC 7591 dynamic client registration. #### GET /.well-known/openid-credential-issuer Open # Discovers the issuer's credential_endpoint , nonce_endpoint , credential_configurations_supported , authorization_servers . Public per OID4VCI §7. ##### Response (excerpt) ``` { "credential_issuer": "https://issuer.example", "credential_endpoint": "https://issuer.example/credential", "nonce_endpoint": "https://issuer.example/nonce", "authorization_servers": ["https://issuer.example"], "credential_configurations_supported": { "eu.europa.ec.eudi.pid_mdoc": { "format": "mso_mdoc", "doctype": "eu.europa.ec.eudi.pid.1" }, "urn:eudi:pid:1": { "format": "dc+sd-jwt", "vct": "urn:eudi:pid:1" } } } ``` #### GET /.well-known/oauth-authorization-server Open # RFC 8414 authorization-server metadata: authorization_endpoint , token_endpoint , pushed_authorization_request_endpoint , registration_endpoint . Fallback if absent: /.well-known/openid-configuration . #### POST /register Open — external issuers only # RFC 7591 dynamic client registration. Present at external issuers (e.g. issuer.eudiw.dev ) whose registration_endpoint metadata field advertises this URL. Not exposed on CodeB's own vci.ashx — for OEM apps against our issuer, the OEM's OIDC client_id is issued during onboarding and does not need to be re-registered per install. Discover via A2 metadata; if the field is absent, the issuer does not support dynamic registration. ##### Request body (when supported by the external issuer) ``` { "client_name": "", "redirect_uris": ["://cb-oidc"], "grant_types": ["authorization_code"], "response_types": ["code"], "token_endpoint_auth_method": "none", "application_type": "native" } ``` #### POST /par Open (PKCE) # RFC 9126 Pushed Authorization Request. Public with PKCE + client_id . Fallback path if issuer omits PAR: /vci.ashx?par . ##### Form body ``` client_id= response_type=code redirect_uri=://cb-oidc code_challenge= code_challenge_method=S256 scope=openid credential_configuration_ids= state= issuer_state= authorization_details= ``` ##### Response ``` { "request_uri": "urn:ietf:params:oauth:request_uri:...", "expires_in": 60 } ``` #### POST /token Open (PKCE) # Two grant flavours. Pre-authorized code : grant_type=urn:ietf:params:oauth:grant-type:pre-authorized_code, pre-authorized_code, tx_code? . Authorization code : grant_type=authorization_code, code, redirect_uri, code_verifier, client_id . ##### Response ``` { "access_token": "ey...", "token_type": "Bearer", "expires_in": 300, "c_nonce": "..." } ``` #### POST /nonce Open # OID4VCI 1.0 FINAL nonce endpoint. Public. Returns a fresh c_nonce for the credential proof. #### POST /credential — SD-JWT VC Bearer # Issue an SD-JWT credential. Body carries the wallet's proof_type=jwt containing an OpenID4VCI proof-JWT signed by the wallet key. ##### Request body ``` { "format": "dc+sd-jwt", "vct": "urn:eudi:pid:1", "proof": { "proof_type": "jwt", "jwt": "" } } ``` ##### Response ``` { "credential": "", "format": "dc+sd-jwt" } ``` #### POST /credential — mDoc Bearer # Same endpoint as A7 but with format=mso_mdoc . Response is a CBOR-encoded IssuerSigned structure (base64-url). ##### Request body ``` { "format": "mso_mdoc", "doctype": "eu.europa.ec.eudi.pid.1", "proof": { "proof_type": "jwt", "jwt": "..." } } ``` #### GET Open # Fetch by-reference credential offer when the deep-link uses credential_offer_uri= instead of an inline credential_offer= . Returns the offer JSON. #### GET /.well-known/jwt-vc-issuer + jwks_uri Open # Used when verifying the issuer signature on a persisted SD-JWT. The issuer's JWT-VC issuer document + JWKS. #### GET /.well-known/web-identity Open # W3C Digital Credentials API wallet-provider discovery manifest per WICG Editor's Draft . Browsers that expose navigator.credentials.get({identity: …}) or navigator.identity.get({credentials: …}) (Chrome 128+ under origin-trial today) fetch this document to populate the credential-picker UI, so a Relying Party page can trigger a browser-mediated presentation without any custom URL scheme. ##### Response shape ``` { "provider_name": "CodeB EU Digital Identity Wallet", "provider_url": "https:///", "provider_icon": "https:///favicon.svg", "wallet_url": "https:///logineu.html", "protocols": ["openid4vp","openid4vp-v1-unsigned","openid4vp-v1-jwt"], "trust_frameworks": ["eudi-ref","eidas-2"], "supported_credentials": [ { "vct": "urn:eudi:pid:1", "format": "dc+sd-jwt" }, { "vct": "urn:eu.europa.ec.eudi:pid:1", "format": "dc+sd-jwt" }, { "doctype": "eu.europa.ec.eudi.pid.1", "format": "mso_mdoc" }, /* Additional VCTs (EHIC, mDL, PhotoID, PDA1, IBAN, MSISDN, gematik Versicherter, ...) are added to this array as their real end-to-end issuance + verification lands. We deliberately do NOT advertise credentials we cannot process yet -- see the honesty rule in codeb-honesty-gold-rule. */ ], "standards": [ "https://wicg.github.io/digital-credentials/", "https://openid.net/specs/openid-4-verifiable-presentations-1_0.html", "https://openid.net/specs/openid-connect-for-identity-assurance-high-1_0.html" ], "support_contact": "https:///contact.html", "tenant": "" } ``` Manifest is per-tenant (each tenant advertises itself as its own wallet provider). Public, unauthenticated, CORS wide open, no-store — no cookies, no PII. Trace tag [W3C-DC-API-DIAG] web-identity manifest served fires on every hit. ##### Client-side adapter — js/web-dc-api.js Feature-detected shim exposing window.CodeBDcApi for pages that want to use the DC API transport: ``` ``` ### B. Self-issue from OIDC identity The signed-in user's OIDC profile drives an on-server minting: no external issuer needed. Two endpoints on our own vci.ashx . #### GET /vci.ashx?available-attributes=1 Bearer # Lists which credential types the signed-in user is eligible for, based on their OIDC profile completeness and tenant configuration. ##### Response ``` { "subject": "", "credentials": [ { "vct": "urn:eudi:pid:1", "ready": true, "missing": [], "display": "Personal Identification Data" }, { "vct": "https://aloaha.com/vc/employee_id", "ready": false, "missing": ["employee_number"], "display": "Employee ID" } ] } ``` #### POST /vci.ashx?issue-in-session=1 Bearer # Server mints a credential using the signed-in user's OIDC profile as source. Requires the wallet's public JWK in cnf.jwk so the issued credential is bound to the wallet key. Returns an SD-JWT with disclosures. ##### Request body ``` { "vct": "urn:eudi:pid:1", "cnf": { "jwk": } } ``` ##### Response ``` { "credentials": [ { "credential": "" } ], "credential": "", "vct": "urn:eudi:pid:1", "format": "dc+sd-jwt" } ``` ### C. Credential presentation — OID4VP holder side Responding to a Verifier's presentation request. Three endpoints cover the JAR fetch (browsers only), the direct-post response, and Wallet Attestation issuance. #### GET /oidc.ashx?action=jar-proxy&url= Session (browser-only) # Same-origin proxy that returns the verifier's signed JAR ( application/oauth-authz-req+jwt ). Exists to bypass browser CORS on cross-origin request_uri fetches. Auth is same-origin session (browser cookies); no Bearer required today. Server-side hardening (as of 2026-08-12): caller must be HTTPS; target must be HTTPS and public-routable (host string check + DNS-resolved IP check); HTTP redirects refused (single-hop only, no auto-follow); upstream error bodies logged internally but NOT returned to the caller. #### POST Open (form) + WA header # Two response shapes, selected by the JAR's response_mode : - direct_post : form fields vp_token , state , optional mdoc_generated_nonce . - direct_post.jwt : form field response = JWE (ECDH-ES + A128GCM) whose plaintext is the same JSON. Optional mdoc_generated_nonce lives in the JWE's apu header per OID4VP 1.0 FINAL §8.1. Optional header OAuth-Client-Attestation: when the verifier requires HAIP §5.11 wallet attestation. #### POST /wallet-attestation.ashx Bearer # Mints a Wallet Attestation JWT (WIA / WA per HAIP §5.11) bound to the wallet's public key. Cached client-side for 23 hours. Under the OEM tier, the issuer key is the OEM's own KYB-attested key. ##### Request body ``` { "walletPublicJwk": { "kty":"EC","crv":"P-256","x":"...","y":"..." }, "nonce": "" } ``` ##### Response ``` { "wallet_attestation": "", "expires_in": 86400 } ``` ### D. Wallet operations Vault sync (encrypted server backup), narrow-scope session tokens, mDoc verification, and tenant DID discovery. #### POST /wallet-session-token.ashx Bearer # Mints a narrow-scope HS256-signed token used only for vault push / pull / delete. Trades the full OIDC access token for a short-lived storage-scoped token whose payload carries the caller's OEM azp so wallet-backup can preserve per-OEM isolation. ##### Response ``` { "access_token": "", "token_type": "Bearer", "expires_in": 600, "aud": "wallet-backup", "iat": , "exp": } ``` The minted JWT's payload additionally includes iss=codeb-wallet-session, sub, tenant, jti, azp, scope="wallet-backup:save wallet-backup:load wallet-backup:delete" . #### POST /wallet-backup.ashx?action=save Bearer # Push the encrypted vault blob to the server. The server stores it opaquely and never sees the plaintext. ##### Request body (opaque to server) ``` { "v": 1, "wrappedDeks": [ { "kek_id": "...", "dek_cipher": "..." } ], "cipher": "", "updatedUtc": "2026-08-12T18:30:00Z", "hint": "" } ``` #### GET /wallet-backup.ashx?action=load Bearer # Pull the encrypted vault blob. Response is the same opaque JSON persisted at save time. 404 {"error":"not_found"} if the user has never saved a vault. #### POST /oidc.ashx?action=mdoc-cred-verify Bearer # Server-side verification of a stored mDoc credential. Used by the wallet to display trust indicators without shipping the mDoc verify stack into the client. ##### Request body ``` { "issuerSigned": "", "docType": "eu.europa.ec.eudi.pid.1" } ``` ##### Response ``` { "ok": true, "sig_ok": true, "chain_ok": true, "issuer_cn": "...", "doc_type": "eu.europa.ec.eudi.pid.1", "mso_valid_from": "2026-08-01T00:00:00Z", "mso_valid_until": "2027-08-01T00:00:00Z" } ``` #### GET /business-wallet.ashx?action=identity Open (same-origin) # Tenant DID discovery: did_web , did_key , did_jwk , did_webvh , and wallet_id . Populates the tenant identity chips in the wallet UI. #### GET /oidc.ashx?action=end_session&post_logout_redirect_uri= Open # RP-initiated logout. Sweeps the server-side session and returns 200 text/html containing a Clear-Site-Data header plus a JS/meta redirect to post_logout_redirect_uri . Not a 302 — the response has to reach the browser so Clear-Site-Data can wipe cookies/storage before navigation. #### POST /wallet-backup.ashx?action=delete Bearer # Delete the server-side vault blob. Requires the caller to POST {"confirm":"delete"} to reduce accidental wipes. Symmetric with save/load; keyed on the same (sub, tenant, azp) . #### POST /vci.ashx?self-offer Bearer # Member-facing offer mint: builds an OID4VCI credential-offer URL that the signed-in user can consume from another device (e.g. desktop generates the QR, phone wallet scans it). Complement to B2 (which issues in-session on the same device). #### POST /oidc.ashx?action=data-deletion-request Bearer # ARF 3.0 TS7 data-deletion right endpoint. The signed-in wallet user can request server-side deletion of their PII footprint (session logs, vault, cached credentials, WA issuance history). #### GET /oidc.ashx?action=dpa-report Bearer (operator) # ARF 3.0 TS8 DPA-report endpoint. Operator-only (superuser); produces a Data Protection Authority-facing report of user activity with a 24-month cap. Not called from the wallet; documented for OEM operators. ### Native-parity summary — what your app must implement locally The web wallet uses browser primitives; native apps substitute with platform equivalents. This inventory maps each substitution. #### WebCrypto crypto.subtle substitutions - ECDSA-P256 keygen + sign (proof-JWT, KB-JWT, WA signing) → iOS SecKeyCreateRandomKey + SecKeyCreateSignature(.ecdsaSignatureMessageX962SHA256) ; Android KeyPairGenerator("EC","AndroidKeyStore") + Signature.getInstance("SHA256withECDSA") . - SHA-256 (PKCE challenge, KB-JWT hash) → iOS CryptoKit.SHA256 ; Android MessageDigest.getInstance("SHA-256") . - ECDH-ES + A128GCM (direct_post.jwt encryption) → iOS CryptoKit.KeyAgreement.ecdhKeyAgreement + Concat KDF + AES.GCM.SealedBox ; Android KeyAgreement.getInstance("ECDH") + Cipher.getInstance("AES/GCM/NoPadding") . - PKCE code_verifier / state → CSPRNG via SecRandomCopyBytes / SecureRandom . #### Storage substitutions - IndexedDB (vault, credentials, WA cache, settings) → iOS Core Data or SQLite with SQLCipher; Android Room with SQLCipher. Keys wrapped by Keychain / Keystore-held KEKs. - localStorage (dynamic-client-reg cache) → iOS UserDefaults (non-secret) or Keychain (if you consider client_id sensitive); Android EncryptedSharedPreferences. - sessionStorage (PKCE verifier) → in-memory app state; drop on backgrounding. #### Browser-only endpoints your app should skip - /oidc.ashx?action=jar-proxy (C1) — only for browser CORS bypass. Fetch request_uri directly. - Any use of navigator.credentials (WebAuthn PRF) — substitute with platform biometric-gated Keychain / Keystore keys. - Service-worker offline caching — substitute with your app's own resource cache. #### Common headers to send from your native client - User-Agent: / (native; iOS 17.4; iPhone15,3) — helps our support triage and lets us apply per-OEM rate limits accurately. - X-CodeB-Client-Id: — optional but recommended for support diagnostics. - Accept-Language: — some error responses localise error_description . OEM landing page → CSC v2 signing API Contact for OEM tenant + WA KYB =================================================================== # GoBD-compliant invoice signing · Qualified timestamp instead of WORM archive · API, Wallet, Business Wallet · CodeB Aloaha Malta # Source: https://www.aloaha.com/gobd-compliant-invoice-signing.html =================================================================== > Invoice archives that meet Germany's GoBD immutability requirement without a five-figure WORM appliance. Cryptographic signature with an RFC 3161 qualified timestamp under a QTSP on the EU LOTL. Three signing paths on CodeB Sovereign Communications: Cloud Signature Consortium v2 API, personal European Digital Identity Wallet, and Business Wallet for accounting teams. On-premise or Malta-managed. eIDAS-conformant, ready for European Digital Identity Wallet integrations. ## Qualified timestamp as a building block for GoBD-compliant retention . GoBD requires immutability — and it is technology-neutral about how you deliver it. A qualified electronic timestamp from an EU QTSP carries the statutory presumption of time accuracy and data integrity under eIDAS Art. 41(2). That is the load-bearing legal component. CodeB Sovereign Communications from Malta puts one on every signed invoice through three signing paths: API, personal European Digital Identity Wallet , or Business Wallet. ### What CodeB delivers — and what it does not. To avoid confusion: “revisionssicher” is not a statutory category . It is a professional term from Germany's VOI (Verband Organisations- und Informationssysteme, originally 10 principles) and IDW RS FAIT 3. It describes a whole system that satisfies the statutory framework: AO §146, §147; HGB §257; and the GoBD (BMF letter 28.11.2019 as amended by BMF letters of 11.03.2024 and 14.07.2025). A timestamp or a signature by itself is not a system and therefore does not make an archive “revisionssicher” on its own. Component | Role | What it delivers legally Qualified RFC 3161 timestamp | CodeB provides as a proxy to the QTSP | Load-bearing legal component. eIDAS Art. 41(2) grants the statutory presumption of accuracy of the date and time and integrity of the data linked with it. Only a qualified timestamp from a LOTL-listed QTSP carries this presumption. Advanced Electronic Signature (AdES) on a self-signed tenant CA | CodeB provides today by default | Technical tamper-evidence. eIDAS Art. 3(11): detects later changes. Because the issuing CA is Aloaha-controlled, signer authenticity is only as trusted as our CA — no third-party, QTSP-attested identity. Qualified Electronic Signature (QES) | Available optionally via the wallet paths; not the default on the API path | eIDAS Art. 25(2): legal equivalence to a handwritten signature. For invoices under UStG §14(3), not required since 2011. Procedural documentation + orderly filing | Your responsibility, not ours | GoBD Rn. 151–155 — without this documentation no archive is revisionssicher, regardless of the technology. ### What does “GoBD-compliant” actually require? Revisionssicherheit is not a German statute. It comes from VOI (Verband Organisations- und Informationssysteme) and today is captured in IDW RS FAIT 3. The statutorily relevant provisions are AO §146 (immutability), §147 (retention), HGB §257 and the GoBD (BMF letter 28.11.2019 as amended by BMF letters of 11.03.2024 and 14.07.2025). Five properties derive from GoBD: Property | Meaning | Classically satisfied by | Signature-based satisfied by Completeness | All retention-mandated invoices are recorded. | Filing process + control | Filing process + control (unchanged) Correctness | Booking matches invoice. | Internal control procedure | Internal control procedure (unchanged) Timeliness | Invoice is recorded promptly. | Filing process | Timestamp records the signing moment Order | Invoice is findable and machine-processable. | Archive indexing | Indexing + PDF/A-3 with structured XML payload Immutability | Invoice cannot be altered undetectably after filing. | WORM hardware, blockchain, or audit-monitored database | Cryptographic signature + qualified timestamp ### The qualified timestamp — and why it carries the legal weight. The central legal building block of our offering is the qualified electronic timestamp under eIDAS Art. 42, issued by a Qualified Trust Service Provider (QTSP) on the EU List of Trusted Lists (LOTL). CodeB proxies the QTSP call, defaulting to Sectigo. The QTSP is the trust anchor — not CodeB. eIDAS Art. 41(2) states: “A qualified electronic time stamp shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound.” This presumption is evidentiary in civil proceedings (analogous to §371a ZPO in Germany) and is accepted by tax auditors. What about the signature in front of it? The AdES signature we ship by default uses an Aloaha-controlled CA certificate and therefore provides only tamper-evidence , not third-party-attested signer identity. For GoBD immutability that is enough, because the qualified timestamp attests the data's integrity. For formal signer attribution (e.g. in an authorship dispute), the stronger choice is a Qualified Electronic Signature (QES) with a qualified certificate — not, however, required for invoices by UStG §14(3). ### Three signing paths at CodeB. The right path depends on invoice volume and user profile. All three produce a PAdES-signed PDF with a qualified timestamp and long-term validation data (PAdES-B-LT), verifiable across the mandatory ten-year retention window. #### 1. Sign via API The Cloud Signature Consortium v2 endpoint /csc/v2/signatures/signHash signs a SHA-256 hash of an invoice with an OIDC-authenticated user certificate. Ideal for accounting software, ERP integrations and automated invoice output. Curl, Node.js, C#, PHP samples in the HOWTO. HOWTO: sign via API → #### 2. Sign via personal EU Wallet The invoice issuer scans a QR code, confirms in their European Digital Identity Wallet (EUDI wallet app on their phone), and receives back a signed PDF with PAdES signature. Ideal for freelancers, tradespeople and small self-employed issuers signing as natural persons. HOWTO: sign via wallet → #### 3. Sign via Business Wallet An authorised employee or an automated batch signs on behalf of the company through a Business Wallet instance under CSC v2 Remote Signature Service Protocol. With audit trail of who signed what when. Ideal for accounting teams handling several hundred invoices per month. HOWTO: Business Wallet → Preview paths are working; wallet integrations are in pilot with selected partners. The API path is production-available and documented at /csc-v2-api . ### Legal basis — short and precise. The relevant provisions and what they actually require: Provision | Requires AO §147(3) | Ten-year retention for invoices and booking documents, counted from the end of the year of issue. AO §146(4) | Bookings and other required records may not be modified in a way that leaves the original entry undetectable. HGB §257 | Commercial books, invoices and booking documents must be retained for ten years and rendered legible during that time. UStG §14(3) | VAT-relevant invoices may be transmitted electronically; authenticity of origin and integrity of content must be ensured — via internal control procedure, QES or EDI. BMF letter 28.11.2019 (GoBD) | Five-property canon: completeness, correctness, timeliness, order, immutability. eIDAS Art. 3(11) | Advanced Electronic Signature: uniquely linked to the signatory, under sole control, detects later changes. eIDAS Art. 42 | Qualified electronic timestamp: issued by a QTSP listed on the LOTL. ETSI EN 319 142-1 | PAdES baseline signatures: B-B (baseline), B-T (with timestamp), B-LT (long-term validation), B-LTA (archival). ### Cost comparison: WORM appliance vs. signature-based archive. An illustrative comparison for a mid-sized company with roughly 500 inbound and outbound invoices per month, ten-year retention: Line item | WORM archive (classic) | Signature-based (CodeB) Acquisition | Hardware WORM 5,000–15,000 EUR, or cloud archive setup | One-off software licence, or managed service Running cost | 15–25% maintenance p.a., or monthly cloud subscription per user | Signature volume ∼ cents per signature; qualified timestamp ∼ cents each Storage | Proprietary | File system, your choice of location, your backup 10-year migration | Hardware refresh + data migration required | PDF/A stays PDF/A; no migration needed Vendor lock-in | Usually strong: format, API, certification | Open standards: PAdES, RFC 3161, CSC v2 Cloud sovereignty | Often US-cloud (CLOUD Act, Schrems II) | On-premise or Malta-managed — EU law Savings for an SME are typically in the four-digit range per year, plus a marked reduction in IT complexity. For smaller businesses under 100 invoices per month, the difference is even more pronounced. ### Why CodeB from Malta. Four points that German mid-market operators find here and rarely in US-hosted cloud-only offerings: - EU sovereignty. Aloaha Limited is based in Malta — an EU member state with an English-language legal system, GDPR applicability and a LOTL-listed national trust list. No CLOUD Act reach, no Schrems II constructs. - On-premise option. The entire signature infrastructure runs on your own IIS. The only external dependency is the timestamp lookup at the QTSP — configurable to the QTSP of your choice. - Open standards. The Cloud Signature Consortium API v2 is an ETSI/CEN-based vendor-neutral API. PAdES is ISO 32000-2. RFC 3161 is an IETF standard. No vendor lock-in. - Ready for the European Digital Identity Wallet. The signature infrastructure integrates with OIDC + OID4VP so signatories can use their personal or Business Wallet as signing identity — the incoming EU regulatory shape of digital identity. ### Make invoices immutable at a fraction of the WORM cost. Try the signature API with a sample call, or request a Malta-managed offer. ### Frequently asked questions What does GoBD-compliant actually mean for invoice archives? Revisionssicherheit is not a German statute. It is a professional term from VOI and IDW RS FAIT 3 that describes a whole system (technology plus filing process plus procedural documentation) satisfying the statutory framework of AO §146, §147, HGB §257 and the GoBD. The statutorily binding requirement is immutability (AO §146(4), GoBD Rn. 58 ff.), and the GoBD is explicitly technology-neutral about its technical realisation: hardware (WORM), software (locks, versioning, logging) and organisational measures rank equally, and combinations are allowed. A qualified electronic timestamp under eIDAS Art. 42 is a recognised technical realisation because it carries the statutory presumption of data integrity under eIDAS Art. 41(2). Neither a signature nor a timestamp makes an archive revisionssicher on its own -- without the accompanying procedural documentation and orderly filing process, the GoBD is not satisfied. Does a digital signature really replace a WORM archive? It is not the signature that replaces the WORM archive but the qualified electronic timestamp that delivers the alternative, GoBD-recognised technology-neutral answer to the immutability requirement. The timestamp binds the state of the document to a moment attested by a Qualified Trust Service Provider and carries the statutory evidentiary presumption of data integrity under eIDAS Art. 41(2). The AdES signature CodeB ships by default with a self-signed CA additionally provides tamper-evidence but is not a third-party-attested signer identity. The other GoBD properties -- completeness, order, timeliness, machine processability -- remain your responsibility via procedural documentation and filing process. No archive becomes revisionssicher without these, regardless of the cryptography used. What is the difference between QES, AdES and PAdES? EU Regulation 910/2014 (eIDAS) defines three signature classes. A simple electronic signature is essentially any electronic acknowledgement, including a scanned handwritten mark. An Advanced Electronic Signature (AdES, Art. 3(11)) is uniquely linked to the signatory, under their sole control, and detects later changes. A Qualified Electronic Signature (QES, Art. 3(12)) is an AdES based additionally on a qualified certificate from a QTSP and a Qualified Signature Creation Device (QSCD, typically a hardware HSM or smartcard). QES has the legal equivalence of a handwritten signature under Art. 25(2). PAdES is the PDF signature format (ETSI EN 319 142-1) with four conformance levels B-B, B-T, B-LT and B-LTA. For invoices, AdES plus a qualified timestamp is almost always sufficient because German tax law does not mandate QES for invoices. Does the German tax authority require a qualified signature on invoices? No. Since the German Steuervereinfachungsgesetz of 2011, a qualified electronic signature is no longer required for electronic invoices under UStG Section 14(3). Sufficient is an internal control procedure that establishes a reliable audit trail between invoice and delivery. QES remains a recognised but not exclusive method. AdES plus qualified timestamp is now considered best practice because it demonstrates GoBD immutability cryptographically without the QSCD-per-signature cost. How does CodeB compare to classic WORM solutions cost-wise? Classic WORM storage for GoBD archives sits in the several-thousand-euro range for the appliance plus ongoing maintenance. On-premise systems add hardware refresh cycles; cloud archives add per-user or per-terabyte monthly subscriptions. The CodeB signature and timestamp service bills per signature or timestamp, or as a flat allotment for small volumes. The qualified timestamp itself is purchased from an external QTSP (e.g. Sectigo, DigiCert) in the low single-digit cent range per timestamp; the signature itself costs nothing beyond the base software licence. Combined, this is a fraction of a WORM appliance for a mid-sized company. What are the three signing paths CodeB provides? (1) API signing: The Cloud Signature Consortium v2 endpoint /csc/v2/signatures/signHash signs a SHA-256 hash of an invoice with an OIDC-authenticated user certificate. Ideal for accounting software, ERP integrations and automated invoice output. (2) Personal EU Wallet signing: The invoice issuer scans a QR code, confirms in their European Digital Identity Wallet (EUDI wallet on their smartphone), and receives back a signed PDF with a PAdES-B-LT signature. Ideal for freelancers, tradespeople and small self-employed issuers signing as natural persons. (3) Business Wallet signing: An authorised employee or an automated batch signs on behalf of the company through a Business Wallet instance under the CSC v2 Remote Signature Service Protocol. With audit trail of who signed what when. Ideal for accounting teams handling several hundred invoices per month. Where is the qualified timestamp obtained? A qualified timestamp under eIDAS Art. 42 is issued by a Qualified Trust Service Provider (QTSP) on the EU List of Trusted Lists (LOTL). CodeB defaults to Sectigo (URL configurable via the registry value HKLM\SOFTWARE\CodeB\TSAURL). Customers with their own QTSP relationships can point at a different endpoint; the signature module accepts any RFC 3161-compliant TSA server. Malta-based customers can attach to the Maltese QTSP Gattaca. Can CodeB be deployed on-premise? Yes. CodeB Sovereign Communications runs as an on-premise IIS deployment with no cloud dependency other than the timestamp lookup at the QTSP. For regulated industries (healthcare, legal, accounting) on-premise is often mandatory. Alternatively, Aloaha Limited operates the software as a managed service from Malta. Either operating mode produces identically signed PDFs; the legal outcome of the signature is unaffected. How long must a signed invoice be retained? Ten years. AO Section 147(3) mandates ten-year retention for booking documents including electronic invoices. The period begins at the end of the calendar year in which the invoice was issued. Signature and timestamp must remain verifiable across that period, which is why PAdES-B-LT (long-term validation, i.e. embedded OCSP and CRL responses) is the practical target for invoice archives -- more than PAdES-B-T alone. For extra-long retention or certificate expiry during the retention period, PAdES-B-LTA with periodic archive timestamps is the answer. Why Malta? CodeB Sovereign Communications is produced by Aloaha Limited in Malta -- an EU member state with an English-language legal system, GDPR applicability, eIDAS conformance and a LOTL-listed national trust list. An invoice signed and timestamped here is therefore a trust service under eIDAS Art. 25 across Germany and the EU. Software and trust services from non-EU jurisdictions (particularly US providers) bring CLOUD Act and Schrems II risks that many German companies actively avoid when handling sensitive invoice data. =================================================================== # European Digital Identity Wallet procurement readiness · Malta · on-premise sovereign hosting · ARF 3.0 · CodeB Aloaha # Source: https://www.aloaha.com/eudiw-procurement.html =================================================================== > Procurement-ready European Digital Identity Wallet stack from Aloaha Limited, Malta. Personal Wallet, Business Wallet, Wallet Relying Party verifier registered on the EU reference registry, PAdES signing (GoBD-compliant), Malta eID card integration via NFC at LoA High, on-premise sovereign hosting dual-DC deployment with HSM supply chain, ARF 3.0 + eIDAS 2.0 (Regulation (EU) 2024/1183) aligned, wallet-holder privacy hardening on the IETF Token Status List via Feistel FF1 slot-ID permutation. Certification-support commitment. Made in Malta for the 30-country EEA rollout. ## European Digital Identity Wallet procurement readiness — Malta One page mapping Aloaha Limited 's shipped EUDIW stack — Personal Wallet, Business Wallet, Wallet Relying Party verifier, Malta eID Card integration, PAdES signing and sovereign-hosted on-premise delivery — onto the capability tables procurement officers evaluate. Every claim links to a live proof surface or a public specification. Nothing on this page is aspirational. ### Capability map Feature grid, each row a link to the underlying page or specification. #### Personal EU Wallet Web PWA + native Android + native iOS. Receives PID + mDL + PhotoID + EHIC + PDA1 issuance. Presents credentials via OpenID for Verifiable Presentations. HAIP-profiled. urn:eudi:pid:1 canonical VCT. #### Business Wallet The wallet your accounting / operations team uses. Signs invoices with CSC v2 to PAdES-B-LTA (GoBD-compliant), verifies incoming credentials, sits inside your existing SSO. #### Wallet Relying Party verifier OpenID4VP verifier registered with registry.serviceproviders.eudiw.dev . Accepts credentials from any EU Reference Wallet. Publishes WRP certificate + intended-use certificate per ARF 3.0 §5. #### Malta eID Card — ready today LoA High authentication over NFC via our native Android integration. Fully implemented PACE (Password Authenticated Connection Establishment, BSI TR-03110) chip-authenticated channel to the eID card. Full backward compatibility with all valid Maltese eID + residence cards in circulation regardless of chip / OS / applet / certificate profile / APDU / PIN / QSCD. #### PAdES signing (GoBD, eIDAS AdES) PAdES-B-B / B-T / B-LT / B-LTA. Cloud Signature Consortium v2 API. Auto-degrade cascade. Every signature carries an RFC 3161 qualified timestamp under a QTSP on the EU LOTL. #### W3C Digital Credentials API Browser-native VP transport per WICG Editor's Draft. Manifest at /.well-known/web-identity . Feature-detected client adapter upgrades OpenID4VP calls automatically when the browser supports it; falls back cleanly on everything else. #### OpenID Federation 1.0 Entity statement at /.well-known/openid-federation . ES256-signed. Third parties merge us into their federation trust anchor without bilateral configuration. #### Access model (6 roles) superuser (operator-scope), admin (per-tenant), poweruser (elevated quotas), user (default), siponly (SIP-only), guest (sign-in only). Passwordless admin role assignment via credentials=setrole . ### Delivery model #### Hosting — Malta on-premise co-location, dual data centre Production tier deploys inside the national dual data-centre configuration with dark-fibre redundant paths, on 42U cabinets with standard 19″ rack-mount HSMs (bidder supplies + installs + maintains). Dev / test / staging / pre-production run off-site per typical large-scale-procurement patterns, keeping the on-prem footprint minimal. Environment | Location | Hardware sourcing Production | National data centre, Malta (dual DC) | Bidder-supplied hardware + HSMs; maintained by bidder Pre-production | Off-site (bidder facility) | Bidder-owned; mirrors production HSM class Staging | Off-site (bidder facility) | Bidder-owned Development | Off-site (bidder facility) | Bidder-owned #### What is shipping today Personal Wallet (web PWA + native Android + native iOS) and Business Wallet are live. The Wallet Relying Party verifier is registered on the EU reference registry. PID issuance runs today in three VCT forms including mDoc. Native eID-card NFC login is shipping via our Android integration. PAdES-B-B / B-T / B-LT / B-LTA signing runs today with an auto-degrade cascade. The W3C Digital Credentials API browser transport is wired at /.well-known/web-identity and activated automatically where browser support exists. OpenID Federation 1.0 entity statements, EU Trusted List, DID document and RP metadata are published. ### Standards our stack implements These are the specifications we implement in code. This is not a claim of third-party accreditation or certification. Formal EUDIW wallet conformity schemes are still being finalised by national and EU authorities; where a scheme exists we support the assessment process (see below). Standard / specification | Where it lives on our stack eIDAS 2.0 — Regulation (EU) 2024/1183 amending 910/2014 | Wallet Solution scope, WRP entry, PID issuance Architecture Reference Framework 3.0 (ARF 3.0) | arf-conformity.html , WUA, WRPAC, intended-use cert CIR 2024/2977 (PID Rulebook v1.1) as amended by CIR 2026/1731 | PID data-set + issuance, W3C DC API notice CIR 2024/2979 (Wallet Attestations, ARF core) as amended by CIR 2026/1731 | WUA per Annex Ib, pseudonyms per Art 14, Trust Mark per Art 4 CIR 2024/2980 (Relying Party Registrar) as amended by CIR 2026/1731 | WRP registration + intended-use cert lifecycle CIR 2024/2981 (WSCD / RWSCD) | PID secret key in RWSCD; other secret keys can live on device TEE/SE per amended Clause 4.2.3.4.1 CIR 2024/2982 (Presentation) as amended by CIR 2026/1731 | OpenID4VP verifier surface CIR 2025/848 (Trust Services PKI) as amended by CIR 2026/1730 | WRPAC per Annex IV/V; ETSI EN 319 411-8 as benchmark OpenID4VP 1.0 Final | Verifier + wallet; DCQL native; HAIP-strict mode OpenID4VCI 1.0 Final | Issuer + wallet; HAIP-profiled W3C Digital Credentials API (WICG ED) | wallet-api.html #a11 ; manifest at /.well-known/web-identity ETSI EN 319 142-1 (PAdES B-B/B-T/B-LT/B-LTA) | CSC v2 API ETSI EN 319 122-1 (CAdES) | CMS SignerInfo layout RFC 3161 (Timestamp) | TSA fetch inside every B-T+ signature IETF Token Status List (draft-ietf-oauth-status-list) | /bitstring-status.ashx?format=oauth-token OpenID Federation 1.0 | /.well-known/openid-federation SD-JWT VC + ISO 18013-5 mDoc | Both formats in issuer catalogue + verifier accept list ### Wallet-holder privacy on the status list The IETF Token Status List draft lets a verifier check revocation by reading one bit at credentialSubject.status_list.idx . If those idx values are handed out sequentially, an observer of many status-list reads can correlate credentials into batches — adjacent idx means adjacent issuance, which leaks issuance order and onboarding-batch structure. Our European Digital Identity Wallet issuer surface pushes each sequential internal counter through a keyed Feistel Format-Preserving Encryption permutation (NIST SP 800-38G FF1, seeded by a per-tenant-per-purpose 32-byte random value) before the value is published in the credential. The mapping is bijective — every slot still points to exactly one credential and every credential still has exactly one slot — but consecutive issuances land on pseudorandom-looking slot IDs. Bitmap encoding, publisher endpoint ( /bitstring-status.ashx ) and verifier code path are unchanged; only the mapping is scrambled. Mixed-mode is safe: credentials already issued with sequential slots continue to be revocable in the same bitmap. This is an operator-configurable privacy hardening, on by default for new tenants. It is not encryption — the bit value at each slot is still public. It only removes the ordering side channel. ### Independent proof surfaces Every claim on this page is machine-verifiable from a third party, not just our word. - Live EU Reference Registry entry — fetched fresh on every page load from registry.serviceproviders.eudiw.dev/wrp . - OpenID Federation entity statement — ES256-signed JWT. - EU Trusted List — ETSI TL XML. - Wallet Provider attestation — HAIP §5.11 signed JWT. - RP metadata — machine-readable relying-party JSON. - W3C DC API wallet-provider manifest — WICG registration doc. - DID document — did:web . - Trust Federation statement — bilateral trust JWS. ### Certification support commitment Formal EUDIW wallet certification schemes are still being finalised by national and EU authorities. We commit to supporting the certification process end to end — conformance testing, interoperability testing, security testing and cooperation with the assigned assessor. This is scoped per engagement and can be structured as a milestone-gated commitment. ### Data handling & residency Data stays inside EU jurisdiction end to end. No US cloud, no CLOUD Act exposure. Signing pipeline is memory-only (no temporary files, no server-side PDF retention — see the CSC v2 data-handling section ). Audit trail records only cryptographic metadata (hashed username, credential ID, first-8 chars of hash-to-sign, signature length, cert serial — no PDF content, no filename, no reason string). GDPR minimisation compliant (Art 5(1)(c)). ### Where to go next → Solution page — Malta EU ID Wallet software (Personal + Business + Verifier) → Wallet API reference (25 endpoints, includes W3C DC API discovery) → CSC v2 signing API (PAdES-B-LTA + GoBD compliance) → Business Wallet API → EU Wallet integrations (verifier surface) → EU Reference Registry entry — live proof → ARF 3.0 conformity → 26 integration cookbooks → Roles & access model → Wallet OEM & embedding → Contact for a formal RFP response ### Frequently asked questions Is the wallet certified under an EU or national scheme? Formal EUDIW certification schemes for wallets are still being finalised by national and EU authorities. Aloaha commits to supporting the certification process end to end — conformance testing, interoperability testing, security testing and audit cooperation. Can the solution be hosted on-premise in a Malta sovereign data centre? Yes. Production deployment supports Malta on-premise co-location in a dual data-centre configuration with dark-fibre redundant paths. The bidder supplies, installs and maintains all hardware including HSMs. Development, testing, staging and pre-production environments can be hosted off-site per typical large-scale-procurement patterns. Does the wallet integrate with the Maltese eID card? Yes and it is ready today. Full backward compatibility with all valid Maltese eID and residence cards in circulation regardless of chip, operating system, JavaCard applet, certificate profile, cryptographic algorithm, APDU command set, PIN lifecycle or QSCD implementation. LoA High authentication over NFC is supported today via our native Android integration with a fully implemented PACE chip-authenticated channel per BSI TR-03110. Are the PID BirthPlace and Nationality claims supported? Yes. Both claim paths are wired in the PID issuer today (vci.ashx type-metadata, DCQL emission and runtime insertion). When eid.gov.mt production adds these fields (planned end 2026), a per-tenant PID profile update populates the values with no code work required. Is the eIDAS scope only the 27 EU member states? No. eIDAS 2.0 covers the entire European Economic Area, 30 countries. The 27 EU Member States must offer at least one certified wallet by December 2026. Norway, Iceland and Liechtenstein follow the same framework with roughly one additional year of lag. How do you protect the wallet-holder against status-list correlation? Our European Digital Identity Wallet issuer runs each sequential internal counter through a keyed Feistel Format-Preserving Encryption permutation (NIST SP 800-38G FF1, seeded by a per-tenant-per-purpose 32-byte random value) before the value is published as the credential's status-list index. Consecutive issuances land on pseudorandom-looking slot IDs, so an observer of many status-list reads can no longer group credentials into batches by adjacent index. The permutation is bijective, the bitmap encoding is unchanged, and verifiers see the same IETF Token Status List that the base specification produces. =================================================================== # Aloaha RDPLauncher · one-click Remote Desktop tray + Get Online Help (10-digit help code) + consent-gated remote support on Windows · Aloaha Limited # Source: https://www.aloaha.com/rdplauncher.html =================================================================== > Aloaha RDPLauncher (Aloaha RDP System Tray): a small Windows tray application that lists your .rdp connections in the system tray, stores logons securely with Windows DPAPI and starts Remote Desktop with one click. Ships with Get Online Help — two clicks show a 10-digit help code, your helper types it and takes control of your screen without further clicks (only with your permission). Also joins CodeB / Aloaha video meetings in a window of its own with screen sharing and consent-gated remote support. Free for private use; commercial licence on request. No installer. No administrator rights. No telemetry. Per-monitor DPI aware, sharp on 4K. ## All your Remote Desktop connections one click away in the system tray — plus Get Online Help in two clicks. Aloaha RDPLauncher (tray name: Aloaha RDP System Tray ) lists every .rdp connection in the Windows system tray, stores the logon inside the connection file with Windows DPAPI encryption and starts Remote Desktop with one click — no password prompt every time. It also runs Get Online Help : two clicks show a 10-digit help code, and your helper takes control after your consent — from Aloaha RDP System Tray or from a normal browser. Sending this to a customer who needs help? Use the short step-by-step page: Remote support (English) · Fernwartung (Deutsch) . Single RDPLauncher.exe · no installer · no administrator rights · Windows 10 / 11 / Server 2016+ with .NET Framework 4.8, 32-bit and 64-bit · version 5.1.0.0 · per-monitor DPI aware (sharp on 4K). Get help in two clicks Your help code: 301 404 9694 Read the number to your helper. They type it into Aloaha RDP System Tray » Online Meeting…, or open the Copy link in any browser. Control starts after you click Share . ### Get help in two clicks. No installer for the helper. Right-click the Aloaha RDP System Tray icon and pick Get Online Help . A window opens with a 10-digit code at the top: Your help code: 301 404 9694 Copy code · Copy link Windows asks you to share, with the picker already on Entire Screen because a helper can only control what they can see. Click Share , read the number to your helper by phone, and they take control — from Aloaha RDP System Tray on their own PC, or from a normal browser using the Copy link. #### What the user does - Tray icon » Get Online Help . The window opens with a fresh 10-digit code. - Click Share on the Windows picker (already set to Entire Screen ). - Tell the code to your helper. When they arrive, the window shows "In the room: Anna" so you see who joined. - Optionally click Lock room so nobody else can join. - When you close the window, the code stops working. A new one is generated next time. #### What the helper does - Open Aloaha RDP System Tray » Online Meeting… and type the code (spaces, dashes and dots are ignored, so 301 404 9694 works the same as 3014049694 ) — or open the Copy link the user sent, in any browser. - Take control. A bar on every screen shows who is controlling the PC. The zip includes a Get Remote Help shortcut. Users who need help occasionally can double-click that shortcut and skip the tray menu — the Get Online Help window opens directly. Whoever knows the number can see and control your screen until you close the window. Give it only to the person actually helping you, never to someone who calls you unexpectedly. That is how support scams work. You get a fresh number every time. Wording rule: this is help you actively give someone with a code you show and share, not "unattended access". Someone must be at the PC to open Get Online Help and click Share. ### A small tray helper for people who use Remote Desktop every day. You keep your .rdp connection files in one folder. RDPLauncher lists them in the system tray. Click a connection and the standard Windows Remote Desktop client ( mstsc.exe ) opens, already logged in. The logons live inside the connection files, encrypted with Windows DPAPI so only your Windows user on this PC can decrypt them. Because the files stay in the mstsc-format, Remote Desktop can still open them directly. Nothing about the connection is hidden or proprietary. Alongside the RDP menu, RDPLauncher can run Get Online Help , join a CodeB / Aloaha video meeting in a window of its own, and let a helper you invited take control of your screen — only after your permission. ### For users, and for administrators. #### For users - Tray menu Call RDP Hosts : every .rdp file in the RDP folder, one click to connect. - Call RDP starts the plain Remote Desktop client; Call smartRDP lets you pick any .rdp file and connect. - Edit RDP Hosts : small dialog for host (optionally with port), user name, domain and password. Buttons: Save , Save and Call RDP , Save as (copy a connection), Notepad (edit the file directly), Open Folder (the RDP folder in Explorer). - Password entered twice (repeat check) and stored encrypted with Windows DPAPI for your Windows user on this PC. Nobody else, and no other PC, can decrypt it. - Automatically launch on startup : pick one connection that opens when the tray app starts. - Start with Windows toggle: one click to start the tray automatically at logon (per user), one click to remove it again. - Works with IPv4, host names, IPv6 addresses, custom RDP ports and network (UNC) folders, in any encoding. - Get Online Help : a 10-digit help code, guided share, see section 1 . - Online Meeting… : join a CodeB / Aloaha video meeting in a window of the tray app (no separate browser). - Optional Tools submenu with the Command Prompt (hidden by default; showable via the cmd switch). #### For administrators - Master folder (registry MasterRDPFolder ): a read-only, admin-managed set of connections. Users can use but not edit them. - Global folder (registry GlobalRDPFolder ): machine-wide connections shown to every user, added to their own. - Per-user folder (registry RDPFolder ), with automatic fallback to Documents\RDPFiles when none is configured. - Every tray menu item can be shown or hidden per user or machine-wide through simple registry switches under HKCU\Software\Aloaha\SysTray and HKLM\Software\Aloaha\SysTray — including hiding Exit or the tray icon itself, for kiosk / locked-down desktops. - One instance per user session, safe on Windows Server 2016+, Remote Desktop Session Host and RDS environments. - Per-monitor DPI aware . The tray, the Get Online Help window and the meeting window are sharp at 100 % / 125 % / 150 % / 175 % / 4K. Remote control coordinates are exact at any scaling on either side. Scaling is picked up from Windows at sign-in. - Upgrade-safe : settings, registry values and .rdp files stay compatible with older RDPLauncher builds, and a backup of all configuration is created automatically on first start of a new version. - Built-in HTML manual (tray menu Help ) and About dialog with contact data. After a meeting, About also shows the meeting page's build tag — helpful for support calls. - No log files, no telemetry. ### Screen sharing and consent-gated remote support in a window of the tray app. #### Online Meeting… Opens a CodeB / Aloaha video meeting in a window of the tray app — no separate browser. Room code or invite link, or Create new room and Copy invite link . Works without a microphone or camera (the tray then suggests sharing the screen). The meeting server is configurable; the default is phone.codeb.io . #### Screen sharing Choose a whole screen, a window or a browser tab. A clear orange bar "You are sharing your screen" with Stop sharing is always visible while sharing. In Get Online Help the picker opens already on Entire Screen , because that is what remote control needs. #### Remote support — let someone control your screen (only with your permission) - A participant clicks Request control on your picture. - You see who is asking, with a verified identity when the meeting server confirmed it, otherwise marked Unverified . You must tick "I trust …" and click Allow . Deny is the default and is chosen automatically after 60 seconds. - While someone has control, a bar on every screen says "name is controlling your screen" with Stop . Ctrl+Alt+F12 also stops it at any time. - Control also ends automatically when you stop sharing, leave the meeting, lock Windows, after 10 minutes without remote input, and after 30 minutes at most (your helper can ask again). - Only while a whole screen is shared, so the helper can only click what they can see. Only one helper at a time. - The meeting window minimises itself while someone has control, and comes back afterwards. - The helper's mouse pointer takes the same shape as on your computer (arrow, text cursor, hand, resize arrows, program cursors). Aloaha RDPLauncher does not allow unattended access or control of a PC without the user. Someone must be at the PC to share the screen. A plain meeting-room link never gives control. Only an invite link that carries an access code the user created and sent themselves does — see section 5 . #### Helping someone You can help from Aloaha RDP System Tray or from a normal browser in the same meeting — the person being helped does not care which one you use. The Request control button appears only for participants who use Aloaha RDP System Tray, because that is the client that can actually be controlled. ### Remote help with an access code (like a session password). When you join a meeting you can turn on Remote help: allow control with an access code . The tray app generates a random 6-character code (letters and digits, without confusable characters), shows it in the meeting window with a Copy code button, and lets you pick: - Validity : 10 minutes up to 24 hours, or until the meeting window closes (default 30 minutes). - Uses : once, 2, 3, 5, 10 times, or any number of times (default once). Read the code to your helper. When your helper enters the code with the Request-control button, control starts without the Allow dialog. A wrong code just shows the normal Allow / Deny dialog. Three wrong codes block the code until you create a new one. In the Join Meeting dialog you can also tick Put the code into the invite link . The tray app then copies a link like https://phone.codeb.io/room.html?room=…#rc= . The code is in the URL fragment only, so the meeting server never sees it and it never reaches server logs, proxies or a Referer header. When your helper opens the link, the page strips the fragment from the address bar immediately and requests control as soon as you share the whole screen — with no click on either side. Never read an access code to a caller you did not expect — even if they say they are from IT, your bank, Microsoft or Aloaha. Give a code only to a person you already know and trust, and only for the moment you need help. Prefer the once setting so the code is used up after one session. #### Honest limits - The person who is being helped needs Aloaha RDP System Tray on Windows . The helper can join from a normal browser. - Windows does not let a normal program operate windows that run with administrator rights (for example UAC prompts) or the Windows lock screen . If your task needs elevation, you dismiss the UAC yourself; the helper waits. - Remote control needs a whole-screen share. Sharing a single window or a tab does not enable it. ### Three steps for RDP. Two clicks for online help. #### Remote Desktop - Put your .rdp files in the RDP folder (default Documents\RDPFiles ). - Open Edit RDP Hosts and set user name, domain and password once. RDPLauncher writes them encrypted into the file with Windows DPAPI. - Click the connection in the tray. Remote Desktop opens, already logged in. Administrators can put an admin-managed set of connections in MasterRDPFolder (read-only) and a shared set in GlobalRDPFolder . Users see all three folders in one menu. #### Get Online Help - Tray icon » Get Online Help . Copy the 10-digit code, click Share . - Read the code to your helper. They type it into Aloaha RDP System Tray » Online Meeting… , or open the Copy link in a browser. ### Central folders, registry switches, RDS-friendly. Every tray menu entry can be shown or hidden with a REG_SZ value under HKCU\Software\Aloaha\SysTray (per user) or HKLM\Software\Aloaha\SysTray (machine-wide, needs administrator rights only to write). "1" shows the entry, "0" hides it. Value name | Controls editrdp | Edit RDP Hosts dialog rdplist | Call RDP Hosts submenu (the list of your .rdp files) callrdp | Call RDP entry (plain mstsc) tools | Tools submenu cmd | Command Prompt entry inside Tools (hidden by default) exitvisible | Exit entry visibility trayvisible | The tray icon itself autostart | Start-with-Windows entry onlinehelp | Get Online Help entry joinmeeting | Online Meeting entry help, about | Help (HTML manual) and About dialog Historic note: earlier RDPLauncher builds had a Tools submenu with browser and Adobe entries and a separate Free Online Meeting link. Those were removed; the switch names adobe , ie , firefox , chrome , rdp and meeting no longer exist in the current build. RDP folders (each a REG_SZ, points at a folder path): - HKLM\Software\Aloaha\CSP\MasterRDPFolder — admin-managed, read-only for users. - HKLM\Software\Aloaha\CSP\GlobalRDPFolder — machine-wide, added to every user's list. - HKCU\Software\Aloaha\CSP\RDPFolder — per user (falls back to Documents\RDPFiles ). ### Your passwords, your consent, your network. - DPAPI encryption per Windows user and per PC. Passwords are never stored in plain text. Temporary copies are deleted as soon as the Remote Desktop client has read them. - No logs, no telemetry. Network traffic goes to the meeting server (default phone.codeb.io ) only while a Get Online Help or Online Meeting window is open. Remote Desktop connects to the servers you choose. - Remote support only with consent : Allow click or a user-created access code. Always visible while it is happening. Instant Stop. Automatic end on lock, disconnect, share stop, 10 minutes without input, 30 minutes maximum. - Camera, microphone and screen sharing only after you allow them, and only for the meeting server. - No administrator rights for any function. - EU-based publisher and default meeting server. Organisations that want full sovereignty can self-host the meeting server on their own Windows + IIS and point RDPLauncher at it. ### No installer. Download, unzip, run. #### Aloaha RDPLauncher · 5.1.0.0 Download: https://www.aloaha.com/download/rdplauncher.zip The zip contains RDPLauncher.exe , a readme rdplauncher.txt , and a Get Remote Help shortcut. About 2 MB. #### Install in 30 seconds Aloaha RDPLauncher does not need an installer. There is nothing to click Next through, no admin prompt, no service to allow, no reboot. Just three steps: - Download RDPLauncher.zip from the link above. - Unpack the zip anywhere — your Documents folder, a shared network folder, a USB stick, wherever. The location does not matter, because RDPLauncher keeps its settings in the Windows registry rather than next to the exe. - Double-click RDPLauncher.exe . The Aloaha RDP System Tray icon appears in the notification area next to the Windows clock. Right-click it to see the menu — your .rdp connections, Get Online Help , Online Meeting… , Edit RDP Hosts , and the rest. That is the whole install. It just sits in the tray and waits for you to trigger a Remote Desktop connection, an online meeting or a Get Online Help session. Right-click the tray icon and tick Start with Windows so RDPLauncher launches automatically at your next Windows sign-in. Untick it again to remove that. This is per-user; it does not touch other user accounts on the PC. Close the tray (right-click the icon » Exit ) and delete the folder. The only things left behind are your per-user settings under HKCU\Software\Aloaha , which you can delete with regedit if you want a spotless removal. #### Requirements - Windows with .NET Framework 4.8 (Windows 10 / 11 and Windows Server 2016+ include it or can install it). - 32-bit and 64-bit Windows. - Windows Remote Desktop client ( mstsc.exe , part of Windows) for the RDP side. - For meetings, Get Online Help and remote support: Microsoft Edge WebView2 Runtime — part of Windows 10 / 11. If it is missing, RDPLauncher offers Microsoft's download page and WebView2 also installs without administrator rights (into your user profile). - No administrator rights needed for any function. Licence: Free for private use. Commercial use requires a licence — please contact info@aloaha.com . ### Frequently asked questions. What is Aloaha RDPLauncher? Aloaha RDPLauncher (tray name: Aloaha RDP System Tray) is a small Windows tray application from Aloaha Limited that lists your .rdp Remote Desktop connections in the system tray, stores the logon encrypted with Windows DPAPI, and starts the Windows Remote Desktop client with one click. It also joins CodeB / Aloaha video meetings in a window of its own with screen sharing and consent-gated remote support, and includes Get Online Help — a 10-digit help code the user reads to a helper who takes control after the user's consent. How much does Aloaha RDPLauncher cost? Free for private use. Commercial use requires a licence — please contact info@aloaha.com . There is no licence-key dialog in the program; it just runs. How do I install Aloaha RDPLauncher? There is no installer. Download RDPLauncher.zip , extract the files anywhere you like (Documents, a shared folder, a USB stick — the location does not matter), and double-click RDPLauncher.exe . The Aloaha RDP System Tray icon appears in the notification area next to the Windows clock. Right-click it to see the menu. That is the whole install — no administrator rights, no DLLs, no service, no reboot. Optionally right-click the tray icon and tick Start with Windows so it launches automatically at your next sign-in. To remove it later, close the tray and delete the folder. See section 9 for the full walk-through. Do I need to install anything as an administrator? No. RDPLauncher itself does not need administrator rights at any step. On Windows 10 or 11 the Microsoft Edge WebView2 Runtime is usually already present; if it happens to be missing, RDPLauncher offers Microsoft's WebView2 download page and WebView2 also installs without administrator rights (into your user profile). Administrator rights are only needed if you (or an admin) want to write machine-wide (HKLM) settings such as GlobalRDPFolder or MasterRDPFolder . Is there an MSI installer for group-policy or SCCM / Intune deployment? RDPLauncher ships as a plain executable, not an MSI. For fleet deployment, copy RDPLauncher.exe to a shared folder and add a shortcut (or a scripted registry value) to the user's Autostart via group policy or your MDM. Machine-wide options live under HKLM\Software\Aloaha\SysTray and HKLM\Software\Aloaha\CSP ; per-user options live under HKCU\Software\Aloaha . There is no service to install and nothing to run as SYSTEM. Is Aloaha RDPLauncher an alternative to TeamViewer or AnyDesk? For the remote-support scenario, yes — Get Online Help works the same way: a short code, one click to share, a helper who takes control. Differences: control only ever starts with the user's permission (an explicit Allow click, or a code the user created and gave out themselves), the meeting server is configurable and can be self-hosted, and RDPLauncher has no licence-key dialog, no telemetry and needs no administrator rights. There is no 'unattended access' feature: someone must be at the PC to share the screen. How does Get Online Help work? Right-click the Aloaha RDP System Tray icon and pick Get Online Help . A window opens with a 10-digit code (e.g. 301 404 9694 ) and Copy code / Copy link buttons. The share picker opens already on Entire Screen; click Share. Read the number to your helper. They type it into Aloaha RDP System Tray » Online Meeting… (spaces and dashes are ignored) or open the Copy link in any browser. They take control after you clicked Share. Stop or Ctrl + Alt + F12 ends the session at any time. When you close the window the number stops working. Is the 10-digit help code safe to share? It works like a room address and a password in one. Whoever knows the number can see and control your screen until you close the Get Online Help window. So give it only to the person actually helping you, and never to someone who called you unexpectedly. You get a fresh number every time you open the window. Once your helper is in, click Lock room to keep everyone else out; the window always shows who is in the room so you notice a stranger. What is the difference between the 10-digit help code and the 6-character access code? The 10-digit code is the room number for Get Online Help — it identifies the meeting room the helper joins. The 6-character access code is an optional extra: if you turn it on in the Join Meeting dialog, a helper who requests control with that code skips the Allow dialog. You can use either on its own, or together; you can also embed the access code into the invite link (fragment-only, so it never reaches server logs) for one-link remote help, but then anyone who has that link takes control while the code is valid — send it only to your helper and prefer the once setting. Can someone control my PC without my permission? No. Control only starts after you click Allow — or with a short access code you created yourself and gave out. A bar on every screen always says who has control, and Stop or Ctrl + Alt + F12 ends the session instantly. Control also ends automatically when you stop sharing, lock Windows, leave the meeting, after 10 minutes without input, and after 30 minutes at most. Does the helper need Aloaha RDPLauncher too? No. The helper can join from a normal browser — they type the 10-digit code into the meeting page, or open the Copy link you send them. Only the person being helped needs Aloaha RDP System Tray, because that is what handles the consent dialog and OS-level input on the controlled PC. Why must I share my whole screen? So the helper can only click what they can see. If you share a single window or a browser tab, remote control stays disabled — that way sensitive content in other windows never becomes reachable by accident. In Get Online Help the share picker already opens on Entire Screen, and the window shows an orange warning when only a window is shared. Can the helper operate administrator windows? No. Windows does not allow a normal program to operate windows that run with administrator rights (for example UAC prompts) or the lock screen. If your task needs elevation, you dismiss the UAC yourself; the helper waits and then continues. How long can a remote-support session last? Until you stop it. It also ends automatically after 10 minutes without any remote input, and after 30 minutes at most. The helper can simply ask again if more time is needed. My screen is 4K and my helper has a small laptop. Does that work? Yes. The shared screen is scaled to fit the helper's window and their clicks land exactly where they point, at any display scaling on either side. Small text can be hard for the helper to read on a small screen; full-screen (F11) in the helper's browser helps. Does it work with display scaling (125 %, 150 %)? Yes. RDPLauncher is per-monitor DPI aware and its windows are sharp at every scaling factor. The scaling is picked up from Windows at sign-in; after changing scaling, sign out and back in so all windows re-open at the new size. Where are my RDP connections stored? In the RDP folder — by default Documents\RDPFiles for each user, or a folder set via the registry value RDPFolder . Administrators can add a machine-wide GlobalRDPFolder and a read-only MasterRDPFolder . The tray menu combines all three. Can a colleague read my RDP password from the .rdp file? No. Passwords are encrypted with Windows DPAPI for your Windows user on your PC. Nobody else, and no other PC, can decrypt them. The .rdp files remain standard mstsc-format files so Remote Desktop can still open them directly. Does Aloaha RDPLauncher need administrator rights? No. RDPLauncher needs no administrator rights for any function — the program never asks for elevation. Administrator rights are only needed if you want to write machine-wide (HKLM) settings such as GlobalRDPFolder or MasterRDPFolder . Does Aloaha RDPLauncher run on terminal servers or RDS? Yes. RDPLauncher runs one instance per user session and is safe to use on Windows Server 2016+, Remote Desktop Session Host and RDS environments. Administrators typically point every user to a read-only MasterRDPFolder for the standard set of connections, and let users add their own in the per-user RDPFolder . Does it work on Windows 10 and Windows 11? Yes. RDPLauncher runs on Windows 10, Windows 11 and Windows Server 2016 or later, 32-bit and 64-bit. It needs .NET Framework 4.8 (part of Windows 10 / 11) and, for meetings and Get Online Help, the Microsoft Edge WebView2 Runtime (also part of Windows 10 / 11; if missing, RDPLauncher offers Microsoft's download page and WebView2 installs without administrator rights). Is Aloaha RDPLauncher a portable application? Yes. The zip contains a single RDPLauncher.exe and a readme — unpack anywhere and run. There is no installer, no DLLs, no admin rights required and no service. Settings live in the registry under HKCU\Software\Aloaha\SysTray (per user) and, if an administrator wrote them, HKLM\Software\Aloaha\SysTray . Is Aloaha RDPLauncher an EU / GDPR-friendly remote support tool? The publisher (Aloaha Limited) is based in Malta (EU). The default meeting server phone.codeb.io runs on the CodeB Sovereign Communications stack. Organisations that need full data residency can self-host their own CodeB tenant on Windows Server + IIS and point RDPLauncher at it. RDPLauncher itself writes no logs and sends no telemetry. Can I put Aloaha RDPLauncher on a company-wide image? Yes. Copy RDPLauncher.exe to a shared folder and add a shortcut to the Start menu or Autostart of the image; the tray reads user-specific settings under HKCU and machine-wide settings under HKLM\Software\Aloaha\SysTray . Point every user at a read-only MasterRDPFolder that your admin scripts fill with the standard set of connections. Can I use Aloaha RDPLauncher without joining a meeting? Yes. The whole meetings / Get Online Help side is optional. Users who only want one-click RDP never need to open a meeting; the tray menu, DPAPI-stored logons and the RDP folders work on their own. Which network ports does Aloaha RDPLauncher need? For Remote Desktop, the standard RDP port to your servers (3389 by default; a custom port per connection is set in Edit RDP Hosts, e.g. host:3390 ). For meetings and Get Online Help, standard HTTPS (443) to the meeting server plus WebRTC media (UDP + TCP, TURN over 443 as a fallback) to that server's ICE endpoints. No incoming ports. Is there telemetry? No. RDPLauncher writes no log files and sends no telemetry. It connects to the meeting server ( phone.codeb.io by default, configurable) only while a Get Online Help or Online Meeting window is open. Remote Desktop connects to the servers you choose. After about 30 days of use it opens www.codeb.io or www.aloaha.com in the browser about once a week — nothing else. Can I roll back to an older version? Yes. Settings, registry values and .rdp files stay compatible with older RDPLauncher builds, and a backup zip of all configuration is created automatically on first start of a new version at %LOCALAPPDATA%\Aloaha_Limited\RDPLauncher.exe_StrongName_…\ . Just replace RDPLauncher.exe with the older build. How do I hide a tray menu item on a locked-down desktop or kiosk? Set the corresponding value in HKCU\Software\Aloaha\SysTray (per user) or HKLM\Software\Aloaha\SysTray (machine-wide) to "0" . "1" shows the entry, "0" hides it. See section 7 for the full list. You can also hide the tray icon itself ( trayvisible ) and the Exit entry ( exitvisible ) for kiosk use. Does Aloaha RDPLauncher support smart cards? Aloaha RDPLauncher itself is not a smart-card product. The .rdp files it writes contain the standard mstsc option to redirect smart cards into the Remote Desktop session ( redirectsmartcards:i:1 ), which is the same behaviour the built-in Remote Desktop client offers. If you need Aloaha's smart-card-based sign-in, that is a separate product line. Where do I get help using Aloaha RDPLauncher? The tray menu Help opens a built-in HTML manual. For anything beyond that, email info@aloaha.com or call the numbers in section 11. Support hours are CET, Monday to Friday. ### Talk to us. Email info@aloaha.com . Phone (Germany) +49 541 3859 4554 or +49 151 5761 0183 . CET business hours, Monday to Friday. English and German. =================================================================== # OID4VP 1.0 verifier — proof of work · CodeB Sovereign Communications · x509_hash + x509_san_dns live # Source: https://www.aloaha.com/eu-wallet-proof.html =================================================================== > Live OID4VP 1.0 + SD-JWT VC + DCQL verifier on CodeB Sovereign Communications. x509_hash (mandated by HAIP 1.0 Final, OID4VP 1.0 §5.9.3) is the wallet-preferred Client Identifier Prefix; x509_san_dns is supported as an additional OpenID4VP compatibility mode (not HAIP 1.0 Final). End-to-end mock-wallet receipt + crypto-stack documentation. EUDI-Wallet-ready, self-hosted, NIS2-aligned. ## EU Wallet Sign-In — Verified Proof of Work CodeB Sovereign Communications shipped an OID4VP 1.0 / EUDI Wallet verifier. On 2026‑06‑08 a spec‑compliant test wallet round‑tripped end‑to‑end against www.aloaha.com, returning verified PID claims and a signed SSO assertion. This page records the receipts — for buyers, auditors, regulators, and search engines that want more than a marketing slide. ### Built by Aloaha Limited. Not a fork of any SDK. Every protocol layer in the transcript below — SD-JWT VC parsing, JWS + KB-JWT signature verification, OpenID4VP request/response, DCQL query builder, direct_post.jwt JWE ECDH-ES, x5c chain validation, OpenID Federation 1.0 entity statements, the HAIP-mandated x509_hash Client Identifier Prefix plus the additional OpenID4VP-compatibility x509_san_dns prefix — is written in-house by the Aloaha Limited engineering team. No eudi-lib-* , no third-party EUDI SDK anywhere in the dependency tree. That translates into three practical guarantees: - The code belongs to us. Every line of the implementation can be inspected in your own security audit. No closed EUDI libraries that your CISO has to trust on faith. Generic infrastructure libraries (JWT/JWS, HTTP, .NET BCL crypto primitives) are widely-used open-source components; the EUDI-protocol code itself is 100% Aloaha-written. - Our own delivery calendar. We ship on our own release cadence — not gated on a consortium’s next SDK version, not tied to withdrawal cycles we didn’t choose. CVE patches and trust-policy changes land as soon as we’ve tested them, not on someone else’s schedule. - Strict standards-based interoperability. The wallet, the verifier and the issuer talk to each other exclusively through published RFCs (RFC 7519 JWT, RFC 7515 JWS, RFC 7516 JWE, RFC 8725 JWT BCP, RFC 9126 PAR) and EUDI protocols (OID4VP 1.0 FINAL, OID4VCI 1.0 Final, HAIP 1.0 FINAL, SIOP v2, OpenID Federation 1.0). Every piece is replaceable — no vendor lock-in, not even between our own components. 0 third-party EUDI SDK dependencies · 100% Aloaha-owned source · built and maintained in Malta by Aloaha Limited , a Malta-based European sovereign-tech vendor. ### Why a mock wallet? The EUDI Wallet ecosystem is mid‑rollout. National pilot apps exist, but spec‑compliant OID4VP 1.0 + SD‑JWT VC + DCQL support is still landing in real wallets. To prove the verifier works independently of any specific wallet vendor, an internal deterministic test client follows the OID4VP 1.0 happy path exactly as the spec requires — demonstrating that any conforming wallet will interoperate. Real‑wallet interop scales as the ecosystem matures. The substrate is locked in today. ### What ran end-to-end Eleven steps, every cryptographic gate passed, HTTP 200 returned with verified claims. The verifier's exact response to a successful presentation: Four selective disclosures ( given_name , family_name , birth_date , age_over_18 ) were verified against the SD‑JWT VC's _sd SHA‑256 hash array. The SSO assertion is a standard RS256 JWT with amr=["vc"] and acr="urn:codeb:acr:eudi-wallet" — every federated app in the tenant inherits verified identity through ordinary OIDC userinfo. One presentation, every reliant party benefits, no bespoke integration. ### Full transcript — sanitised mock‑wallet run Every protocol step recorded by the internal test client, with placeholder identity ( Alice Tester , 1990‑01‑01 ) substituted for the real test subject. Cryptographic blobs are shown truncated ( eyJ… ) because they encode the placeholder data. The session ID, nonce, state, ephemeral keys and certificate are illustrative; they rotate per session. Decode the sso_assertion JWT and you find amr=["vc"] and acr="urn:codeb:acr:eudi-wallet" : every reliant party that trusts CodeB's OIDC layer now knows this session was authenticated by an EU Wallet credential, not a password. That signal is the whole point. ### The crypto stack we shipped - Authorization Request — signed JAR (ES256), typ=oauth-authz-req+jwt , x5c chain pinned per HAIP 1.0 - Client Identifier Prefix — x509_hash (OID4VP 1.0 §5.9.3, base64url SHA‑256 of the DER leaf) is the wallet‑preferred form that real EUDI wallets bind to; x509_san_dns (HAIP 1.0 Final) is supported for compatibility. The caller picks per request via ?client_id_prefix= on the vp‑start endpoint; verifier‑metadata advertises both via client_id_schemes_supported . Tested back‑to‑back on every release with eu‑wallet‑mock‑both.py . Several identity‑focused verifiers in the wider ecosystem now support both prefixes; to our knowledge, CodeB is the only OID4VP 1.0 verifier with this combination integrated directly into a SIP / WebRTC business communications platform. - DCQL — native OID4VP 1.0 credential query syntax. No Presentation Exchange (PEX) legacy - Response encryption — JWE compact serialisation, alg=ECDH-ES + enc=A128GCM , NIST SP 800‑56A Concat KDF, RFC 7518 §4.6 / §5.1 conformant - SD-JWT VC — vc+sd-jwt format, _sd array of SHA‑256 disclosure hashes, structural integrity verified leaf‑by‑leaf - KB-JWT — holder key binding via cnf.jwk ; nonce, aud and sd_hash all verified against the verifier challenge - Result envelope — response= form parameter per OID4VP §8.4; decrypted plaintext is a JSON envelope with the DCQL‑shaped vp_token object - Session persistence — vp‑sessions atomically written under App_Data//vp‑sessions/ , so IIS app‑pool recycles or multi‑worker routing never lose a mid‑flight presentation ### What is still ahead (iteration 2) The current iter‑1 substrate verifies structural integrity and holder binding. Future work, transparently flagged: - JWS issuer signature verification against per‑issuer JWKS / x5c trust chain - LoTL (List of Trusted Lists) trust‑chain validation — PKI → member‑state Trusted List → EU LoTL - Status list / revocation checking for issued credentials (IETF OAuth Status List) - Multi‑credential DCQL queries — today the first credential in the response is consumed - Phase B Issuer (OID4VCI) so CodeB tenants can issue their own member‑organisation credentials Until iter‑2 ships, the verifier accepts well‑formed SD‑JWT VCs for use cases where the tenant trusts the issuer at presentation time — pilot deployments, identity‑proofing demos, member‑organisation logins. Production high‑assurance identity proofing should wait for iter‑2 + a notified national wallet. ### Why this matters eIDAS 2.0 applies to the entire European Economic Area — 30 countries. The 27 EU Member States must issue at least one certified national Digital Identity Wallet by December 2026 and public‑service relying parties must accept it; Norway, Iceland and Liechtenstein follow the same framework with roughly one additional year of lag (Liechtenstein already has an eID app covering identity, driving licence and QES that will be adapted into an EUDI Wallet; Norway is running a sandbox with public + private partners and has contributed to the EU Large‑Scale Pilots). The OID4VP 1.0 / SD‑JWT VC / DCQL specs are the wire format. A working verifier is the precondition for accepting wallet sign‑in — without it, "EU Wallet ready" is just a marketing claim. CodeB tenants get the verifier today. Self‑hosted, EU‑sovereign, NIS2 / DORA aligned, with the verified‑claim relay wired through the OIDC layer the rest of the platform already uses. Free EU Wallet training. Free EU Wallet training (dial 1844) — a dedicated AI trainer that walks you through OID4VP, SD‑JWT VC, eIDAS 2.0 and the December 2027 mandate. Free, no signup, ends when you do. Hear the AI receptionist. Talk to vnum 1234 in your browser — the live CodeB Sovereign Communications virtual assistant. Ask it about EU Wallet, features, the build chain, anything. Try the wallet flow. logineu.html — the live EU Wallet sign‑in flow. Read the feature card. features.html#eu-wallet Public verifier API. Integrators — the full endpoint reference is at eu-wallet-api.html (DE: de/eu-wallet-api.html ). Deutsche Fassung. de/eu-wallet-proof.html Engineered by Aloaha Limited — 🇲🇹 proudly made in Malta, shipped from the smallest EU member state to the whole single market. www.codeb.io ### Frequently asked questions Is CodeB's OID4VP verifier production-ready? The protocol substrate is live as of 2026-06-08. Issuer-signature chain against the EU's List of Trusted Lists is iter-2. Today's verifier is suitable for pilot deployments and identity-proofing demos; production high-assurance identity proofing should wait for iter-2 plus a notified national wallet. Which OID4VP profile does CodeB implement? OID4VP 1.0 with both Client Identifier Prefix schemes supported. x509_hash (mandated by HAIP 1.0 Final, OID4VP 1.0 §5.9.3) is the wallet-preferred form; x509_san_dns is supported as an additional OpenID4VP compatibility mode (not HAIP 1.0 Final). ES256-signed JAR with x5c chain, DCQL credential queries, JWE-encrypted responses with ECDH-ES + A128GCM, SD-JWT VC with KB-JWT holder binding. Why DCQL instead of Presentation Exchange? DCQL is the OID4VP 1.0 Final mandatory query language. The EUDI reference wallets implement DCQL. Presentation Exchange is JSON-LD-heavy and adds no value for the EU Wallet use case, so CodeB shipped DCQL only. Is CodeB EUDI-certified? No. EUDI certification is reserved for notified national wallet schemes and qualified trust service providers under eIDAS 2.0. CodeB is a verifier (relying party), not a wallet issuer, and is careful not to claim certification it does not hold. From when does my business need to accept the EU Wallet? From December 2027, private-sector relying parties that are required by Union law, national law or contractual obligation to use strong user authentication for online identification — excluding micro and small enterprises — plus qualifying very large online platforms, must accept the EU Digital Identity Wallet when the user voluntarily chooses it (eIDAS 2.0 Article 5f). Named sectors include banking, financial services, transport, energy, social security, health, postal services, digital infrastructure, education and telecommunications. =================================================================== # SIPS — SIP-over-TLS (RFC 5630) on the CodeB Sovereign SBC # Source: https://www.aloaha.com/sips.html =================================================================== > RFC 5630 SIPS on the CodeB bridge. Per-tenant cert via SNI on TCP 5061/6061, ACL gate shared with TURN, per-IP auto-blacklist tuned for CGNAT, /sip-tls/health observability, per-trunk opt-in. RFC 4028 Session-Timer adds mid-call UPDATE refresh for dialog liveness. EU-built. ## SIPS — encrypted SIP signalling, RFC 5630 compliant. The CodeB sovereign SBC terminates SIP-over-TLS on dedicated ports for both trunk-side and public-listener traffic. Each TLS handshake selects the per-tenant certificate by SNI from the operator’s existing Windows certificate store — one Let’s Encrypt cert per tenant, no SAN list to maintain. ACL, auto-blacklist and observability are shared with the rest of the bridge. SBC overview SIP-over-WebSocket Compare /sip-tls/health endpoint ### Two TLS ports, mirroring the UDP topology Adopting SIPS on a CodeB tenant does not rearchitect routing. The two TLS listeners sit beside the existing UDP listeners so the operator’s call flows, ACL rules and trunk plumbing continue to work as configured. Per-trunk opt-in means SIPS rolls out one trunk at a time. #### Per-tenant cert via SNI Each TLS handshake selects the per-tenant certificate from LocalMachine\My by SNI server name. Same cert store the WSS listener and TURN-TLS already use; same per-tenant LE cert auto-deployed via /acquire-cert (or wacs.exe directly). Adding tenant N+1 means installing one more cert in the store — no SAN-list reissue, no operator-visible SIPS reconfiguration. #### Per-trunk opt-in In trunks-admin.html , every trunk has a TLS (SIPS) checkbox and an optional TLS port (default 5061). When checked, the bridge registers + dials via sips:user@host:5061;transport=tls per RFC 5630. Most modern carriers expose a TLS port on 5061; legacy FRITZ!Box or ATA boxes typically don’t — leave the checkbox off for those. #### ACL gate (shared with UDP) The same acl.html rules that block SIP over UDP block SIPS too. SIPS traffic enters the same InboundDispatcher dispatch point, so per-IP, CIDR, glob, sip-user, sip-from, sip-did and tenant rules all apply with no per-protocol carve-out. Hot-reload from disk, anti-self-lockout for private IPs, per-tenant rule pools — operator manages everything in one place. #### Per-IP TLS auto-blacklist Per-source-IP sliding-window detector: more than 15 failed TLS handshakes from one IP in a 5-minute window blocks that IP at the SIPS accept layer for 1 hour . Catches noisy SIP-scanner traffic at the cheapest possible response point. Threshold deliberately higher than the TURN default (5) to forgive CGNAT-shared mobile carrier source IPs. Private / loopback / link-local / IPv4-mapped-IPv6 private addresses are never blocked. #### Slow-loris defence A 15-second handshake timeout shuts down peers that dribble bytes after the TLS record header. A per-channel SemaphoreSlim(200) caps in-flight handshakes per port so a /16 scanner can’t starve the threadpool. Over-cap accepts get a fast TCP RST + a throttled WRN log; legit clients can retry instantly. #### Observability without REST exposure One greppable log line per inbound SIPS request: [sips-arrival] with CallID, method, from, to, remote, local. One [sips-downgrade] WRN per call when a SIPS leg bridges to a plain SIP leg — never silent, never blocked. Periodic [SIPS-stats] line every 30 s with handshake counters, fail counts and active blocklist size. Operator-facing /sip-tls/health endpoint returns the same data as JSON. ### SRTP via SDES — media-plane encryption on the trunk leg SIPS protects the SIP control plane. SDES (Session Description Protocol Security Descriptions, RFC 4568 ) keys SRTP for the media plane on the same trunk leg. Together they make the leg between bridge and carrier encrypted end-to-end on both planes: SIPS for signalling, SDES for media . #### Per-trunk SRTP toggle In trunks-admin.html , every trunk has an SRTP checkbox alongside the existing TLS (SIPS) checkbox. When checked, the bridge offers SDES on outbound INVITEs and answers SDES on inbound INVITEs from this trunk. Default OFF per trunk so existing routing is unchanged until an operator opts in. #### Crypto suite: AES_CM_128_HMAC_SHA1_80 Outbound INVITEs offer m=audio … RTP/SAVP with a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline: — the mandatory baseline crypto suite from RFC 4568. The 32-byte key (128-bit master key + 112-bit master salt) is freshly generated per call. #### Asymmetric inbound answer An inbound INVITE that includes a=crypto: is answered with SDES regardless of the trunk’s outbound toggle — safe-by-default. Peers that prefer SRTP get SRTP back; peers that don’t offer crypto keep working as before. #### Fail closed, never silently plaintext When the per-trunk SRTP toggle is on and the peer rejects the SDES offer (or returns no usable crypto line), the call ends. There is no fallback to plaintext RTP that an operator hasn’t explicitly approved. Every rejection is logged at INF level with the call correlation ID. #### Bridge-terminated for AI & recording The bridge terminates the SDES session and re-emits the right thing on the far leg. AI receptionist (Gemini media path), signed call recording, transcription and lawful-intercept hooks continue to operate because the bridge sees decoded audio internally. The carrier never sees plaintext on the wire. #### Complementary to DTLS-SRTP on WebRTC Browser legs already negotiate DTLS-SRTP automatically. SDES on the trunk leg fills the symmetric gap on the carrier side. Pair both with the per-trunk TLS (SIPS) toggle and the trunk leg is encrypted on signalling and media planes simultaneously. #### Session-Timer for mid-call liveness (RFC 4028) SIPS keeps the TCP socket alive; Session-Timer ( RFC 4028 ) keeps the SIP dialog itself accountable. With the per-trunk Session-Timer toggle on, outbound INVITEs advertise Session-Expires + Min-SE + Supported: timer ; if the carrier acknowledges, the bridge sends mid-call UPDATE refreshes at half the negotiated interval and tears the dialog down via BYE if a refresh round-trip is missed past the grace window. Carriers without RFC 4028 support simply ignore the offer and fall back to the RTP-watchdog already in place — no day-one regression. Default OFF per trunk; inbound calls honour the peer's request regardless. EU CRA and NIS2 alignment: media-plane encryption between a regulated organisation and its telecoms boundary is increasingly a baseline expectation, not a nice-to-have. SDES on the trunk leg, paired with SIPS on the signalling plane, ticks both boxes with operator-controllable per-trunk granularity — no all-or-nothing rollout. ### The risk of unencrypted SIP A SIP packet on a UDP or TCP-without-TLS leg crosses every intermediate router, ISP, IXP and transit AS in clear text. Three concrete categories of harm follow directly from that. #### Header metadata is personal data The From , To , Contact , P-Asserted-Identity and Via headers carry calling and called numbers, extensions and host identities. Under EU data-protection law, a phone number that identifies a natural person is personal data (GDPR Art. 4(1)). A passive capture of plain SIP is a personal-data interception — reportable under GDPR Art. 33 if it occurs. #### Authentication digests fund toll fraud A plain REGISTER or INVITE carries the digest Authorization header. The HA1 hash is salted with the realm + nonce, but the username and realm are visible and any nonce can be reused until the registrar rotates it. Captured digests are routinely brute-forced offline or replayed during the nonce window — the resulting hijacked SIP line is then auto-dialled to premium-rate destinations, accumulating four- to five-figure bills inside a single weekend. ENISA and the CFCA list toll fraud as one of the top three telecoms-fraud categories every year. #### Audio is recordable without SRTP Plain RTP packets carry G.711 / Opus payloads with no integrity tag and no encryption. A position on the call path — a misconfigured switch, a compromised CPE, a hostile transit network — is enough to record every conversation verbatim and reconstruct the audio with off-the-shelf tools. SRTP via SDES on the trunk leg and DTLS-SRTP on the browser leg removes that exposure. CodeB defaults to a posture where TLS on the signalling plane and SRTP on the media plane are both available on every trunk and every endpoint. The TLS (SIPS) and SRTP toggles in trunks-admin.html are per-trunk so a tenant can enable them carrier-by-carrier as confidence builds, without a flag-day rollout. ### Encrypted SIP and the law No regulation today says “use SIPS” in those words. Several do require encryption of personal data in transit, confidentiality of electronic communications, and cryptography as a baseline security measure — and TLS on SIP signalling plus SRTP on RTP media is how a SIP / telecoms operator demonstrates compliance with those clauses. #### GDPR Art. 32 (EU 2016/679) Controllers and processors implement “appropriate technical and organisational measures” including “the pseudonymisation and encryption of personal data” . SIP headers identify natural persons; SIP audio carries identifying biometric voice data. TLS + SRTP is the recognised state-of-the-art encryption-in-transit answer. #### ePrivacy Directive Art. 5 (2002/58/EC) Member States must ensure the confidentiality of communications and prohibit interception or surveillance of communications and the related traffic data without consent. Plaintext SIP fails the technical part of that duty: anyone on the wire can intercept it. #### NIS2 Directive Art. 21(2)(h) (EU 2022/2555) Essential and important entities — including digital infrastructure and a wide band of B2B providers — must adopt cybersecurity risk-management measures including “policies and procedures regarding the use of cryptography and, where appropriate, encryption.” In force since 18 October 2024 across EU Member States. #### EU Cyber Resilience Act (EU 2024/2847) Annex I obliges products with digital elements to “protect the confidentiality of stored, transmitted or otherwise processed data … by encrypting relevant data at rest or in transit by state of the art mechanisms.” SBCs and voice platforms fall squarely in scope. #### EECC Art. 40 (EU 2018/1972) Electronic-communications providers must take appropriate and proportionate technical and organisational measures to manage risks to the security of networks and services. National regulators read transport encryption of signalling as a baseline of “state of the art.” #### Germany — TKG § 165 + BSI TR-02102 German Telecommunications Act § 165 requires “appropriate technical precautions” for confidentiality of communications. The BSI’s TR-02102-2 cryptographic-procedures guideline recommends TLS 1.2 or TLS 1.3 with forward-secrecy cipher suites for transport security. Both are satisfied by SIPS on TLS 1.2/1.3 with the modern cipher suites IIS / SCHANNEL negotiate by default. Sector-specific overlays then add their own requirements: HIPAA § 164.312(e) (US healthcare voice), PCI-DSS v4 if call recordings touch cardholder data, ETSI TS 133.203 for IMS interconnect. The common denominator on the SIP plane is the same: TLS on signalling, SRTP on media. ### Why TLS on the signalling plane SIPS protects the metadata layer of every call: who called whom, what extension was dialled, what the auth realm is, what carrier identity headers (P-Asserted-Identity, P-Preferred-Identity) say about the caller. On a UDP or TCP-without-TLS leg, all of that crosses the network in plain text — visible to any intermediate ISP, IXP or transit AS that captures the packet. - NIS2 / DORA / CRA alignment. EU compliance frameworks increasingly call for transport-encrypted control-plane traffic between regulated entities and their telecoms providers. SIPS on the signalling plane is the simplest box to tick. - Defence against passive metadata harvest. Caller-ID, called-DID and call-frequency metadata leak business intelligence. TLS encrypts the SIP headers so a passive observer sees only TLS application records. - Anti-spoofing at the registration layer. A REGISTER over plain UDP is trivially observable + replayable from a man-on-the-side attacker. Over TLS, the registration password digest is protected by the TLS session key. - Carrier-side identity assurance. Carriers that issue P-Asserted-Identity expect SIPS signalling on the trust boundary; with SIPS, the bridge can present + accept PAI without it ever crossing in plaintext. - In-house TLS + SIP stack — minimal supply chain. The SIPS handshake, SIP parser, SDES key derivation and SDP rewrite are all Aloaha-written .NET code. Third-party server dependencies are a hand-picked short list (SIPSorcery, Newtonsoft.Json, jose-jwt) — not a transitive graph pulled from a package registry. When a future log4j-shaped supply-chain incident hits a mainstream telecoms SDK, it will not reach the signalling plane between your bridge and your carrier. ### How an operator turns on SIPS for a trunk - Install the tenant LE cert. If the tenant’s certificate isn’t already in LocalMachine\My , run wacs.exe or use the superuser Get LE cert button on superadmin.html . The SipsCertResolver picks it up by SNI on the next handshake. - Open the trunk in trunks-admin.html . Tick the TLS (SIPS) checkbox. Adjust TLS port only if the carrier exposes TLS on a non-standard port; default 5061 covers ~95% of carriers. - Save the trunk. The bridge hot-reloads the trunks file; the TrunkRegistrar recreates the SIPRegistrationUserAgent with sips:user@host:5061;transport=tls within a few seconds. - Verify in the bridge log. Grep for REGISTER