Quick Gate

QuickGate's Platform Architecture & Compliance Repository

This document outlines the engineering, security, and compliance architecture of the QuickGate platform. It is designed to demonstrate how QuickGate functions not merely as a software gateway, but as a fully compliant Intermediary Relying Party under the eIDAS 2.0 framework.

1. Regulatory Compliance & Trust Framework: Explains the legal-technical mapping of certificates (RPAC/RPRC) and how QuickGate absorbs

regulatory complexity on behalf of its clients.

2. Technical Specification: Details our "Zero-Persistence" infrastructure, "Browser-First" security model, and "Triangular Encryption" strategy.

3. Functional Requirements: Outlines the core API capabilities, SDKs, and session management logic.

4. Non-Functional Requirements: Defines our requirements regarding latency, encryption, and data minimization.

Part 1: Regulatory Compliance & Trust Framework

Part 2: Technical Specifications

The "How" Core Engineering & Security Architecture.

1. System Overview & Architectural Principles

QuickGate operates as a EUDI Wallet Intermediary, functioning as a secure, stateless gateway between Client Relying Parties (RPs) and User Wallet Units.

1.1. Core Design Decisions

Intermediary Model: QuickGate acts as the technical endpoint. We sign requests using our own RPAC (Relying Party Access Certificate) and the Client's RPRC (Relying Party Registration Certificate), abstracting the PKI complexity from the client.

Browser-First Strategy (Unified Flow): To maximize security and compatibility (specifically addressing iOS restrictions on the Digital Credentials API in native apps), all Same-Device flows (Web and Native App) are routed through the QuickGate Secure Web Gateway.

Zero-Persistence (Memory-Only): In strict adherence to NFPRI 001, the system acts as a pipe. User attributes are processed in volatile memory RAM, cryptographically verified, forwarded to the client, and immediately wiped.

2. Supported Protocols & Interfaces

2.1. Presentation Interfaces (Wallet Communication)

Table 2.1 Protocol Specifications for Wallet Interaction

Protocol	Implementation Context
W3C Digital Credentials API (DC API)	Primary. Used for all "Same-Device" flows. Whether the user starts in a Client App or Client Website, the interaction is mediated by the System Browser (Safari/Chrome) calling the DC API.
OpenID4VP (OpenID for Verifiable Presentations)	Underlying Engine. The payload format and request/response structure used within the DC API and for Cross-Device QR flows.
ISO/IEC 180135	Proximity. Supported for physical kiosk/in-person verification via NFC or QR.

2.2. Client Interfaces (Relying Party Backend To QuickGate Communication)

REST API: Protected by high-entropy API Keys (NF-SEC-002.1) and TLS 1.3.

Webhooks: Signed payloads sent to Client servers upon successful verification.

3. Authentication & Trust Architecture

3.1. Certificate Management (Legal & Tech Integration)

To comply with Article 5b(10) and the ARF, QuickGate manages the trust chain:

• RPAC (Access Certificate): Identifies QuickGate as the certified Intermediary.

• RPRC (Registration Certificate): Identifies the specific Client (End-RP) and authorizes QuickGate to act on their behalf.

• Request Signing: Every OpenID4VP request generated by the Gateway is signed using the QuickGate private key associated with the RPAC, incorporating the Client's RPRC details in the metadata.

3.1.1. Trust Chain Registration

To comply with EUDI Wallet trust framework, QuickGate must:

• Formally register as a Relying Party (Intermediary) with a Registrar in our home Member State

• Obtain RPAC (Relying Party Access Certificate) from an Access Certificate Authority (ACA)

• Maintain integration with EU Trusted Lists (LOTL) for QTSP validation

3.2. Verification Logic (NF-PER-002)

• Latency constraint: Cryptographic verification must complete in < 1 seconds.

• Validation: Signatures of incoming Verifiable Presentations (VPs) are checked against the EU Trusted Lists (LOTL) to ensure the Wallet Provider is an authorized Qualified Trust Service Provider (QTSP).

3.3. OpenID4VP Request Object Specification

Example demonstrating structure of the signed JWT payload:

4. Data Flows & Security

4.1. Same Device Flow

This section described flows in which end-user interacts via with clients app (either native or web) on same device with the EUDI Wallet installed.

4.1.1. Scenario A: Native App Integration (Server-Init + PKCE + DC API)

Use Case: End-user interacting via a Client Native Application (iOS/Android) with the Wallet Unit installed on the same device.

Flow Overview: The QuickGate architecture enforces a "Secure Web Gateway" pattern. Rather than the Client Application directly invoking the User Wallet, the user is redirected to a transient, secure session hosted on the QuickGate Web Frontend.

This approach is chosen to leverage the W3C Digital Credentials API (DC API) as the primary invocation mechanism. As detailed in the EU Digital Credentials API Discussion Paper (Topic F, v1.3):

• Section 2.1 (Proposed Solution) recommends the DC API to address "Session Binding" and "Clear Origin Verification," ensuring the wallet interacts with a verified web origin.

• Section 3.1 (Expected Functionality) emphasizes the browser's role in mediating secure wallet selection and transport.

Primary Driver: Identity Consistency & Operational Scalability

The decision to route flows through a Web Gateway is primarily driven by the Origin Association requirements of the Digital Credentials API.

