Web of Trust: Data Access Consent Demo

Introduction

This article presents a demonstration of the Web of Trust (WoT) system’s Enhanced Consent mechanism for granting data access to autonomous agents. The demo showcases how WoT acts as a trusted intermediary, extending traditional OAuth2/OIDC identity standards to provide users with granular, transparent control over which organizations and their autonomous agents can access their data from third-party providers.

Unlike standard OAuth2 consent flows where only the client application is disclosed, WoT’s Enhanced Consent Screen explicitly presents the Organization, the specific Agent (autonomous entity), the Data Provider, and the Identity Provider involved in the data access request. This transparency enables users to make informed decisions about granting access while WoT maintains cryptographic accountability for all data access operations.

Context: Where This Demo Fits in Web of Trust

The Web of Trust system provides a comprehensive framework for managing trust relationships, identity verification, consent, and data access across organizations, users, and autonomous entities. The following diagram illustrates the four foundational use cases of WoT:

The demo presented in this article focuses specifically on Use Case #3: User Granting Data Access, which represents a critical interaction point where:

• Use Case #1 - Establishing Trust: Trust anchors (organizations, identity verification providers) have already been established within the WoT ecosystem
• Use Case #2 - Registering Trusted Entities: Organizations and their autonomous agents have been registered as trusted entities within WoT
• Use Case #3 - User Granting Data Access (This Demo): Users grant explicit, granular consent for registered agents to access their data from third-party providers like Google
• Use Case #4 - Agent Accessing Data: Authorized agents subsequently access user data in accordance with the granted consent

This demonstration illustrates the consent workflow that bridges user authorization with autonomous agent data access, showing how WoT extends traditional identity protocols to support the unique requirements of autonomous operations.

Demo: Participants

The demonstration involves four key participants working together to enable the enhanced consent flow:

User with Browser

The end user accessing the WoT Portal through a web browser. The user initiates the data access consent process and makes decisions about which data to share with which organizations and agents.

WoT Portal (React Frontend)

A web-based frontend application built with React that provides the user interface for the Web of Trust system. The portal presents the Enhanced Consent Screen and manages the user’s interaction with the consent flow.

Identity Subsystem (Rust Backend)

The WoT backend service implemented in Rust that orchestrates the authorization workflow. It serves the authorization options, manages the consent process, and coordinates with external identity and data providers. The Identity Subsystem implements the core business logic for data access authorization following Clean Architecture principles.

Google Authorization Service (OAuth2/OIDC)

Google’s standard OAuth2 and OpenID Connect authorization service, which acts as both the Identity Provider (IdP) and Data Provider for this demonstration. Google authenticates the user and manages consent for WoT (as an OAuth2 client) to access the user’s Google data.

Demo: Video

Demo: Walkthrough

The demonstration showcases the complete flow of the enhanced consent process:

1. Sign-In Initiation

The user navigates to the WoT Portal landing page and clicks the “Sign In with Google” button to initiate the data access consent flow.

2. Enhanced Consent Screen (WoT Layer)

After clicking the sign-in button, the user is immediately presented with WoT’s Enhanced Consent Screen. This screen provides comprehensive transparency about the data access request by displaying:

• Organization: The organization requesting data access on behalf of its autonomous agent
• Agent/Application: The specific autonomous agent or application that will access the data
• Data Provider: Google (in this demo), indicating where the data resides
• Identity Provider: Google (in this demo), confirming who will authenticate the user
• Data Types: A detailed list of data types being requested (e.g., email, profile information, calendar access), with user-selectable checkboxes allowing granular control over which data types to grant access to
• WoT Intermediary Disclaimer: A clear message explaining that Web of Trust acts as a trusted intermediary and will facilitate access to the data strictly in accordance with the granted consent

This Enhanced Consent Screen is a WoT-specific addition to the standard OAuth2 flow, providing users with critical context about the autonomous operations and organizational relationships involved in the data access request.

3. Google Consent Screen (IdP Layer)

After accepting the WoT Enhanced Consent, the user is redirected to Google’s standard OAuth2 consent screen. This screen displays:

• OAuth2 Client: “Web of Trust” as the registered OAuth2 client application
• Requested Scopes: The specific data and permissions that WoT (as the OAuth2 client) will have access to on behalf of the user

Important Clarification: Google’s consent screen does not include information about the Organization or Agent mentioned in the WoT Enhanced Consent Screen. From Google’s perspective, WoT itself is the OAuth2 client requesting access. Google has no knowledge of the downstream organizations and autonomous agents that WoT represents. This is a fundamental aspect of WoT’s role as a trusted intermediary—WoT obtains consent from the data provider (Google) while separately managing and enforcing the user’s granular consent for specific organizations and agents.

Pending in this Flow

The demonstration concludes after the user completes Google’s consent screen. In the full production flow, additional steps would follow including:

• Token exchange and validation
• Cryptographic binding of consent to the user’s identity
• Storage of consent attestations
• Agent authentication and data access

Code: Structure and Architecture

