Identity Orchestration over OpenID Connect

§Abstract

Every existing identity system — social login, enterprise SSO, a database table of users — authenticates a person and then hands the relying party one static profile. That single representation is the root of three problems research validated in parallel: users cannot compartmentalise their digital lives without manual, exhausting effort; organisations accumulate personal data they do not need and cannot defend; and the resulting identity providers become high-value honeypots.

TrustNet is an Identity Orchestration Layer. It separates authentication (proving which human is present) from identity representation (which person the human chooses to present). A user owns one account — the one real login — and projects many personas to services over standard OpenID Connect, disclosing on a per-service, per-claim basis exactly the attributes they approve. Relying parties integrate once, change no code, and store no personal data. The research verdict is that this is technically feasible today, commercially valuable to European SaaS, HealthTech, and FinTech, and behaviorally aligned with how users already think — provided TrustNet hardens against the one catastrophic risk its own centralisation creates: the persona-mapping honeypot.

1The problem

1.1 Identity is a single, static profile

A traditional Identity Provider (Okta, Auth0, Microsoft Entra, Keycloak — and even Google or Apple sign-in) models a user as one flat record. Auth0 stores a user as a JSON object with a single user id mapped to standard claims; its metadata fields are capped at 32 KB, and account linking discards the secondary account's metadata. When one human acts as a personal shopper, a business buyer, and a contractor in the same application, that multi-dimensional relationship is force-fit into a single profile. Granular consent is then handled with coarse OAuth scopes and progressive profiling, which works for simple B2C apps and fails for multi-persona ones: either the token bloats with every persona's permissions (violating least privilege and risking header-size limits) or the user is forced through a disruptive re-authentication to switch.

The architectural assumption is the obstacle: the directory, schema, and token pipeline of every incumbent are built around one immutable user record, and their business model is tenant-centric and monetised on monthly active users. That is the strategic moat — and the gap.

1.2 Compartmentalisation is natural, but manual

The research falsifies the idea that personas are a foreign concept. Users already compartmentalise, without the vocabulary:

• 86% of consumers maintain at least two active email addresses, with 28% managing four or more — a primary inbox for high-trust mail, a professional inbox, and a "burner" for sign-ups.
• 50–80% of youth and young adults maintain secondary social accounts ("Finstas") as a private counterweight to "context collapse" — the merging of family, classmates, and employers into one audience.

The behaviour is proven; the manual execution is the burden. Users log in and out of accounts, remember credentials, and navigate distinct interfaces, which produces "identity leakage" (posting to the wrong account) and consolidation fatigue, where privacy boundaries are abandoned for convenience. TrustNet's value is formalising and automating the pattern users already have — not teaching a new mental model.

1.3 Consent fatigue has made privacy dashboards a failed paradigm

Regulators mandated granular consent. Platforms answered with cookie banners and settings panels, and users disengaged:

• The average user sees 5–15 cookie banners per day — over 1,000 decisions a year; 85% exhibit clear consent fatigue.
• 96% of users blindly click "Accept All" or dismiss banners; only 0.4% ever open secondary settings to customise.
• 72% of consent implementations contain at least one dark pattern; making "Accept All" visually dominant raises acceptance by ~25%. When a clear, equally prominent "Reject All" is mandated, rejection rises to 45–55%.

The conclusion is decisive: users do value privacy, but only act on it when the UX is frictionless. The "configure a dashboard" model has failed; TrustNet must be an automated orchestrator that applies persona preferences in the background, and where it does ask, ask once and ask clearly.

1.4 The regulatory blast radius: GDPR versus AML/KYC

European FinTech and HealthTech sit at a hard regulatory intersection. AML/KYC obliges financial institutions to collect extensive personal data and retain it for 5–7 years; GDPR demands data minimisation and storage limitation. HealthTech adds Article 9 "special category" data and Know-Your-Patient verification. Under these conditions, storing a full user profile is a liability:

• Customer PII is the most frequently compromised data class, involved in 53% of breaches, at roughly $160 per record; employee PII ~$168.
• The average GDPR fine is €2.8 million, maximum €20 million or 4% of global turnover; a regulatory-failure "non-compliance premium" adds ~$190,000 to a breach.
• Biometric identifiers used for identification are special-category data: explicit consent is fragile, withdrawal must trigger an equally seamless non-biometric alternative, and erasure rights require carefully segmenting what must be kept (AML logs) from what must be deleted (marketing, behavioural, biometrics).

An organisation that never stores the identity attributes in the first place removes most of this exposure.

1.5 The "SSO tax" and the build trap