• The Constraint: For a Native App (e.g., com.client.bank ) to invoke the API on behalf of an Intermediary ( https://QuickGate.com ), the Operating System requires proof of association (e.g., Android Digital Asset Links or iOS Associated Domains).

• The Problem: Direct native invocation would require QuickGate to host the app signatures of every client on its domain (hosted at https://QuickGate.com/.well known/assetlinks.json ). In the absence of these certificates, the Wallet will either display a warning regarding the mismatch or block the request entirely as a potential spoofing attempt. To support this natively, we would need to manage a massive JSON file and update our server configuration every time a client releases a new app version or rotates their keys. This creates an operational bottleneck that is impossible to scale.

• The Solution: By routing the flow through verify.QuickGate.com , the "Caller" is the QuickGate System Browser. The Caller Origin perfectly matches the Relying Party Identity ( QuickGate.com ), satisfying security checks without requiring any client specific infrastructure configuration.

Secondary Driver: Platform Unification

Secondarily, this strategy resolves platform fragmentation. While Android supports direct usage of the Digital Credentials API within native apps, iOS currently restricts this API surface to the browser context. By routing all native app flows through the QuickGate Web Gateway, we normalize this disparity, providing a single, consistent implementation path for Clients across both mobile ecosystems.

The Initialization Lifecycle:

1. Indirect Initiation: The Client App never communicates directly with QuickGate APIs.

2. Server-to-Server Trust: The Client App requests a verification from its own Client Backend. The Client Backend then authenticates with QuickGate Core (via Secret API Key) to initialize the session.

3. Session Generation: QuickGate Core returns a unique, time-bound web_session_url containing a secure session token.

4. Handoff: The Client Backend passes this URL to the Client App, which launches it in the System Browser to begin the secure wallet interaction.

Architectural Rationale: This flow enforces a layered security model designed to neutralize both remote relay attacks and local privilege escalation:

1. Authorization (Stripe-Model): Only the Client Backend (holding a valid API Key) can initiate a verification session. This ensures QuickGate processes requests exclusively from authorized partners.

2. Anti-Relay Mechanism (Delivery Path): We mitigate Remote Relay Attacks by coupling result delivery to the user's device context. The Authorization Code is delivered strictly via a system browser redirect to the Client App on the victim's device. Consequently, a remote attacker who initiated the flow never receives the code required to fetch the identity data.

3. Session Binding (PKCE): We implement Proof Key for Code Exchange (RFC 7636) to secure the Deep Link handoff on the local device. Since custom URL schemes ( app scheme:// ) are vulnerable to interception by malicious apps installed on the same device, the Authorization Code (delivered in step 2) is theoretically exposed. PKCE mitigates this by requiring the code_verifier (generated securely at session start) to redeem that code. A malicious app intercepting the code cannot exchange it for data because it lacks the code_verifier stored in the legitimate app's memory.

4. Protocol Compliance: The QuickGate Core generates the specific OID4VP request_uri (Signed JWT) required by the Digital Credentials API, abstracting the cryptographic complexity and signing requirements from the Client.

5. Identity Consistency & Scalability: As detailed in the "Primary Driver" section above, we verify user identity via the QuickGate Web Gateway (System Browser) to solve the OS-level Origin Association problem (Digital Asset Links), ensuring the Caller Origin matches the Request Signer.

The Detailed Flow:

Step 1: Client App Setup (PKCE Generation)

• Actor: Client Frontend (Native App).

• Action:

• Generates a cryptographically random secret: code_verifier (e.g., secret_abc )

• Hashes it: code_challenge = SHA256(code_verifier) .

• Sends the code_challenge to the Client Backend to start the process.

Step 2: Session Initialization (Server-to-Server)

• Actor: Client Backend → QuickGate Core.

• Action:

• Authenticates using the Secret API Key.

• Calls POST /api/v1/sessions with the code_challenge and requested attributes.

• QuickGate Core:

• Validates API Key.

• Generates a Wallet Nonce.

• Creates the Signed OID4VP Request Object (JWT) containing the nonce and return paths. Stores this as the request_uri .

• Internal Storage: Creates a Session (Internal ID: 555 ) storing the code_challenge , request_uri , and API Key owner.

• Public Handoff: Generates a secure, random Session Token (e.g., sess_xyz123 ) mapping to Internal ID 555 .

• Returns the web_session_url containing this token: https://verify.QuickGate.com/start?token=sess_xyz123 .

Step 3: Triggering the Flow

• Actor: Client Backend → Client App → System Browser.

• Action:

• Client Backend returns the web_session_url to the App.

• Client App opens the System Browser (Safari/Chrome) to that URL.

Step 4: QuickGate Web & DC API Interaction

• Actor: QuickGate Web Frontend (Browser) & User.

• Action:

• The QuickGate Page loads and parses the token from the URL.

• Context Fetch: The Frontend JavaScript calls GET /api/session-context using the token.

• QuickGate Core: Validates the token, retrieves the associated request_uri (the Signed JWT), and returns it to the browser.

• Invocation: The JavaScript calls the API:

• Browser/OS: Resolves the URI, validates the signature, opens Wallet, and gets User Consent.

• Browser: Returns the Verifiable Presentation VP object to QuickGate Frontend memory.

Step 5: Verification & Code Issuance

• Actor: QuickGate Frontend → QuickGate Core.

• Action:

• QuickGate Frontend sends an AJAX POST with the vp_token to the Core.

• QuickGate Core:

• Verifies the VP signature against the EU Trusted Lists (LOTL).

• Verifies the nonce inside the VP matches the one in the request_uri.

• Success: Generates an Authorization Code ( auth_code_999 ) linked to the original code_challenge.

• Returns the code to the Frontend.

Step 6: The Return

• Actor: QuickGate Frontend → Client App.

• Action:

• QuickGate Frontend redirects the browser to the client's callback: bank-app://callback?code=auth_code_999.

Step 7: Secure Exchange

• Actor: Client App → Client Backend → QuickGate Core.

• Action:

• Client App sends auth_code_999 AND the secret code_verifier to Client Backend.

• Client Backend calls POST /api/v1/token (using API Key).

• QuickGate Core:

• Validates API Key.

• Checks: SHA256(code_verifier) == code_challenge (stored in Step 2).

• Result: Returns the verified User Attributes.

Figure 4.1.1: Native App - Same Device Authentication Sequence

4.1.2. Scenario B: Web Client Integration (Secure Pop-up Flow)

Use Case: End-user interacting via a Client Web Application (Browser). The Wallet Unit is installed on the same device.

Architectural Rationale: Unlike Native Apps, Web Clients already operate within a browser environment, theoretically allowing them to invoke the Digital Credentials API directly. However, we strictly route the flow through the QuickGate Web Gateway to enforce Origin Consistency (as detailed in Section 4.1). Since the OpenID4VP Request is cryptographically signed by QuickGate's certificate (RPAC), invoking it from a different Client domain would cause a mismatch between the Calling Origin and the Request Signer, triggering security warnings or blocking by the User's Wallet.

• The Constraint: The OpenID4VP Request is signed by QuickGate's RP Access Certificate.

• The Security Requirement: To prevent "Origin Mismatch" errors or Phishing warnings in the User's Wallet, the browser's Top-Level Origin (calling the API) must match the Certificate Signer ( QuickGate.com ).

• The UX Solution: We use a Pop-up Architecture (via the QuickGate Web SDK) to load the Secure Gateway in a modal window, maintaining the user's context on the Client Website while satisfying the Origin security requirement.

The Detailed Flow:

Step 1: Session Initialization (Stripe-like)

• Actor: Client Backend → QuickGate Core.

• Action: Authenticates via API Key and calls POST /sessions.

• Return: QuickGate returns the web_session_url (e.g., https://verify.QuickGate.com/start?token=sess_123 ).

• Handoff: Client Backend passes this URL to the Client Frontend (JS).

Step 2: The Pop-up Trigger (QuickGate Web SDK)

• Actor: Client Frontend (User).

• Action: User clicks "Verify Identity".

• SDK Action:

• Instead of a full page redirect, the SDK opens a Pop-up Window pointing to web_session_url.

• Note Pop-ups are required (rather than iFrames) because the Digital Credentials API typically requires a top-level browsing context or specific Permissions Policy delegation, and Wallet System Dialogs function best from top-level windows.

Step 3: DC API Execution (Inside the Pop-up)

• Actor: QuickGate Frontend (Pop-up Window).

• Context: The browser is now strictly on https://verify.QuickGate.com.

• Action:

• The Frontend JS retrieves the request_uri.

• Calls navigator.credentials.get().

• Security Check: The Browser Origin ( QuickGate.com ) matches the Request Signer ( QuickGate.com ). The Wallet trusts the interaction.

• Wallet Interaction: User completes the flow; VP is returned to the Pop-up's memory.

Step 4: Verification & Closure

• Actor: QuickGate Frontend → QuickGate Core.

• Action: POSTs the VP for verification.

• Success: QuickGate Core verifies the proof and returns an Authorization Code.

Step 5: Cross-Window Communication (PostMessage)

• Actor: QuickGate Frontend (Pop-up) → Client Frontend (Parent Window).

• Action:

• The Pop-up does not redirect.

• Instead, it uses the window.opener.postMessage API to send the Authorization Code securely to the Parent Window.

• The Pop-up closes itself automatically.

Step 6: Token Exchange

• Actor: Client Frontend → Client Backend → QuickGate Core.

• Action: The Client Frontend passes the code to its Backend, which exchanges it for the User Attributes (same as Scenario A).

Figure 4.1.2: Web Client Same Device Authentication Sequence

4.2. Cross-Device Flow

This section details flows where the End-User initiates the verification on one device (e.g., a Desktop, Laptop, or Tablet) while the EUDI Wallet is hosted on a separate device (e.g., a Smartphone).

4.2.1. Scenario A: Native App Integration (Tablet/Desktop App)

Use Case: End-user interacting via a Client Native Application (e.g., on an iPad or Android Tablet) with the Wallet Unit installed on a smartphone.

Flow Overview: The initialization and handoff process mirrors Scenario 4.1.1. The Client Backend initializes the session and the Client App opens the QuickGate Web Gateway in the System Browser.

Architectural Rationale:

• The Challenge: A standard OpenID4VP implementation using response_mode=direct_post enables the Wallet to send credentials directly to the Backend over the internet. While broadly supported, this approach is vulnerable to Remote Relay Attacks. A remote attacker could display a "Direct Post" QR code to a victim, and if the victim scans it, the Wallet would push the credentials to the Backend, bypassing the attacker's lack of physical presence.

• The Solution (DC API & CTAP): We explicitly reject the direct_post method for cross device flows. Instead, we invoke the Digital Credentials API, which utilizes the CTAP (Client to Authenticator Protocol) Hybrid Flow.

• Proximity Security: This protocol routes the credentials from the Wallet (Phone) to the Browser (Tablet) via a secure local tunnel, enforced by a Bluetooth (BLE) Proximity Check. If the devices are not physically close, the connection fails. This renders Remote Relay Attacks impossible.

The Detailed Flow:

Steps 1-3: Initialization

• Identical to Section 4.1.1. The Client App generates a PKCE challenge, the Backend creates a session, and the App launches the web_session_url in the Tablet's System Browser.

Step 4: Secure Tunnel Establishment

• Actor: QuickGate Frontend (Tablet Browser).

• Action: Calls navigator.credentials.get().

• Browser UI: The Browser displays a system-generated QR code.

• User Action: User scans the QR code with their Smartphone Wallet.

• Security Check: The devices perform a Bluetooth Handshake to verify physical proximity.

• Tunneling: A secure, end-to-end encrypted tunnel (CTAP Hybrid) is established between the Wallet (Phone) and the Browser (Tablet).

Step 5: Data Transfer & Return

• Action: The Wallet sends the Verifiable Presentation (VP) through the secure tunnel to the Tablet Browser's memory.

• Note: The VP is not posted directly to the QuickGate Backend from the phone. It returns to the calling context (the Browser) to resolve the JavaScript Promise.

Step 6-7: Verification & Handoff

• Action: The QuickGate Frontend (Tablet) POSTs the VP to the QuickGate Core, receives the Authorization Code, and redirects back to the Native App (client-app://callback) exactly as described in Section 4.1.1.

4.2.2. Scenario B: Web Client Integration (Desktop Browser)

Use Case: End-user interacting via a Client Web Application (e.g., Banking Website on a Desktop) with the Wallet Unit installed on a smartphone.

Flow Overview: The initialization process mirrors Scenario 4.1.2. The Client Website opens the QuickGate Pop-up Window to maintain Origin Consistency.

Architectural Rationale:

• The Challenge: As with the Native App scenario, utilizing a standard response_mode=direct_post QR code allows the Wallet to transmit data over the internet from anywhere. This creates a vulnerability to Remote Relay Attacks, where a remote attacker presents a QR code to a victim, and the victim's scan successfully authorizes the attacker's session.

• The Solution (DC API & CTAP): We mitigate this by strictly avoiding "Direct Post" flows. By invoking the Digital Credentials API within the QuickGate Pop-up, we trigger the CTAP Hybrid Flow.

• Proximity Security: This forces a Bluetooth (BLE) Proximity Check. The Wallet verifies that it is physically next to the Desktop computer requesting the identity before releasing any data. This ensures that the user is not being phished by a remote attacker.

The Detailed Flow:

Steps 1-2: Initialization

• Identical to Section 4.1.2. The Client Backend creates the session, and the Client Website opens a Pop-up Window pointing to the web_session_url

Step 3: Secure Tunnel Establishment

• Actor: QuickGate Frontend (Pop-up Window on Desktop).

• Action: Calls navigator.credentials.get().

• Browser UI: The Pop-up displays the system-generated QR code.

• User Action: User scans the QR code with their Smartphone Wallet.

• Security Check: The devices perform a Bluetooth Handshake to verify physical proximity.

• Tunneling: A secure, end-to-end encrypted tunnel (CTAP Hybrid) is established between the Wallet (Phone) and the Desktop Browser.

Step 4: Data Transfer & Return

• Action: The Wallet sends the Verifiable Presentation (VP) through the secure tunnel to the Pop-up Window's memory.

• Note: The VP is returned to the browser context, not posted directly to the backend from the phone.

Step 5-6: Verification & Handoff

• Action: The QuickGate Frontend (Pop-up) POSTs the VP to the QuickGate Core, receives the Authorization Code, and passes it to the Parent Window via window.opener.postMessage, exactly as described in Section 4.1.2.

4.3. Security Enhancement: Bi-Directional Triangular Encryption

Architectural Rationale:

While TLS 1.3 secures data in transit over the public internet, standard HTTPS termination occurs at the infrastructure edge (e.g., Cloudflare WAF, Cloud Load Balancers, Kubernetes Ingress). This implies that legally sensitive User Attributes (PII) and Authentication Secrets exist in plaintext within these intermediate systems and their associated logs before reaching the core logic.

To mitigate this, we implement Application-Layer Encryption (ALE). This architecture treats all intermediate network infrastructure as "Blind Proxies." By encrypting the payload at the application level (JWE), we ensure that data remains cryptographically opaque to WAFs, load balancers, and cloud monitoring tools (e.g., Datadog, Splunk), preventing accidental exposure in infrastructure logs.

To achieve a true Zero Trust architecture, we further refine this by acknowledging that the Client Backend serves two distinct roles with different privilege requirements:

1. Blind Proxy for Credentials: It relays the authorization proofs (authorization_code, code_verifier) from the App to QuickGate. It does not need to read these secrets.

2. Consumer of Identity: It receives the verified User Attributes to generate a session. It must be able to read this data.

We implement a Triangular Encryption Model (or "Sealed Request" pattern) to map these trust boundaries precisely to the cryptography.

The Cryptographic Flow:

1. Key Provisioning (The Triangle)

• QuickGate Public Key: Distributed via the QuickGate Client SDK (Mobile/Web) or provided during the Onboarding Configuration. Used by the Client App to seal the request.

• Client Backend Public Key: Registered with QuickGate Core during the Onboarding Process. Used by QuickGate to encrypt the response.

• Client Backend Private Key: Generated by the client and stored strictly in the Client Backend HSM (Hardware Security Module) or Secure Vault.

2. The Sealed Request (Client App → QuickGate)

• Actor: Client App (via QuickGate SDK).

• Action: The SDK bundles the authorization_code and code_verifier.

• Encryption: The SDK encrypts this payload using QuickGate's Public Key.

• Transit: The Client App sends this "Sealed Blob" (JWE) to the Client Backend via standard TLS.

• Relay: The Client Backend cannot read the blob. It attaches its own Secret API Key in the standard HTTP Headers and forwards the payload to QuickGate Core.

• Architectural Note: The API Key remains visible to the Infrastructure Layer (API Gateway/WAF) to enable high-speed Rate Limiting and DoS protection for unauthenticated traffic.

• Security Binding: To mitigate API Key theft, the Client App includes its client_id inside the encrypted JWE payload. QuickGate Core decrypts the payload and validates that the client_id inside the blob matches the account associated with the API Key in the header. A mismatch indicates that the API Key is being used out of context (e.g., stolen or replay attempt), triggering an immediate rejection.

• Benefit: Authentication secrets are never exposed to the Client Backend's logs, crash reports (e.g., Sentry/Firebase), or internal traffic sniffers, while the Infrastructure remains capable of protecting the Core.

3. The Trusted Response (QuickGate -> Client Backend)

• Actor: QuickGate Core.

• Action: QuickGate decrypts the Sealed Request (using its own Private Key) and verifies the proofs. It retrieves the User Attributes.

• Encryption: QuickGate encrypts the Identity Data using the Client Backend's Public Key.

• Transit: The encrypted JWE is returned to the Client Backend.

• Decryption: The Client Backend uses its Private Key to decrypt the PII in volatile memory, creates the Access Token, and wipes the data.

Table 4.3 Summary of Data Exposure

Data Segment	Visible to Client App?	Visible to Client Backend?	Visible to QuickGate?
Auth Secrets ( code / verifier )	Yes (Originator)	NO (Encrypted)	Yes (Verifier)
Identity Data (PII)	NO (Only Token)	Yes (Consumer)	Yes (Provider)

5. SDK Strategy: Accelerating Adoption & Ensuring Consistency

5.0. Why SDKs are Crucial for Success

1. Dramatically Easier Integration: Clients avoid OpenID4VP, JWT verification, and cryptographic complexity

2. Reduced Time-to-Market: Integration becomes hours/days instead of weeks/months

3. Fewer Support Tickets: Protocol changes require only SDK updates, not client re integration

4. Consistent Implementation: Ensures all clients handle errors, timeouts, and user flows correctly

5. Competitive Advantage: Well-designed SDKs create significant switching costs and differentiation

5.1. Server-Side SDK (Node, Java, Python)

Enhanced Responsibilities:

• Authentication (API Key management) and session creation

• Webhook signature verification with HMAC validation

• Error handling and retry logic normalization

Security Benefit: Keeps client secrets off the frontend entirely

5.2. Client-Side SDK (Mobile - Android/iOS)

Enhanced Responsibilities:

• Receives web_session_url from backend (never constructs it client-side)

• Safely launches System Browser with anti-phishing protections

• Listens for deep link callbacks and handles app state restoration

• Provides pre-built UI components for consistent user experience

5.3. Client-Side SDK (Web)

Enhanced Responsibilities:

• Renders "Verify with Wallet" button with auto device detection

• Mobile: Redirects to QuickGate verification URL

• Desktop: Renders Cross-Device QR Code

• Built-in analytics and error tracking

6. Operational Management: Admin Dashboard & Client Portal

While the Gateway Core handles the real-time verification flows, the Admin Dashboard serves as the primary interface for Relying Parties to manage their QuickGate integration, monitor operations, and maintain their compliance settings. It is a separate, secure web application that interacts with the Gateway's management APIs.

6.1. System Architecture & Isolation

Principle: The Dashboard is a client-facing Management Plane, physically and logically separated from the high-throughput, security-critical Data Plane (the Gateway Core). This isolation ensures that management activities do not impact the performance or security of live verification sessions.

• Separate Application Stack: The Dashboard runs on its own set of compute instances, with dedicated databases for client configuration and metadata.

• API First Design: All dashboard functions are driven by a secure set of internal RESTful APIs provided by the Gateway Core's management endpoints.

6.2. Core Functional Modules & Technical Implementation

The dashboard's capabilities directly fulfill the requirements outlined in F-OPS-001.

6.2.1. Client Onboarding & API Key Management (F-OPS-001.1)

This module handles the initial integration setup for a new client.

• Account Registration & Vetting: A multi-step UI guides new clients through providing their legal entity details, which are submitted for the initial RPRC registration process.

• API Key Generation: Upon successful onboarding, the system:

• Generates a high-entropy, unique client_id and api_key pair.

• Securely stores a bcrypt-hashed version of the api_key in the management database.

• Displays the api_key in clear text only once to the client upon generation, after which it is irrecoverable and must be rotated if lost.

• Webhook Configuration: Clients can register one or more endpoint URLs for receiving verification results. The UI allows for testing the webhook endpoint.

6.2.2. Usage Monitoring & Analytics (F-OPS-001.2)

This module provides visibility into verification activities, strictly adhering to data minimization (NF-PRI-001.3).

• Real-Time Metrics Dashboard: A UI populated by streaming analytics data (e.g., via WebSockets or frequent API polls) displays:

• Transactions per second/minute

• Success/Failure rate gauges

• Average verification latency

• Historical Reporting: Clients can filter and view aggregated, non-PII transaction logs by date range, status ( verified , failed , user_rejected ), and error code.

• Data Source: All metrics are generated from metadata logs (e.g., transaction_id , timestamp , status , error_code , client_id , requested_attributes_list) emitted by the Gateway Core to a dedicated analytics pipeline (e.g., Kafka stream processed by Flink/Spark).

6.2.3. Configuration Management (F-OPS-001.3)

This is the central hub for clients to define how they use the QuickGate service.

• Attribute Set Management:>

• A UI form allows clients to create and name different "Verification Profiles" (e.g., "Basic KYC", "Age Verification").

• For each profile, clients select the required user attributes from a pre-defined, ARF-aligned schema using a checkbox interface. This configuration is stored as a JSON presentation_definition template.

• RPRC & Legal Entity Linking:

• The dashboard displays the status of the client's RPRC (e.g., Expired).

• Clients can select which active RPRC and associated "Verification Profile" to use for different parts of their application.

• Billing Settings:

• Integrates with the payment provider (e.g., Stripe). Clients can view current usage against their plan, download invoices, and update payment method details.

6.3. Security Model for the Dashboard

• Authentication: Clients log in using a separate set of credentials (e.g., Email/Password, SSO). Multi-Factor Authentication (MFA) is enforced.

• Authorization: All requests from the Dashboard UI to the internal Management API are authenticated using a session token and authorized based on the client_id to ensure clients can only access their own data and configurations.

• Audit Logging: Every configuration change made via the Dashboard (e.g., API key rotation, webhook update) is logged for security and compliance auditing.

7. End-to-End Verifiable Audit Trail

To ensure cryptographic non-repudiation and process integrity without compromising the "Zero-Persistence" privacy model, QuickGate implements a Dual-Layer Audit Architecture. This combines a public transparency log with client-side sealed evidence.

A. Layer 1 The Transparency Log (Integrity Anchor)

QuickGate maintains a Merkle-Tree based Transparency Log to prove the existence and timing of every verification request.

1. Hashing: Upon completion of a verification, QuickGate generates a cryptographic hash of the transaction metadata: SHA256(Transaction_ID + Timestamp + LOTL_Fingerprint + Hash(Wallet_Signature)). Crucially, no PII (Personally Identifiable Information) or raw attribute values are included in this hash.

2. Aggregation: These transaction hashes are aggregated into a Merkle Tree structure.

3. Anchoring: The Merkle Root is periodically anchored to a public ledger (e.g., Ethereum or a specialized Transparency Log).

4. Purpose: This creates an immutable public record that a specific verification event occurred at a specific time, preventing QuickGate from retroactively altering transaction logs or fabricating history.

B. Layer 2 The Sealed Evidence Pattern (Content Proof)

While QuickGate proves the existence of the transaction, the Client must retain the content for legal defense. Since QuickGate wipes data immediately, the Spec mandates a Sealed Evidence Strategy for Clients via the SDK:

1. Sealing: Upon receiving the webhook payload, the Client SDK bundles the verified attributes PII and the raw wallet_signature.

2. Encryption: This bundle is immediately encrypted using a dedicated Audit Public Key (owned by the Client, with the Private Key held in offline cold storage/HSM).

3. Storage: The Client stores this Encrypted Audit Blob in their database.

4. Purpose: This ensures that PII remains inaccessible during daily operations (satisfying GDPR Data Minimization) but is cryptographically recoverable by the Client's Compliance Officer in the event of a regulatory audit or dispute.

C. The Verification Link

In the event of a dispute, an auditor decrypts the Client's Sealed Evidence to retrieve the original wallet_signature. By hashing this signature, the auditor can locate the corresponding record in QuickGate's Transparency Log (Layer 1). This mathematically proves that the data held by the Client is exactly what was verified by QuickGate at that specific moment in time.

8. Non-Functional Implementation Details

8.1. Security (NF-SEC)

Encryption: All data in transit protected via TLS 1.3.

Format Support: Parsing engines for SD-JWT (Identity) and mdoc/CBOR (Driver's Licenses) as per NF-SEC-003.1.

>Replay Protection: strict nonce validation on every request to prevent replay attacks.

8.2. Privacy & Data Minimization (NF-PRI)

8.2.1. The "Secure Pipe" Architecture

Memory-Only Processing Pipeline:

1. Receive Verifiable Presentation in volatile memory

2. Extract ONLY requested attributes (data minimization)

3. Verify trust chain against EU Trusted Lists

4. Immediately forward to Client Webhook

5. Force garbage collection and memory overwrite

Logging Constraints:

• Zero PII in logs, metrics, or analytics

• Only transaction_id , timestamp, status, error_code

• No attribute values, wallet identifiers, or user identifiers

8.2.2. Comprehensive Error Handling

Error Normalization:

Standard Error Code Examples:

• user_rejected: User explicitly declined consent

• timeout: Verification request timed out

• wallet_unavailable: No certified wallet installed

• network_error: Temporary connectivity issues

• invalid_request: Malformed presentation request

8.3. Scalability (NF-PER)

Stateless Core: The Gateway does not maintain sticky sessions. Session state is stored in a distributed ephemeral cache (e.g., Redis) allowing the Core to scale horizontally to meet the 99.9% availability target.

8.4. Session State Management and Reliability (NF-PER-001/002)

The system must ensure high reliability and responsiveness, especially during the critical authentication window.

Table 8.4: Requirements for Session State Management and Reliability

Requirement	Implementation Detail	Rationale
Real-Time Status	Server-Sent Events SSE or WebSockets MUST be used for the QuickGate Web client to listen for status changes from QuickGate Core.	Eliminates inefficient polling and provides immediate feedback, significantly improving NF-PER-002 (Latency) and user experience.
Session TTL (Backend)	All sessions MUST have a hard expiration (TTL) of 300 seconds (5 minutes) enforced in the distributed ephemeral cache.	Security and Data Minimization (NF-PRI-001). Prevents "zombie" sessions and adheres to time-limited transaction standards.
Request Expiration (OpenID4VP)	The generated JWT Request Object MUST include an exp claim set to iat + 300 seconds.	Ensures the Wallet Unit itself refuses to submit data for an expired transaction, aligning with OpenID4VP security best practices.
SSE Client Timeout	The QuickGate Web client MUST implement a disconnection timeout corresponding to the Session TTL. If the SSE stream breaks or remains idle past the session TTL, the client stops waiting and displays an "Expired" message.	Provides graceful failure for network issues or server crashes, ensuring the user is not stuck on a loading screen indefinitely.
Backend Crash Handling	When QuickGate Core receives a successful Direct POST from the Wallet, it MUST immediately verify the VP and send the webhook before responding to the Wallet, ensuring successful delivery is guaranteed before PII is wiped.	Guarantees that the Client Backend is notified even if the QuickGate Core fails immediately after VP reception.

9. Compliance Assurance

The Technical Specifications successfully implement all Functional Requirements (FR) and Non-Functional Requirements (NFR).

Table 9.1: Implementation of Functional Requirements (FR)

Functional Requirement Area	Implementation in Technical Specifications
F-CORE-001: Session Management	Detailed in Section 4.1. The POST /api/v1/sessions API creates sessions. Session state is managed in a distributed cache with a 5-minute TTL as defined in Section 8.4.
F-CORE-002: Credential Processing	Section 3.2 outlines verification logic against EU Trusted Lists. Section 8.1 confirms support for SD-JWT/mdoc formats. The "Secure Pipe" architecture in Section 8.2.1 enforces data minimization.
F-CORE-003: Secure Data Forwarding	The core data flow in Section 4.1 shows immediate forwarding via TLS. The "Memory-Only Processing Pipeline" in Section 8.2.1 explicitly mandates memory wiping post-forwarding.
F-CORE-004: Integrity & Audit	Section 7 details the "Dual-Layer Audit Architecture." It implements F-CORE-004.1 (Transparency Log/Merkle Tree) and F-CORE-004.2 (Sealed Evidence) to ensure non-repudiation.
F-CLIENT-001: API & SDK Interfaces	Section 2.2 defines the REST API, and Section 5 is dedicated to the SDK strategy. The presentation_definition in Section 3.3 implements the Attribute Request Schema.
F-CLIENT-002: UI Integration	The primary user flows (Scenario A, B in Section 4) directly implement Same-Device and Cross-Device flows. Status Polling via SSE is mandated in Section 8.4.
F-PROTOCOL-001/002: Protocols	Section 2.1 clearly defines OpenID4VP as the underlying engine and DC API as the primary interface. Support for ISO 18013-5 is stated in Section 2.1.
F-OPS-001: Admin Dashboard	Section 6 provides a dedicated architectural breakdown of the Admin Dashboard, explicitly detailing Client Onboarding (6.2.1), Usage Monitoring (6.2.2), and Configuration (6.2.3).

Table 9.2: Implementation of Non-Functional Requirements (NFR)

Requirement	Implementation Detail	Rationale
Real-Time Status	Server-Sent Events SSE or WebSockets MUST be used for the QuickGate Web client to listen for status changes from QuickGate Core.	Eliminates inefficient polling and provides immediate feedback, significantly improving NF-PER-002 (Latency) and user experience.
Session TTL (Backend)	All sessions MUST have a hard expiration (TTL) of 300 seconds (5 minutes) enforced in the distributed ephemeral cache.	Security and Data Minimization (NF-PRI-001). Prevents "zombie" sessions and adheres to time-limited transaction standards.
Request Expiration (OpenID4VP)	The generated JWT Request Object MUST include an exp claim set to iat + 300 seconds.	Ensures the Wallet Unit itself refuses to submit data for an expired transaction, aligning with OpenID4VP security best practices.
SSE Client Timeout	The QuickGate Web client MUST implement a disconnection timeout corresponding to the Session TTL. If the SSE stream breaks or remains idle past the session TTL, the client stops waiting and displays an "Expired" message.	Provides graceful failure for network issues or server crashes, ensuring the user is not stuck on a loading screen indefinitely.
Backend Crash Handling	When QuickGate Core receives a successful Direct POST from the Wallet, it MUST immediately verify the VP and send the webhook before responding to the Wallet, ensuring successful delivery is guaranteed before PII is wiped.	Guarantees that the Client Backend is notified even if the QuickGate Core fails immediately after VP reception.

9. Compliance Assurance

The Technical Specifications successfully implement all Functional Requirements (FR) and Non-Functional Requirements (NFR).

Table 9.1: Implementation of Functional Requirements (FR)

Non-Functional Requirement Area	Implementation in Technical Specifications
NF-SEC: Security	Zero-Trust architecture is fundamental. TLS 1.3/Triangular Encryption are defined in Section 4.3. Section 7 implements NF-SEC-004 (Auditability) via the Transparency Log, ensuring non-repudiation without PII storage.
NF-PRI: Privacy & Data Protection	The "Zero-Persistence" and "Secure Pipe" principles in Section 1.1 and Section 8.2.1 directly fulfill NFPRI 001. The architecture supports ISO 27001/27701 compliance as detailed in Section 8.2.
NF-INT: Interoperability	Section 2.1 provides a clear matrix of supported protocols (OpenID4VP, DC API) and scenarios (Same-Device, Cross-Device, Proximity).
NF-PER: Reliability & Performance	The system is designed as stateless for horizontal scaling (Section 8.3). The 1-second latency target is stated in Section 3.2. Session reliability is defined in Section 8.4.

3. Alignment with Business, Legal, and Market Goals

• Business Model: The stateless, API-driven gateway enables precise Pay-As-You-Go metering.

• Legal Solution: Section 3.1 details RPAC/RPRC management ("Compliance by Proxy"). Section 7 (Audit) provides the critical "Evidence for Defense" capability required by legal teams.

• Market Advantage: The SDK Strategy (Section 5) and Dashboard (Section 6) deliver on the promise of "Stripe-like" simplicity.

Part 3: Functional Specifications (F-REQS)

The "What" Scope of Capabilities.

This section outlines the core functional requirements of the QuickGate platform, detailing the specific tasks the system must perform to achieve its purpose as a compliant EUDI Wallet Intermediary.

1. Gateway Core Services (The Intermediary Role)

The Gateway Core is the heart of QuickGate, responsible for managing the entire identity verification lifecycle between the Relying Party (Client) and the EUDI Wallet Unit.

1.1. Verification Session Management (F-CORE-001)

The system must generate, manage, and secure a unique, time-limited verification session for every identity request initiated by a client.

• F-CORE-001.1 (Session Creation): Create a secure, single-use session upon receiving an identity request from a Client Server SDK.

• F-CORE-001.2 (Request Generation): Generate a valid OpenID4VP Request Object (as a signed JWT) containing the requested attributes, callback URI, and nonce specific to the session.

• F-CORE-001.3 (Session State): Maintain the state of the session (e.g., Awaiting Presentation, Verification In Progress, Success, Failed) without storing the requested PII.

• F-CORE-001.4 (Time-Out): Automatically time out and invalidate sessions that remain inactive for a predefined period (e.g., 5 minutes) to mitigate risk.

1.2. Credential Processing & Validation (F-CORE-002)

Upon receiving a Verifiable Presentation from a User Wallet, the system must perform mandatory cryptographic checks.

• F-CORE-002.1 (Signature Validation): Cryptographically validate the signature of the Verifiable Presentation (VP) against the corresponding Wallet Unit's key, using the EU Trusted Lists for certificate chain validation.

• F-CORE-002.2 (Credential Decoding): Successfully decode and parse credentials presented in mandated formats: SD-JWT and mdoc (CBOR/COSE).

• F-CORE-002.3 (Data Minimization Enforcement): Functionally extract only the attributes requested by the Client and consented to by the user, discarding all extraneous data.

• F-CORE-002.4 (Replay Protection): Implement and enforce nonce checking to prevent the fraudulent reuse of a presentation in subsequent sessions.

1.3. Secure Data Forwarding and Wiping (F-CORE-003)

Adhering to strict Data Minimization requirements, the system must process data in a memory-only environment.

• F-CORE-003.1 (Forwarding): Immediately forward the verified, extracted user attributes to the Client's pre-configured webhook endpoint via a secure, authenticated channel (TLS 1.3).

• F-CORE-003.2 (Memory Wipe): Functionally and programmatically destroy all processed PII and attribute data from volatile memory RAM immediately upon successful forwarding to the client.

1.4. Integrity & Audit Services (F-CORE-004)

The Core must generate and distribute cryptographic proofs of verification.

• F-CORE-004.1 (Transparency Logging): For every completed session, the system must compute a cryptographic hash of the transaction metadata and Wallet Signature, and append this hash to an immutable, append-only log (e.g., Merkle Tree)

• F-CORE-004.2 (Evidence Delivery): The system must return the raw wallet_signature to the Client (via Webhook/SDK) to enable the "Sealed Evidence" pattern, allowing the Client to store the proof locally while QuickGate wipes the data.

• F-CORE-004.3 (Verification Endpoint): The system must provide a public endpoint where a transaction hash can be submitted to verify its inclusion and timestamp in the Transparency Log.

2. Client Integration Services (Relying Party Interface)

These functions define how Client applications (Relying Parties) integrate with and leverage the QuickGate platform.

2.1. API & SDK Interfaces (F-CLIENT-001)

The system must provide clear, well-documented interfaces for integration.

• F-CLIENT-001.1 (Server API): Provide a REST API for Server SDKs (Node.js, Java, Python) to initiate verification requests and define webhooks.

• F-CLIENT-001.2 (Client SDKs): Provide client-side SDKs (Web, iOS, Android, React Native, Flutter) that handle the front-end user experience, including generating QR codes, managing deep links, and listening for the verification result.

• F-CLIENT-001.3 (Attribute Request Schema): Allow clients to specify required identity attributes using a defined JSON schema aligned with EUDI ARF and country-specific mappings.

2.2. User Interface Integration (F-CLIENT-002)

The client-side components must facilitate various user flows.

• F-CLIENT-002.1 (Same-Device Flow): When initiated on a mobile device, the SDK must trigger the appropriate operating system intent or deep link to invoke the Wallet App.

• F-CLIENT-002.2 (Cross-Device Flow): When initiated on a desktop browser, the SDK must render a standard OpenID4VP QR code that contains the session request URI.

• F-CLIENT-002.3 (Status Polling): The client-side interface must poll the QuickGate Gateway to receive real-time status updates on the verification session (Pending, Verified, Failed).

3. Supported Protocols and Formats

QuickGate must function as a protocol translation layer, abstracting complexity from the client.

3.1. Remote Protocol Support (F-PROTOCOL-001)

• F-PROTOCOL-001.1 (OpenID4VP): Full functional support for all mandated features of the OpenID4VP protocol, including both Request URI and Request Object formats.

• F-PROTOCOL-001.2 (DC API): Functional readiness to interface with the Digital Credentials API to enable modern, browser-based credential presentation flows.

3.2. Proximity Protocol Support (F-PROTOCOL-002)

• F-PROTOCOL-002.1 (ISO 18013-5): The Server SDK must functionally support the initiation and processing of verification sessions based on the ISO/IEC 180135 standard for physical/in-person verification (NFC/Proximity QR).

4. Operational Management and Monitoring

The system must provide tools for operational oversight and client management.

4.1. Admin Dashboard Functions (F-OPS-001)

The QuickGate Admin Dashboard must provide core management and visibility functions for the client Relying Parties.

• F-OPS-001.1 (Client Onboarding): Functionality to register new client accounts, issue unique API keys, and configure client webhooks.

• F-OPS-001.2 (Usage Monitoring): Display real-time and historical transaction volumes, success rates, and error logs (metadata only, no PII).

• F-OPS-001.3 (Configuration Management): Allow clients to define their required attribute sets, link their legal entities to the appropriate QuickGate RPRC (Relying Party Registration Certificate), and manage billing settings.

Part 4: Non-Functional Specifications (NF-REQS)

The "Quality" Security, Privacy & Performance Standards.

These requirements outline the system attributes QuickGate must satisfy to operate as a compliant European Digital Identity EUDI Wallet Intermediary.

1. Security Requirements (NF-SEC)

Adherence to a Zero-Trust Architecture is mandated for all system lifecycles.

1.1. Communication Security (NF-SEC-001)

The system must ensure all data exchanged is protected during transit.

• NF-SEC-001.1 (Encryption Standard): All external communications (Client to Gateway and Gateway to Wallet) must be encrypted using TLS 1.3 or higher.

• NF-SEC-001.2 (Protocol Security): Wallet interactions must strictly adhere to OpenID4VP security profiles, utilizing mTLS or signed JWTs for client authentication where applicable.

• NF-SEC-001.3 (Flow Prioritization): The system must prioritize browser-mediated flows over direct custom URL schemes to mitigate security risks associated with deep links.

1.2. Authentication & Authorization (NF-SEC-002)

The system must verify the identity and permissions of all interacting parties.

• NF-SEC-002.1 (Client Authentication): Relying Parties (Clients) must authenticate via high-entropy API Keys or Mutual TLS (mTLS).

• NF-SEC-002.2 (Wallet Trust): QuickGate must authenticate itself to Wallet Units using Relying Party Access Certificates (RPAC) and validate all Wallet signatures against the EU Trusted Lists.

1.3. Cryptographic Agility (NF-SEC-003)

The architecture must support required and evolving cryptographic standards.

• NF-SEC-003.1 (Format Support): The system must support signature verification for SD-JWT and mdoc (CBOR/COSE) credential formats.

• NF-SEC-003.2 (Key Management): The architecture must allow for the seamless rotation of cryptographic keys without service interruption.

1.4. Auditability & Non-Repudiation (NF-SEC-004)

The system must provide cryptographic proof of transaction integrity without compromising user privacy.

• NF-SEC-004.1 (Immutable Evidence): The system must generate a tamper-evident record for every verification session that proves the existence and validity of the transaction.

• NF-SEC-004.2 (Privacy-Preserving Logs): Audit logs must be cryptographically hashed such that verification can occur without QuickGate retaining or reading the underlying PII (Zero-Knowledge property).

• NF-SEC-004.3 (Dispute Resolution): The architecture must support a mechanism where a Client can cryptographically prove to a third party (auditor/regulator) that a specific attribute set was verified by QuickGate at a specific time.

2. Privacy & Data Protection (NF-PRI)

Strict adherence to Data Minimization and Privacy by Design is mandatory (acting as a "pipe," not a "bucket").

2.1. No Storage of PII (Memory-Only Processing) (NF-PRI-001)

The system is prohibited from storing sensitive user data.

• NF-PRI-001.1 (PII Storage Ban): QuickGate shall not store data about the content of the transaction (User Attributes/PII).

• NF-PRI-001.2 (Memory Processing): Attributes must be processed in volatile memory (RAM), forwarded, and then securely overwritten/wiped immediately.

• NF-PRI-001.3 (Log Data Minimization): System logs must contain only transaction metadata (e.g., timestamps, status, error codes) and never PII.

2.2. Compliance Standards (NF-PRI-002)

The system must be built to demonstrate formal compliance with key standards.

• NF-PRI-002.1 (GDPR Assurance): The system architecture must support formal demonstration of GDPR compliance.

• NF-PRI-002.2 (Security Certification): The system architecture must support compliance with ISO/IEC 27001 and ISO/IEC 27701.

3. Interoperability & Platform Compatibility (NF-INT)

The platform must handle protocol and environment fragmentation to maximize adoption.

3.1. Primary Protocol Support (NF-INT-001)

The system must support foundational EUDI protocols.

• NF-INT-001.1 (OpenID4VP): Must be supported as the baseline protocol for immediate compliance and remote verification flows.

• NF-INT-001.2 (DC API): Must be implemented as the strategic standard for web-based flows to ensure browser-level security and simplify user experience.

3.2. Supported Integration Environments (NF-INT-002)

The platform must ensure seamless verification across all user touchpoints.

• NF-INT-002.1 (Same-Device Flow): The system must support flows where the User and the Wallet are on the same device (Mobile or Desktop web browser), including handling deep links or system intents.

• NF-INT-002.2 (Cross-Device Flow): The system must support "Second Device" flows where a desktop-initiated request displays a QR code for a mobile Wallet to scan.

• NF-INT-002.3 (Physical/Proximity): The system must support in-person verification scenarios using ISO/IEC 180135 standards (NFC or QR).

4. Reliability & Performance (NF-PER)

The system must be highly available and responsive to prevent user drop-off.

4.1. High Availability (NF-PER-001)

The service must remain operational for critical infrastructure clients.

• NF-PER-001.1 (Availability Target): Target availability of 99.9% is required.

• NF-PER-001.2 (Architecture): The Gateway Core must be stateless to allow for instant horizontal scaling and load balancing.

4.2. Latency (NF-PER-002)

Back-end processing time must be minimized to enhance user experience.

• NF-PER-002.1 (Transaction Time): Cryptographic verification (including signature validation against Trusted Lists) must not exceed 1 seconds for total back-end processing.

The EUDI Mandate: A Market-Wide Challenge

By late 2027, under the amended eIDAS Regulation, private companies in key sectors— including banking, financial services, and crypto platforms—will be legally required to accept the EU Digital Identity EUDI Wallet for strong user authentication and the presentation of verified identity data (identification and verification). Furthermore, under the new Anti-Money Laundering (AML) Regulation, these institutions are explicitly authorized to use the EUDI Wallet to fulfill their strict customer identity verification (KYC) obligations.

1. The Obligation to Accept the Wallet

Regulation: Regulation EU 2024/1183 (amending Regulation EU No 910/2014) also known as eIDAS 2.0

• Who must accept it?

Private "relying parties" providing services in specific sectors where "strong user authentication" is required by law or contract. This includes banking, financial services, transport, energy, social security, health, drinking water, postal services, digital infrastructure, education, and telecommunications. Exemptions: Microenterprises and small enterprises.

• The Deadline

These entities must accept the wallet no later than 36 months after the entry into force of the implementing acts. This places the effective deadline around late 2027.

• Source: (Article 5f(2) of Regulation (EU) 2024/1183)

2. Using the Wallet for Customer Verification (KYC/AML)

Regulation: Regulation EU 2024/1624 (Anti-Money Laundering Regulation)

• Can it be used for verification?

Yes. The new AML Regulation explicitly permits "obliged entities" (banks, crypto-asset service providers, etc.) to use electronic identification means compliant with the eIDAS Regulation (which includes the EUDI Wallet) to verify a customer's identity.

• Why this matters?

It provides the legal certainty that using the EUDI Wallet satisfies the strict "Customer Due Diligence" (CDD) requirements necessary to prevent money laundering.

• Source: (Article 226)(b) of Regulation (EU) 2024/1624

Problem: Technical and Legal Hurdles

The Core Problem for Businesses (Relying Parties: banks, crypto exchanges etc.): The process of direct integration is complex and fragmented, involving strict technical and legal procedures. Each Relying Party (RP) must:

1. Individually integrate with multiple, disparate EUDI Wallet implementations and protocols. This requires supporting:

• OpenID4VC/OpenID4VP - The current standard for online verifiable presentations

• Digital Credentials API - The emerging W3C standard for browser-mediated flows

• Multiple trust anchors - Each Wallet Provider uses unique EAA (Electronic Attestation of Attributes) Certificates, requiring validation against periodically updated Trusted Lists from 27 EU Member States

2. Obtain a specialized certificate as per Implementing Regulation EU 2025/848.

This presents a significant technical, legal, and operational hurdle with a hard deadline.

Solution: QuickGate (EUDI Wallet Gateway)

QuickGate is a EUDI Wallet Gateway designed to simplify and accelerate compliance for Relying Parties. We're doing for EUDI compliance what Stripe did for payments.

How It Works:

QuickGate acts as an Intermediary on behalf of your business. As defined in the EUDI Wallet Architecture (Section 3.11.3), an Intermediary is a special class of Relying Party that acts for others.

• Compliance by Proxy & No Certificate Hassle: We manage all the complex legal and technical registration with EU trust registries on your behalf. You operate under our compliance umbrella, eliminating the need for you to obtain and manage your own specialized Relying Party Certificates. The operational contract between us serves as the legal basis for this, allowing you to leverage our status as a compliant Relying Party.

• Single Integration: Your platform integrates once with QuickGate's unified API (instead of integrating all EUDI wallets).

• Wallet Agnostic: We handle the complexity of connecting to all various EUDI Wallets.

• Security by Design: QuickGate is built with security at its core, leveraging a zero-trust architecture and the expertise of software engineers experienced in high-security systems. This ensures end-to-end protection for all data in transit and compliance operations.

• Data Relay & Minimization: We request the necessary user attributes from the wallet and forward them securely to your system. In strict adherence with Section 3.11.3, we do not store any data related to the content of the transaction.

• Audit Log Integrity: QuickGate provides zero-PII, cryptographically anchored audit logs, ensuring legal non-repudiation without storing user data. Each verification generates a hash-only entry in a Merkle-based transparency log, while raw attributes remain only with the client as an encrypted evidence blob.

• Key Legal & Operational Assurance: The European Digital Identity Regulation (Art. 5b(10)) states: "Intermediaries acting on behalf of relying parties shall be deemed to be relying parties."

Legal Problem Details: The Certification Burden

For any company to accept the EUDI Wallet directly, they must undergo a complex and costly certification process as a Relying Party:

1. Obtain a Relying Party Access Certificate (RPAC): This requires formal registration with a National Registrar in an EU Member State, involving a detailed assessment of their technical and organizational security measures. This registration process is further detailed in Commission Implementing Regulation EU 2025/848 , which establishes the specific rules for registering wallet-relying parties across all Member States

2. Demonstrate High-Level Security & GDPR Compliance: The registration process is "proportionate-to-risk," meaning companies must provide evidence of robust security and data protection practices. This is demonstrated through internationally recognized certifications, primarily:

• ISO/IEC 27001 for Information Security Management - necessary to validate adherence to Regulation (EU) 2024/1183 Recital 12 (security by design) and pass the "proportionate-to-risk" assessment required by Article 5b(2).

• ISO/IEC 27701 for Privacy Information Management (extending GDPR compliance)- required to fulfill Regulation EU 2024/1183 Article 5a(17) of , which explicitly states that "Compliance of such processing with Regulation (EU) 2016/679 (GDPR) shall be demonstrated"

This presents a significant barrier: each company must individually navigate a legal and technical certification landscape, a process that is time-consuming, expensive, and requires specialized expertise.

Legal Solution: Compliance by Proxy

QuickGate eliminates this entire burden by acting as your Intermediary Relying Party.

How it works:

1. We Hold the Certificates: QuickGate undergoes the rigorous certification process once to obtain our own RPAC and the necessary Relying Party Registration Certificates (RPRC) on behalf of our clients.

2. You Operate Under Our Compliance Umbrella: Your company leverages our certified status. You are not required to obtain your own RPAC or the associated ISO certifications.

3. The Legal Foundation is a Contract: The operational service contract between your company and QuickGate serves as the legal basis for this relationship, explicitly authorizing us to act on your behalf. This is fully compliant with the EUDI Wallet Architecture Framework.

Reference: Annex-2, RPI_04

Result: You achieve full legal compliance with the eIDAS mandate through a simple commercial agreement, bypassing a multi-year, high-cost certification journey.

How We Ensure Compliance: Our Trust Framework

As a certified Intermediary Relying Party, QuickGate is built on the principle that trust is the foundation of digital identity. We are committed to upholding the highest standards to protect the ecosystem, our clients, and end-users.

1. Governance & Compliance Framework

We operate under a "Security-by-Design" model, strictly adhering to:

• eIDAS 2.0 Regulation: Ensuring full compliance with the European Digital Identity Architecture and Reference Framework (ARF).

• GDPR: Acting as a compliant Data Processor, enforcing principles of data minimization and purpose limitation in every transaction.

2. Certification & Assurance

To validate our integrity to regulators and stakeholders, we maintain a certified Integrated Management System:

• ISO/IEC 27001 (Information Security): Implements rigorous controls for confidentiality, integrity, and availability, strict access controls, and vulnerability management.

• ISO/IEC 27701 (Privacy Management): Extends our security controls to formally demonstrate our compliance with GDPR requirements for processing personal data.

3. Operational Commitments

• Strict Data Minimization: We forward only the user attributes you request and the user consents to. We do not store any personally identifiable information PII from the transaction.

• Cryptographically Enforced Confidentiality: Data transmitted between the client and QuickGate is protected by end-to-end encryption at the application level. This ensures that no intermediary—including our own infrastructure—can access the data payload, strictly enforcing our Zero-Trust and Zero-Persistence commitments.

• Audit Log Integrity: We provide zero-PII, cryptographically anchored audit logs to ensure legal non-repudiation for all verification transactions. While the transparency log (Merkle-based) provides proof of verification, the raw attributes are secured by the client within an encrypted evidence blob, completing the legal chain of custody without compromising user privacy.

• Continuous Auditing: We undergo regular third-party audits to maintain our certifications and ensure ongoing alignment with evolving ETSI standards and regulatory requirements.

Technical Problem Details: Hurdles for EUDI Wallet Integration

To comply with the EUDI mandate, businesses face a set of distinct technical requirements:

• Front-End Integration across All Platforms:

Relying Parties need client-side integrations (with EUDI Wallet) for web, mobile, desktop, and physical proximity scenarios. This includes supporting strong user authentication flows, both online and in-person, with seamless user experience.

• Mandatory Support for OpenID4VP and Digital Credentials API:

Direct integration with the OpenID4VP protocol remains essential, as it's the currently mandated standard throughout the EUDI reference architecture for requesting and sharing Verifiable Presentations online.

However, the strategic direction for remote flows is the Digital Credentials API ("Cred_API") as described in Topic F (section OIA_08). This API offers secure credential issuance, access, and presentation, and addresses both same-device and cross-device user flows. its currently being standardized through the Digital Credentials API by W3C.

• Unlike direct integration using custom schemes (e.g. mdoc-openid4vp:// ), which are interim and raise security issues, Cred_API enables browser-mediated flows, supporting proximity and remote use cases.

• The EUDI ecosystem is actively working towards adoption of Digital Credentials API for long-term interoperability.

• SDKs and integrations must support OpenID4VP for immediate compliance, while also preparing for upcoming requirements and greater reliability via Digital Credentials API.

• Verification of Credentials from All EU Member States:

Identity verification requires validating cryptographic attestations from multiple EUDI Wallet providers. Each provider’s certificates must be checked against the trusted lists issued by 27 EU Member States.

• The solution must support signature verification for formats such as SD-JWT (Selective Disclosure JWT) and mdoc (CBOR/COSE).

• Real-time revocation checks (OCSP/CRL) are also necessary.

• Monitoring & Analytics (Optional, but Valuable):

To improve operational reliability, businesses benefit from monitoring tools that track verification success rates, failure reasons, and process metrics across platforms and wallet providers.

Non-Functional Requirements:

• Security best practices: Protocols must be implemented according to regulatory standards (EUDI, eIDAS) and only use certified libraries/APIs; data confidentiality and integrity are non-negotiable.

• Mandatory Non-Repudiation Audit Trail: The solution must deliver a cryptographically-anchored audit trail to ensure legal non-repudiation for all transactions, while simultaneously upholding the Zero-Persistence principle of never storing user PII.

Bottom line:

Complying with EUDI Wallet requirements means supporting secure, standards-based integrations for OpenID4VP and Digital Credentials API across relevant platforms, robust certificate verification workflows, and optional monitoring tools.

Technical Solution: EUDI Wallet Gateway with Complete Ecosystem

"We're doing for EUDI compliance what Stripe/PayPal did for payments" - Turning complex regulatory infrastructure into simple API calls.

Essential Components

1. Gateway Core

• API Layer: Unified REST API for all wallet integrations

• Session Management: Handles verification flows & state

• Trust & Validation: Service Manages wallet provider certificates & validation

• Protocol Engines: Built-in support for the mandated OpenID4VP protocol and readiness for the future Digital Credentials API (DC API).

2. SDK Suite

We provide SDK for all major platforms, making integration a matter of a few lines of code

Platforms: Web, Node.js, Java, Python, React Native, Flutter, iOS, Android

Server SDKs: Tools for secure webhook handling, session creation, and backend integration.

3. Admin Dashboard

• Client management & API keys

• Real-time verification monitoring

• Analytics & success rate tracking

• Usage metrics & billing

4. Developer Tools

• Comprehensive Docs: API reference, quick start guides

• Sandbox Environment: Test with mock wallets

• Zero-Trust Architecture: We use application-layer encryption for data exchange between the client's system and the QuickGate API, providing defense-in-depth. This guarantees that even internal infrastructure (proxies, load balancers, etc.) cannot view the data payload, reinforcing the Zero-Trust and Zero-Persistence architecture.

• Data Minimization: No storage of user PII

• Audit Log Integrity: QuickGate provides zero-PII, cryptographically anchored audit logs, ensuring legal non-repudiation without storing user data. Each verification generates a hash-only entry in a Merkle-based transparency log, while raw attributes remain only with the client as an encrypted evidence blob. This delivers full auditability for regulators while preserving strict data minimization.

Bottom Line: Complete platform that turns EUDI compliance from a complex regulatory and technical burden into a simple API call.

Our Go-To-Market Advantage & Strategic Position

While the market waits for official government wallets and certification bodies to become active, QuickGate is building now. Leveraging deep expertise in security-focused software engineering, our team is designing a solution that is ahead of the market and built with security at its core.

Building Ahead of the Market

1. Proactive Development: The reference wallet—which each EU state will use to build their own wallets—and the OpenID4VP protocol (used by the EUDI Wallet for requesting and presenting credentials) implementation are open source. We are using them to pre-build our entire backend, SDKs, and integration layers, bypassing the current certification deadlock.

2. First-Mover in an Empty Market: The market for such gateway solutions is virtually empty. Only two potential competitors (Verimi and Namirial) exist, with Verimi’s solution not expected until late 2026 and no clear information accessible for Namirial’s production state.

3. Clear Business Model: We are initiating conversations with Relying Parties to sign pre-commitment agreements for a product that will be market-ready well before the 2026/2027 deadline.

Deep Technical Expertise & Secure Architecture Foundation

Beyond regulatory and protocol alignment, QuickGate is being developed by a team of security software engineers with a proven track record in high-security systems — including Zero-Trust cloud infrastructure, true end-to-end encrypted communication systems, cryptography and blockchain related software solutions. This allows us not only to integrate the EUDI framework but also to implement it with real cryptographic rigor instead of “checkbox” compliance. We don’t treat security as compliance decoration — it’s our architectural substrate.

Call to Action for Relying Parties

The 2027 deadline is approaching. Instead of facing a last-minute, costly, and complex integration scramble, partner with QuickGate for a secure, simple, and compliant solution.

Motto: We're doing for EUDI compliance what Stripe did for payments

QuickGate Business Model: Usage-Based (Pay-As-You-Go)

The QuickGate revenue model is designed for simplicity, transparency, and scalability, aligning the client's cost directly with the business value received.

Key Revenue Driver: Transaction Volume (Cost Per API Request)

QuickGate operates on a Usage-Based Pricing (Pay-As-You-Go) model, ensuring that clients only pay when they successfully receive value from the service.