The backend implementation of this demonstration follows a highly modular, layered architecture as illustrated below:

Modular Component Hierarchy

The WoT Identity Subsystem implements the data access authorization workflow through a hierarchical structure of components, each with clearly defined responsibilities:

API Handlers

Entry points that receive HTTP requests from the WoT Portal frontend. The Identity API Handler parses incoming requests, extracts parameters, and delegates business logic execution to the appropriate Operation.

Operations

High-level business logic coordinators implemented as standalone Rust library crates. The Authorize Data Access Operation exposes methods that express business capabilities:

• serve_get_authorization_options(): Provides the authorization options for the consent screen
• serve_authorization_callback(): Handles the callback from the Identity Provider after user consent

Operations define what the system does from a business perspective and orchestrate the execution of Assemblies to achieve these goals.

Assemblies

Workflow orchestrators implemented as independent Rust library crates. Each Assembly implements a specific workflow by coordinating a sequence of Tasks. For example:

• Authorization Options Assembly: Orchestrates the tasks needed to build authorization request parameters
• Authorization Callback Assembly: Orchestrates the tasks needed to process the authorization callback

Assemblies define how a specific workflow is achieved.

Tasks

Granular, single-responsibility units of work implemented within Assemblies. Tasks implement granular logic such as:

• Constant Authz Options Accessor: Retrieves constant authorization configuration (e.g., OAuth2 client_id, provider endpoints)
• Transient Authz Options Builder: Constructs dynamic authorization parameters (e.g., PKCE challenge, state parameter, nonce)

Tasks execute independently, following the Blackboard architectural pattern. This design enables:

• Loose coupling: Tasks don’t depend on each other directly
• Flexibility: Task execution order can be adjusted
• Reusability: Tasks can be shared across multiple Assemblies

Clean Architecture Principles

The implementation strictly adheres to Clean Architecture principles by organizing code into three distinct layers with unidirectional dependencies:

Domain Layer

Contains pure business logic with no external dependencies:

• Business entities (e.g., AuthorizationOptions, ConsentGrant)
• Value objects representing domain concepts
• Domain services implementing core business rules

The Domain layer has zero dependencies on infrastructure, frameworks, or external systems.

Application Layer

Contains application-specific business logic and workflow orchestration:

• Operations: Use case coordinators that define business capabilities
• Assemblies: Workflow implementations that orchestrate tasks
• Tasks: Granular work units with single responsibilities

The Application layer depends only on the Domain layer, ensuring business logic remains independent of infrastructure concerns.

Infrastructure Layer

Contains framework integration and external system interfaces:

• Servers: Web server configuration and routing
• Configuration: External configuration file loading
• API Handlers: HTTP request/response handling using the Axum framework

The Infrastructure layer depends on both the Application and Domain layers but is isolated from business logic. Changes to web frameworks, databases, or external services are confined to this layer.

Composition Root

A special component that wires all layers together through dependency injection:

• Dependency Injection: Inject Assemblies into Operations at application startup
• Factories: Create concrete Assembly implementations based on configuration
• AppState Creation: Compose the application state with fully-wired, ready-to-use Operations

The Composition Root is the only component that knows about concrete implementations, enabling true plug-and-play modularity throughout the system.

Benefits of This Architecture

The modular, layered architecture provides several key benefits:

1. Modularity: Each Operation, Assembly, and Task is an independent Rust crate that can be developed, tested, and deployed separately
2. Replaceability: Assemblies can be swapped without modifying Operations or other Assemblies, enabling A/B testing and gradual rollouts
3. Reusability: Tasks can be shared across multiple Assemblies, reducing code duplication and ensuring consistent behavior
4. Testability: Each layer can be tested in isolation with clean dependency boundaries and mock-friendly interfaces
5. Maintainability: Clear separation of concerns makes the codebase easier to understand, modify, and debug
6. Extensibility: New features can be added without modifying existing code, following the Open/Closed Principle

This architectural approach ensures the WoT system can evolve to meet changing requirements while maintaining stability, security, and code quality.

Conclusion

This demonstration illustrates Web of Trust’s approach to extending traditional OAuth2/OIDC protocols to support transparent, granular consent for autonomous agent data access. By introducing an Enhanced Consent Screen that discloses organizations, agents, data providers, and identity providers, WoT empowers users with the information needed to make informed authorization decisions.

The implementation showcases a production-ready architecture built on Clean Architecture principles, with clear separation between domain logic, application workflows, and infrastructure concerns. The modular design—with API Handlers relying on Operations, Operations coordinating Assemblies, and Assemblies orchestrating Tasks—ensures the system can evolve and scale while maintaining code quality and architectural integrity.

As the WoT system continues to develop, future enhancements will include cryptographic proof of consent, completion of the full authorization workflow including token exchange and validation, and integration with additional identity and data providers beyond Google. These additions will build upon the solid architectural foundation demonstrated here, reinforcing WoT’s role as a trusted intermediary for secure, transparent autonomous operations.