Identity is expensive in ways buyers resent. Auth0's self-serve B2B plans bundle only 3–5 enterprise connections; add-ons run ~$100–$125 per connection per month, and a scaling B2B SaaS with 50 enterprise customers crosses $5,000/month before MAU costs — forcing mid-market companies onto custom contracts of $30,000 to $60,000+/year (enterprise B2B contracts routinely start at $100,000/year). The alternative — building in-house — costs $500,000–$700,000 in Year 1 salary and 18–24 months of opportunity cost, then $150,000–$250,000/year to maintain. Integration alone adds $15,000–$40,000 in professional services or 200–400 developer hours.

A mid-market European B2B SaaS company is therefore choosing between an over-priced vendor and an over-priced build, both of which leave it holding PII it does not want.

1.6 The adversarial problem: the centralised honeypot

The research's red-team workstream surfaced the defining tension. The very property that makes TrustNet valuable — one place that knows a user's personas — makes it a target:

• Honeypot / de-anonymisation. A breach of the account⇄persona mapping table lets an attacker de-anonymise every "Anonymous" persona and link medical, political, or whistleblowing activity to a real identity. Precedent: the 2023 Okta support-system breach, where a single compromised credential cascaded to downstream customers via stolen session material.
• Cross-persona correlation via metadata. Colluding relying parties or a network observer can correlate personas without breaking crypto — key-set fetch timing, synchronised token-refresh clocks, shared IP/TCP reuse.
• Single point of failure. A central orchestrator outage locks the user out of all connected services; enterprise downtime runs ~$9,000–$15,000 per minute, and Gartner expects 30% of enterprises to adopt decentralised identity partly to remove such single points of failure.
• Consent-log tampering. The audit trail is itself a product; if it can be altered, it is a liability, not evidence.

Any credible TrustNet must treat these as first-class design constraints, not roadmap footnotes.

2The thesis

Current identity systems authenticate users but treat identity as a single, static profile. TrustNet adds an architectural layer — Identity Orchestration — that separates authentication from identity representation, letting individuals maintain multiple digital personas and dynamically control which verified attributes are disclosed to each relying party through existing OpenID Connect standards.

The research sought to answer three overarching questions. The rest of this document answers them against the product:

If all three hold, TrustNet is not another IdP but a new infrastructure category between authentication and applications: an Identity Orchestration Layer for privacy-preserving digital interactions.

3How TrustNet works

3.1 Vocabulary

The whole model rests on a strict separation of terms:

3.2 Architecture

TrustNet is built on the OpenID Connect and OAuth 2.0 standards, with a small number of clearly separated components:

State lives in three segregated databases with separate credentials. Attribute values and persona labels are envelope-encrypted, with blind indexes for lookup-by-value; the PPID salt lives only in a dedicated secrets store, and derivation happens only in the orchestration core. Every relying party is registered with pairwise subjects and opaque access tokens — a non-pairwise registration would silently defeat the forced pseudonymous subject and expose the underlying account identifier.

3.3 One login, many personas

At registration a user gets one account and — once onboarding completes — a single auto-created persona named "Persona" carrying the verified email and alias. There is no pre-defined persona set (no "Professional", "Personal", "Anonymous" templates); personas are user-created thereafter. This is deliberate: templates would impose a taxonomy the research says users should discover at the consent screen, not learn upfront.

Personas own only non-attribute data — name, colour/icon, avatar, description, and the RP-facing "about" text. Every claimable value is a reference to the account-level pool, so a work email and a personal email can back different personas, and changing a pool value propagates to every persona and every RP that shares it, without changing any RP-facing subject. A persona's internal key is immutable by design and enforced in the database.

3.4 The consent moment

OIDC already has the mechanism the product needs, and it is under-used: the claims request parameter, plus scope-to-claim mapping for legacy RPs. A TrustNet login parses the requested claims from the authorisation request, maps them to the active persona's pool entries, and renders one screen that combines a persona picker with a two-list disclosure: what will be shared (with live value previews) and what will not be shared. The "not shared" list is the differentiator against every "Sign in with Google" screen and is never cut.

The claim pipeline is explicit:

requested claims ∩ registered claims → consent claims → approved claims → granted claims

To integrate, an RP points its existing OIDC client at TrustNet's discovery endpoint and changes no code. It receives standard tokens, verifies signatures against standard key discovery, and reads standard claims. The RP sees only the claims the user approved, and only a persona-specific subject.

Two refinements matter:

• Fast path. A remembered decision for an (account, RP, persona) combination renders a non-interactive access-proof window showing the persona and granted claims, auto-continuing after 1000 ms and interruptible via Esc / "Not you?". An explicit consent prompt always forces full review. This is what makes daily use one-click without becoming a dark pattern.
• Claim completion. When a requested claim cannot be projected from the chosen persona, the user supplies it before review — it is written once to the account pool and bound to the persona. Saving is not consenting; full review still runs, and a claim may be skipped. An RP can never silently expand what it receives: a growth in the RP's registered claims re-opens full review with a "New request" badge, and a per-transaction request for a claim the RP never registered is rejected as an invalid request.

3.5 Persona switching

One account authentication serves many personas. prompt=select_account semantics are implemented by TrustNet: when there is a genuine choice, the picker runs; when there is exactly one persona, or a remembered prior choice for that RP, the picker is skipped and the user lands directly on consent. Switching a persona for an RP that already has a session never silently swaps claims under the RP — the protocol layer's front- and back-channel logout notifies the RP, which re-fetches the new persona's claims. To fight context blindness, the UI uses colour-coded persona themes, a persistent context badge during the authorisation flow, and confirmation toasts.

3.6 The control moment and the kill switch

The dashboard answers who has access to what, and what can I take back. Each connection shows the projected persona, the attribute count, an "edit sharing" action, and a first-class, always-visible Revoke. Revocation is a single orchestrated operation with load-bearing ordering:

1. headless logout of the login session, so the protocol layer still knows whom to notify;
2. deletion of the consent sessions — refresh tokens die immediately (introspection flips to inactive in roughly a quarter of a second, measured);
3. a signed, RP-bound purge webhook written in the same transaction as the audit events and delivered with bounded retry/backoff — GDPR Article 17 automation;
4. an append-only audit record.

This is the "right-to-be-forgotten kill switch": the user revokes, the RP loses access immediately, and the RP is told to purge.

3.7 The audit and consent trail: compliance as a service

The audit trail is a product feature, not an internal log. It is a per-RP transparency log built on the Certificate Transparency Merkle construction (hash-chained, append-only), with a daily externally timestamped meta-root, plus a time-sharded tree family for authentication events.

Its design choices are direct answers to the research:

• Tamper-evidence — append-only storage, hash-chained entries, a signed tree head on every change, and an external RFC 3161 timestamp.
• Erasure-compatibility — hashed payloads carry claim names only, never values. Internal correlation identifiers live in a separate, erasable metadata store, so erasure under Article 17 removes descriptive metadata while the PII-free proof survives.
• Exportability — an RP downloads a self-contained, offline-verifiable audit bundle from the portal or a machine interface and verifies it with an offline verifier: manifest signature, per-file digests, recomputed range root against the signed tree head, anchor inclusion, consistency bridge, and the per-RP lifecycle obligations. A valid verdict answers the canonical auditor question without calling TrustNet.
• Per-user export — Article 15/20 access and portability through a dedicated export endpoint.

The RP stores only a pairwise subject, permissions, and its own business data — the zero-PII architecture that breaks the GDPR blast radius. Per-claim justification is declared by the RP and displayed per claim at consent, satisfying the purpose-limitation requirement in the UI itself.

3.8 RP onboarding and the registry

An RP operator is an ordinary TrustNet account. Self-service registration is instant: the operator supplies identity, protocol, and consent-surface metadata, proves ownership of each production redirect host at the registrable domain (DNS TXT preferred, a well-known HTTPS file as fallback), and receives a one-time client secret. The protocol registration and the TrustNet registry record are kept in lockstep. An account may own up to 5 tenants, 5 production RPs, and 5 development RPs; a lapsed host proof suspends the RP fail-closed. The lifecycle is active → suspended → active, active/suspended → deleted (global teardown of every live consent), and deleted → purged at the retention horizon — the RP's audit tree is never deleted.

4How TrustNet answers the research

4.1 Technical feasibility

The research found the core premise feasible, and the current implementation proves it: the standard OIDC claims request parameter, scope-to-claim mapping, and Persona-Specific Pairwise Subject Identifiers deliver persona projection with zero relying-party changes. The subject is computed as Hash(sector + persona + salt) and forced at the protocol layer; because the sector is per-RP and the persona identifier is per-persona, the same physical user presents different, mathematically uncorrelatable subjects to different RPs and different personas. Stability is preserved per (persona, RP), so an RP's local account survives attribute changes.

