Phase 2: Publish to Privacy Network

Outcome: Publishing captured consents enables Personal Privacy Networks (PPNs) to be created and is how publishers receive credit for participation in the Privacy Network Exchange.

Phase 2: Publish to Privacy Network

Prerequisites for Publishing

Before deploying Phase 2 infrastructure, ensure you have:

Application Requirements:

Completed Phase 1 - EasyAccess consent language in your consent flow
OIDC provider - User authentication system that issues OpenID Connect tokens
Consent data access - Ability to read collected consent data from your storage (for out-of-band processing)

Infrastructure Requirements:

Docker host environment - Capability to run and orchestrate Docker containers
S3-compatible object storage - Storage backend for Delta tables (AWS S3, MinIO, etc.)
Network access - Ability to deploy HTTP APIs (internal network or API gateway)
Cryptographic key management - Capability to generate, store, and rotate signing keys securely

Technical Knowledge:

Docker deployment - Experience deploying and managing containerized applications
Async consent publishing - Ability to build a background process that reads consent data from your storage and calls the EA Consent APIs. This decoupled approach is strongly recommended:
- Your application flow doesn’t depend on EA Consent Issuer availability
- No latency impact on user-facing consent capture
- Failures in consent publishing don’t affect your main application
Basic familiarity with Delta Sharing - Understanding of what Delta Sharing enables (detailed protocol knowledge not required)

Helpful but not required:

Verifiable Credentials / JWT - The APIs abstract these details, but understanding helps with troubleshooting

If you’re missing any prerequisites, contact your WebShield representative for Slack access and to discuss your integration path.

DevOps Setup

This phase involves deploying the three Docker components that form your Privacy Network infrastructure. These components run in your environment with partner-controlled signing keys.

Overview of Components

You’ll deploy these three components:

EA Consent Issuer - Mints EA Consent VCs and wraps them in Trust Blocks
EA Consent Delta Writer - Transforms Trust Blocks into Delta tables
Delta Sharing Server - Serves Delta tables to Privacy Network participants

Integration Architecture

1. Your Application (Phase 1 - already done)
   └─> Captures user consent (your text + EasyAccess language)
   └─> Stores consent data to your database/storage

--- Phase 2 components below ---

2. Background Process (Recommended)
   └─> Reads stored consent data
   └─> Calls EA Consent Issuer and Delta Writer APIs
   └─> Decoupled from main app: no latency/availability impact

3. EA Consent Issuer
   └─> Mints EA Consent VC, wraps in Trust Block (JWT)
   └─> Exposes verification keys endpoint (setup + rotation)

4. EA Consent Delta Writer
   └─> Receives Trust Block JWT
   └─> Decodes, validates, transforms to Delta Sharing schema
   └─> Writes to: ea-consent-tb, ea-consent-verification-keys
   └─> Also accepts verification keys directly (setup + rotation)

5. Delta Sharing Server (Externally Accessible)
   └─> Serves Delta tables via Delta Sharing protocol
   └─> Authorized consumers query and verify signatures

Recommended: Run consent publishing as a background process, decoupled from your main application. This avoids latency, availability, and failure-mode coupling.

Access Model

Component	Access
EA Consent Issuer	Internal-only (runs in partner environment)
EA Consent Delta Writer	Internal-only (runs in partner environment)
Delta Sharing Server	Externally accessible to authorized Privacy Network participants

Component Versions

Current Release: This documentation covers EA Consent Issuer 1.0.x and EA Consent Delta Writer 1.0.x.

Component	Version	Docker Image
EA Consent Issuer	1.0.x	`webshield/ea-consent-issuer:1.0`
EA Consent Delta Writer	1.0.x	`webshield/ea-consent-delta-writer:1.0`
Delta Sharing Server	0.7.8	`deltaio/delta-sharing-server:0.7.8`

The EA Consent Issuer provides an HTTP API for your application to submit user consent and receive signed Verifiable Credentials wrapped in Trust Blocks.

What it does:

Accepts simplified consent JSON from your application
Validates consent data against schema
Generates cryptographically signed EA Consent VCs
Wraps VCs in Trust Block JWTs
Returns Trust Blocks to your application

Deploy it:

See EA Consent Issuer - Operations Guide for complete deployment instructions including:

Docker image and configuration
Signing key generation and management
Environment variables and secrets
Health check endpoints
Security considerations

The EA Consent Delta Writer receives Trust Blocks and writes them to Delta tables for Privacy Network sharing.

