1Executive summary
TrustNet is an identity orchestration layer that separates authentication (verifying the person) from identity representation (the persona a service receives). It integrates over standard OpenID Connect, so a relying party adds one provider and stores no personal data.
- Reduced GDPR scope. The service holds a stable pseudonymous subject and its own business data — not PII.
- Protected PII. Identity data is envelope-encrypted before storage; lookups go through blind indexes; the correlation salt lives in a vault.
- Verifiable consent. Every consent, access, and revocation is written to an append-only, tamper-evident log — claim names, never values.
- eIDAS 2.0 path. Wallet credentials (SD-JWT) are translated into standard OIDC claims, so regulated sectors can accept EU wallets without refactoring.
2The compliance problem
2.1 PII liability and breach blast radius
Storing identity data makes every service a data controller with a wide breach surface. The safest data is the data you never held.
2.2 Consent that cannot be evidenced
Consent screens built per product rarely produce a durable, exportable record of what was approved, by whom, and when — the exact evidence a DPO is asked to produce.
2.3 Identity lifecycle burden
MFA, recovery, password reset, and email verification are costly to build, easy to get wrong, and undifferentiated across products.
3The TrustNet model
3.1 Separation of authentication and representation
One account authenticates the human; many personas are the projections presented to services. The account is the fact; the persona is the face.
3.2 Personas and pairwise subject identifiers
Each service receives a distinct subject (PPID) derived per persona and client. Two services cannot join records for the same human, so cross-service correlation is mathematically absent.
4Reduced GDPR scope
4.1 A pseudonymous key, not PII
Your service stores the pairwise subject, its permissions, and its own business data. Names, emails, birth dates, and phone numbers are never received.
4.2 TrustNet as a PII broker
When a rule needs a fact about the person, TrustNet verifies the underlying data and returns only the derived fact. The source value never crosses the boundary.
4.3 Derived verified claims
verified_phone— true, number withheldverified_address— true, address withheldverified_over_18— true, birth date withheldverified_human— true, no identity shared
4.4 Article 17 in practice
Because the service holds only a pairwise subject, an erasure or revocation propagates as a signed event and the service's copy becomes unlinkable — no identity data to hunt through its systems.
5Data security
5.1 Envelope encryption
Attribute values are encrypted with per-key envelope encryption before they reach the personas database. A database dump yields ciphertext, not identities.
5.2 Blind-index lookups
Lookup by value (find the account for this email) goes through an HMAC blind index, never a plaintext column. Equality lookups work; the value stays hidden.
5.3 Pairwise isolation and the vault-held salt
The salt that derives pairwise subjects lives only in the vault and never in code, config, tests, or logs. It is the single secret whose exposure could correlate personas.
6Verifiable consent audit
6.1 Append-only, tamper-evident
Consent and access events are append-only and Merkle-anchored. A signed tree head makes the log tamper-evident, and an audited erasure workflow is the only path that removes a record.
6.2 Claim names, never values
Logs record which claim names were approved or revoked
(e.g. email, dob) — never raw values. The
audit trail proves consent without becoming a second copy of the
data.
6.3 DPO exports
Consent history and audit records export as CSV or JSON-LD with timestamps, personas, clients, and versions, scoped to the requesting organization.
7Consent escalation
7.1 Additive re-consent
When a service needs a claim the user has not shared yet, TrustNet runs the escalation flow: the user sees exactly the new claim and its reason, approves or declines, and nothing already granted is re-asked.
7.2 Decline as a first-class outcome
A declined claim is returned as absent — never a partial leak. Consent stays per-claim and per-service and is recorded in the audit trail.
8eIDAS 2.0 readiness
8.1 EUDI Wallet / SD-JWT bridge
TrustNet ingests SD-JWT and wallet credentials and emits standard OIDC claims. Relying parties accept EU Digital Identity Wallets without changing their integration.
8.2 Timeline
- Member states issue wallets — mandate from late December 2026.
- Regulated sectors must accept them — by December 2027.
9Identity lifecycle & continuity
9.1 Stable subject across attribute changes
A user can change email or phone; the pairwise subject your service holds is unchanged, so no re-provisioning and no orphaned records.
9.2 Delegated MFA, recovery, and verification
TrustNet owns multi-factor authentication, password reset, account recovery, and email verification, removing that engineering and its failure modes from your roadmap.
10Integration
10.1 Standard OIDC discovery, no SDK
Point an existing OpenID Connect client at the issuer discovery document. There is no SDK and no custom protocol to learn.
10.2 Claim mapping
Request the claims your product needs; receive only those the user approved for this service, in standard OIDC claim shapes.
11Compliance mapping
Indicative mapping of TrustNet properties to GDPR obligations. This is an outline for a security review, not legal advice.
| GDPR | Obligation | How TrustNet helps |
|---|---|---|
| Art. 5 | Data minimisation & purpose limitation | Only approved claims per persona and service are projected. |
| Art. 6 / 7 | Lawful basis & consent | Per-claim, per-service consent recorded in the audit log. |
| Art. 17 | Right to erasure | Signed revocation/erasure events; the service's copy becomes unlinkable. |
| Art. 25 | Data protection by design | No PII at the relying party; encryption and isolation by construction. |
| Art. 30 | Records of processing | Append-only consent and access records, exportable. |
| Art. 32 | Security of processing | Envelope encryption, blind indexes, vault-held salt, pairwise subjects. |
12Honest limits & roadmap
12.1 What is production today
- RFC-compliant pairwise subject generation
- Standard OIDC discovery and token endpoints
- Append-only consent audit ledgers
- EU data residency (Frankfurt, Stockholm)
12.2 What is in development (2026–2027)
- eIDAS 2.0 SD-JWT wallet verification core
- Blind-signature blinded persona issuance
- Zero-knowledge selective-disclosure proofs
- Hardware-enclave cryptographic validation (HSM)
TrustNet does not claim zero-knowledge today. The production MVP isolates personas through pairwise derivation and schema segregation; the cryptography above is the next stage.
13Glossary
- Account — the one real login that authenticates the human.
- Persona — a named projection of account attributes presented to a service.
- PPID — the pairwise subject identifier derived per persona and client.
- Blind index — an HMAC of a value used for equality lookups without storing the value.
- Envelope encryption — encrypting data with a per-key data key, itself wrapped by a vault-held key.
14References
- OpenID Connect Core 1.0 — discovery, authorization code, claims.
- GDPR Articles 5, 6, 7, 17, 25, 30, 32.
- eIDAS 2.0 / EU Digital Identity Wallet — SD-JWT and OIDC4VP.
- TrustNet architecture: identity model, threat model, audit architecture.