The research also mapped the growth path: Rich Authorization Requests for transaction-specific consent, OpenID Federation for multi-tenant trust establishment, identity projection so raw tokens never pass deep into microservices, and self-issued identity / verifiable presentations so a user's wallet can act as a local identity provider. These are roadmap items, not prerequisites — the current product already delivers zero-code persona orchestration.

4.2 Commercial viability

The research validated a large, growing market: global customer identity and access management at roughly $12.5–19.7B (2024/25) growing to about $21–26B by 2030, and compliance-as-a-service between roughly $7.2B and $15.35B. Crucially, it identified why organisations would outsource orchestration: the GDPR-versus-AML/KYC clash, consent management, PII minimisation, and the SSO tax. TrustNet's answer is Compliance as a Service: zero-PII RP storage, standardised consent, and offline-verifiable audit exports that cut audit preparation and demonstrate accountability.

The target segments follow directly: Tier 1 European SaaS (GDPR pain, low engineering capacity), HealthTech (special-category data), FinTech (KYC/AML tension), and HR platforms (professional identity); Tier 2 universities, associations, marketplaces, B2B portals; Tier 3 government and large enterprise (long cycles). The buyer conversation has two gatekeepers the research names explicitly — the CTO ("we can build this") answered with total cost of ownership and opportunity cost, and the DPO ("where is our data?") answered with EU hosting, zero-PII RP storage, and programmatic erasure.

4.3 Behavioral fit

The product is designed to the behavioral findings rather than against them: it formalises the multiple-inbox / "Finsta" behaviour (§1.2), rejects the failed dashboard model in favour of automation and one-click flows (§1.3), and captures the trust premium that Big Tech SSO leaves unmet — Google holds 73–75% of social logins but only 34–41% trust, and 81% of consumers say privacy practices affect purchasing. The strongest proof of appetite is Apple's "Hide My Email": 19.3–33% of sign-ups use a relay address when offered a one-click shield. TrustNet is that shield, but persona-aware, neutral, and advertising-free.

4.4 Regulatory alignment

The design maps directly to the instruments the research flagged:

A known regulatory gap is delegated authority — proving not just who a person is but what they are allowed to do on another's behalf (electronic attestations of attributes, the European Business Wallet), especially for autonomous agents. TrustNet's architecture is positioned to carry the credentials, but the authority model is a live area of EU law and is treated as an open question, not a shipped feature.

4.5 Competitive positioning

The strategic moat is architectural and philosophical: the incumbents' data models, integrations, and usage-based monetisation cut against data minimisation and user-controlled separation of concerns.

4.6 Adversarial hardening

The research's most important finding is that TrustNet's strength is also its catastrophic risk. The current mitigations:

• Honeypot / de-anonymisation: pseudonymous subjects everywhere; derivation and the salt isolated to the orchestration core and secrets store; three segregated databases with separate credentials; the mapping table access-controlled on its own; envelope encryption with blind indexes; minimal account data; and a hard rule that claim values never appear in logs.
• Metadata correlation: jittered token lifetimes and refresh schedules per persona-RP pair, aggressive key caching, and no token timing derived from the account session clock; shared-IP risk documented honestly.
• Availability: multi-region EU deployment, DDoS protection, a status page, and generous token lifetimes for low-risk RPs.
• Audit tampering: append-only Merkle log, hash-chained entries, signed tree heads, and external timestamping.

The roadmap is the zero-knowledge trust architecture the red team demanded: blind signatures, zero-knowledge proofs with anonymous credentials, blind issuance compatible with OIDC, and local credential storage — so that even a fully compromised TrustNet cannot link personas to humans, and credentials can be verified without a live call to TrustNet (removing the availability single point of failure). Pseudonymous subjects and database segregation are the honest, shippable first step toward that guarantee.

5Research findings as evidence

The figures below are from the research dossier and are included to show the basis of the thesis, not as TrustNet measurements. Where sources disagreed, the range is given.

6What is built versus what is roadmap

The product is functionally complete; what remains on the critical path is hardening and deployment readiness.

Shipped and verified

• Registration, onboarding, and multi-persona management.
• The login and consent experience: persona picker and selective claim disclosure, prompt=select_account / prompt=consent semantics, the remembered-decision fast path and access proof.
• Persona-specific pairwise subject derivation and per-RP unlinkability.
• Claim completion for unprojectable claims.
• Per-RP revoke kill switch with immediate token death and a signed purge webhook.
• The self-service RP registry and portal: registration, host-ownership verification, tenant model, secret reissue, and suspend / reinstate / delete teardown.
• The audit trail: Merkle log with signed tree heads and anchoring, a durable disclosure-read pipeline, the authentication-event domain, per-RP offline-verifiable export, per-user export, the offline verifier, and the audit-key endpoint.
• Per-claim GDPR justification declarations and their consent-screen rendering.
• External identity-provider linking (Google, GitHub, LinkedIn, Facebook).