What it does:

Receives Trust Block JWTs via HTTP API
Decodes and validates Trust Block structure
Extracts EA Consent VC data
Writes to two Delta tables: ea-consent-tb, ea-consent-verification-keys
Provides statistics and health monitoring

Deploy it:

See EA Consent Delta Writer - Operations Guide for complete deployment instructions including:

Docker image and configuration
S3 storage configuration for Delta tables
Delta table initialization
Health monitoring setup
Troubleshooting common deployment issues

The Delta Sharing Server publishes your EA Consent Delta tables to authorized Privacy Network participants.

What it does:

Serves Delta tables via the Delta Sharing protocol
Manages access control for authorized consumers
Provides query capabilities over shared consent data

Deploy it:

See the Delta Sharing Server Docker image and Delta Sharing documentation for:

Docker deployment
Share configuration files
S3 credential setup
Recipient authorization

Step 4: Verify Deployment

Confirm all three components are running and healthy:

EA Consent Issuer health check:

curl http://localhost:8081/health
# Expected: {"status":"healthy"}

EA Consent Delta Writer health check:

curl http://localhost:8081/health
# Expected: {"status":"healthy"}

Delta Sharing Server:

# Verify container is running
docker ps | grep delta-sharing

See component operations guides for detailed health monitoring and troubleshooting.

Developer Integration: Consents

Once infrastructure is deployed, build a background process to submit stored consents and receive Verifiable Credentials.

Prerequisite: Before submitting consents, ensure verification keys have been uploaded to the Delta Writer. See Developer Integration: Verification Keys below.

Call the EA Consent Issuer API to mint a Verifiable Credential for the user’s consent.

API Request:

curl -X POST "http://localhost:8080/ea-consent-issuer/api/v2/consents" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your-token-here>" \
  -d '{
    "subject": {
      "id": "user-123"
    },
    "consent": {
      "agreed": true,
      "summary_html": "I agree to the privacy policy",
      "details_html": "<p>I agree to the privacy policy and terms of service.</p>",
      "contains_ppn_consent": true
    },
    "evidence": [
      {
        "type": "OpenIDTokenEvidence",
        "token": "header.payload.signature",
        "verifies": []
      }
    ]
  }'

What happens:

Submit consent data to EA Consent Issuer
Issuer validates and generates W3C Verifiable Credential
VC is signed and wrapped in Trust Block JWT
Receive Trust Block JWT in response

API details:

See EA Consent Issuer - Developer Guide for:

Section 3: Complete API reference and endpoints
Section 4: Request payload schema and validation rules
Section 7: Error handling and response codes
Authentication requirements and headers

Response handling:

Success (200): Receive Trust Block JWT containing signed consent VC
Error (400): Invalid payload - check schema validation
Error (401): Authentication failure - verify credentials
Error (500): Server error - check health endpoints

Submit the Trust Block JWT (from Step 1) to the EA Consent Delta Writer to persist consent to Delta tables.

API Request:

curl -X POST "http://localhost:8080/ea-consent-delta-writer/api/v1/trust-block-batches" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your-token-here>" \
  -d '{
    "trust_blocks": [
      {
        "client_reference_id": "test-consent-001",
        "trust_block": "<trust-block-jwt-from-step-1>"
      }
    ]
  }'

What happens:

Submit Trust Block JWT to Delta Writer
Delta Writer decodes and validates Trust Block structure
Extracts consent data and writes to two Delta tables:
- ea-consent-tb - Full verifiable payload for consent discovery, retrieval, and verification
- ea-consent-verification-keys - Public keys for signature verification

API details:

See EA Consent Delta Writer - Developer Guide for:

Section 3: Complete API reference and endpoints
Section 4: Request format for Trust Block submission
Section 7: Error handling and response codes
Trust Block validation requirements

Response handling:

Success (200): Trust Block persisted to Delta tables
Error (400): Invalid Trust Block format
Error (401): Authentication failure
Error (500): Server error - check Delta Writer health

Query the Delta Share endpoint to confirm your consent was successfully persisted and is accessible via the Privacy Network.

What to verify:

Query Delta tables via Delta Sharing protocol
Confirm consent appears in ea-consent-tb table
Verify consent data matches what you submitted
Validates end-to-end integration flow

Query Delta tables:

Use Delta Sharing client to query your consent data:

Connect to Delta Sharing Server endpoint
Query ea-consent-tb table for your consent records
Verify consent ID, issuer, and subject identifiers match

Delta Sharing details:

Delta Sharing Protocol Documentation
Delta Sharing Server configuration in your deployment

Testing checklist:

Submit test consent → verify Trust Block received (Step 1)
Verify Trust Block persisted (Step 2)
Query Delta Share endpoint → confirm consent appears (Step 3)
Test error scenarios (invalid payload, auth failures)
Verify Trust Block signature integrity

Developer Integration: Verification Keys

Verification keys are the public keys used to validate cryptographic signatures on Trust Blocks and EA Consents.

Verification keys must be shared before publishing consents, so that downstream consumers can verify their signatures via Delta Sharing.

The EA Consent Issuer exposes an API to retrieve these keys, while the EA Consent Delta Writer provides an API to write them into the ea-consent-verification-keys Delta table. Once written, they are distributed via the Delta Sharing Server.

The EA Consent Issuer domain is configured to match the Delta Sharing Server domain — for example: https://sandbox.delta-sharing.ea.webshield.io. This ensures the system can verify that the keys obtained via the Delta Sharing Server belong to that issuer, and that the corresponding EA Consents and Trust Blocks were minted by the same trusted issuer.

Trust Chain Flow:

Issuer (generates keys) → Delta Writer (stores & validates) → Consumers (verify data)

Step 1: Fetch Verification Keys from Issuer

Retrieve the current public verification keys from the EA Consent Issuer. These keys are used to verify the digital signatures on Trust Blocks and EA Consents.

API Request:

curl "http://localhost:8080/ea-consent-issuer/api/v2/verification-keys"

Response includes:

issuer - Issuer URL (matches Delta Sharing Server domain)
issuer_name - Human-readable issuer name
keys - Array of JWK objects with public keys

API details:

See EA Consent Issuer - Developer Guide Section 3 for complete endpoint documentation.

Step 2: Publish Verification Keys to Delta Schema

Upload the fetched verification keys to the Delta Writer, enabling consumers to verify the digital signatures on Trust Blocks and EA Consents during data ingestion.

By design: The response from Step 1 is the exact JSON payload for Step 2 — no transformation required. Simply POST the Issuer response directly to the Delta Writer.

API Request:

curl -X POST "http://localhost:8080/ea-consent-delta-writer/api/v1/verification-key-batches" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your-token-here>" \
  -d '{
    "issuer": "https://sandbox.delta-sharing.ea.webshield.io",
    "keys": [
      {
        "kty": "EC",
        "kid": "consent-key-2025-11",
        "use": "sig",
        "alg": "ES256",
        "x": "...",
        "y": "..."
      }
    ]
  }'

API details:

See EA Consent Delta Writer - Developer Guide Section 4 for verification key batch request schema.

When to Repeat

Perform these steps:

Initial setup - Before publishing any consents
Key rotation - Whenever signing keys are rotated

Trust Infrastructure Status

Before publishing consents, verify:

Keys Fetched: Yes
Keys Published: Yes (required)
Trust Chain: Complete

Next Steps

Deep-Dive Component Documentation

EA Consent Issuer - Developer Guide - Complete API reference, schemas, and integration examples
EA Consent Issuer - Operations Guide - Deployment, configuration, monitoring
EA Consent Delta Writer - Developer Guide - Trust Block ingestion API and Delta table schemas
EA Consent Delta Writer - Operations Guide - Deployment, Delta table setup, troubleshooting

Support

Need help with your integration?

Slack (for partners): Contact your WebShield representative for access

Last Updated: 2026-01-29 22:23:30 UTC

Phase 2: Publish to Privacy Network

Table of Contents

Prerequisites for Publishing

DevOps Setup

Overview of Components

Integration Architecture

Access Model

Component Versions

Step 1: Deploy EA Consent Issuer

Step 2: Deploy EA Consent Delta Writer

Step 3: Deploy Delta Sharing Server

Step 4: Verify Deployment

Developer Integration: Consents

Step 1: Submit Consent to EA Consent Issuer API

Step 2: Submit Trust Block to EA Consent Delta Writer API

Step 3: Verify via Delta Sharing Query

Developer Integration: Verification Keys

Step 1: Fetch Verification Keys from Issuer

Step 2: Publish Verification Keys to Delta Schema

When to Repeat

Trust Infrastructure Status

Next Steps

Deep-Dive Component Documentation

Support