Roadmap

• Zero-knowledge trust architecture: blind signatures, zero-knowledge proofs, blind issuance, and local credential storage.
• eIDAS 2.0 / EUDI Wallet bridge, including selective-disclosure format translation to plain OIDC claims.
• Rich Authorization Requests and OpenID Federation.
• The per-RP erasure-request relay (account-level erasure is built).
• Delegated authority and delegation tokens (the EU "authority gap").
• Tenant sector mode; qualified timestamp selection; phone and multiple-contact support.

Deployment readiness

• The operations layer: deployment automation, origin and reverse-proxy routing, and production configuration parity.

7Go-to-market implications

The research's go-to-market conclusion maps cleanly onto the shipped surfaces:

1. Target mid-market European B2B SaaS in FinTech and HealthTech first (50–500 employees) — highest regulatory pressure, highest willingness to pay.
2. Lead with compliance, not convenience. The pitch is "your database never holds PII; here is an offline-verifiable audit export" — the RP portal and the offline verifier make that demonstrable in a demo.
3. Position as the pragmatic bridge to eIDAS 2.0, not a competitor to the EUDI Wallet: the layer that turns selective-disclosure presentations into plain OIDC claims.
4. Defuse the two predicted objections — the CTO (total cost of ownership versus a $500K+ build) and the DPO (EU hosting, zero-PII, programmatic erasure) — with the product's own evidence surfaces.
5. Be honest about the honeypot. For security-conscious buyers, the zero-knowledge roadmap is a differentiator, not a caveat: the plan is a trustless orchestrator.

The investor-ready demo is a five-step flow: create two personas, log into two test services, decode the two tokens to show different subjects, export an RP's immutable consent log, then revoke and watch access die.

8Risks, limits, and open questions

The whitepaper would be dishonest without them:

• The honeypot is mitigated, not eliminated. Until the zero-knowledge roadmap ships, a fully compromised TrustNet can still link personas. Pseudonymous subjects and segregation raise the cost and contain the blast radius; they do not make the central mapping table harmless.
• Availability is a shared fate. With standard OIDC, verification requires a live call; TrustNet becomes a high-value single point of failure for its users until decentralised verification is built.
• Correlation side-channels are partly outside TrustNet's control — shared IP, browser fingerprinting, and TCP reuse are documented residual risks.
• Delegated authority is legally unsettled in the EU, and autonomous-agent delegation has no workable legal identity today.
• Several decisions remain open, including terminal deployment readiness; they are acknowledged here rather than closed.

9Conclusion

The research validated the TrustNet thesis on all three axes and identified its single existential condition. Technically, identity orchestration over standard OIDC is feasible and is already built — personas project as standard claims, pairwise subjects make them uncorrelatable, and relying parties change no code. Commercially, the zero-PII architecture and offline-verifiable consent trail answer a real, expensive, and regulated pain for European FinTech, HealthTech, and SaaS, at a fraction of the SSO tax or an in-house build. Behaviorally, users already compartmentalise and are desperate for a frictionless way to do it; the product must automate, not ask.

The condition is security: TrustNet's centrality must be made trustless. The shipped pseudonymous subjects, database segregation, envelope encryption, and Merkle audit log are the credible first architecture; blind signatures and zero-knowledge proofs are the roadmap to the promise. If both hold, TrustNet is not another Identity Provider — it is the Identity Orchestration Layer between authentication and applications, and the only identity provider whose users can prove they were never over-identified.

AUse-case coverage

BStandards and regulations referenced

• OpenID Connect Core 1.0; OAuth 2.0 (RFC 6749)
• PKCE (RFC 7636); OAuth 2.0 for Native Apps (RFC 8252)
• Rich Authorization Requests (RFC 9396)
• JSON Web Token, Signature, and Key standards (RFC 7515/7517/7519)
• Certificate Transparency and Merkle hashing (RFC 9162, RFC 6962)
• JSON Canonicalization Scheme (RFC 8785)
• Internet X.509 Public Key Infrastructure Time-Stamp Protocol (RFC 3161); ETSI EN 319 421/422
• General Data Protection Regulation (EU 2016/679); eIDAS 2.0 (EU 2024/1183); NIS2; PSD2 and its successor PSD3/PSR
• OpenID for Verifiable Presentations and Self-Issued OpenID Provider v2 (roadmap)

§Glossary