Compliance

GDPR Guide

How Aroha Protocol data maps to GDPR categories, and what your obligations are for each.

Legal disclaimer: This guide is informational only and does not constitute legal advice. Consult qualified legal counsel for your specific jurisdiction and use case.

TL;DR — Data Category Summary

Data type	Personal data?	Notes
Capability manifests	No	Describe what an agent can do — not who the user is
Verifiable credentials	Yes (potentially)	May contain name, email, DOB, or other PII — minimise fields
Saga logs	Yes (contextual)	Contain correlationId and agent DIDs; may link to natural persons
DID documents	Pseudonymous	did:aroha: keys are pseudonymous; did:aroha-web: may identify a person via domain
Reputation scores	Yes (contextual)	Beta(α,β) per agent DID — personal if DID is linkable to a natural person

Rule 1 — Minimise What You Put in Envelopes

The Aroha envelope body is end-to-end signed but not encrypted by default. Treat anything in the body as potentially visible to intermediary routers. Keep PII out of envelopes — pass a reference token instead and fetch PII via a separate authenticated channel.

// ❌ Don't do this — PII in the envelope body
{
  "type": "ArohaRequest",
  "body": {
    "capability": "book-hotel",
    "guestName": "Jane Smith",          // PII
    "guestEmail": "jane@example.com",   // PII
    "creditCard": "4111111111111111"    // PCI data
  }
}

// ✅ Do this — reference token, fetch PII server-side
{
  "type": "ArohaRequest",
  "body": {
    "capability": "book-hotel",
    "guestRef": "ref_01HV3KPQR9XY",    // opaque token
    "checkIn": "2026-07-01",
    "checkOut": "2026-07-05"
  }
}

Rule 2 — Saga Logs Are Subject to Right of Erasure

Saga logs contain correlationIds that may link to a natural person. If a user exercises their right to erasure (GDPR Art. 17), you must be able to pseudonymise or delete the linkable fields. The @aroha-sdk/audit package supports selective field encryption to facilitate this.

// Saga log entry — linkable fields in square brackets
{
  "sagaId": "[ref_01HV3KPQR9XY]",     // erase / pseudonymise on request
  "correlationId": "[corr_abc123]",    // erase / pseudonymise on request
  "step": "COMMITTED",
  "agentDid": "did:aroha:Abc123…",     // pseudonymous — generally keep
  "timestamp": "2026-03-01T12:00:00Z",
  "hash": "sha256:deadbeef…"           // chain integrity — keep
}

Rule 3 — Verifiable Credentials Require Consent or Contract

If your agent issues or verifies credentials containing PII (name, email, date of birth, etc.), you need a GDPR lawful basis. The most common bases in agent contexts are:

→Contractual necessity (Art. 6(1)(b)) — credential required to fulfil the service
→Legitimate interests (Art. 6(1)(f)) — fraud prevention, reputation scoring
→Consent (Art. 6(1)(a)) — user has actively opted in

// Verifiable credential with minimal PII — prefer this shape
{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "ArohaAgentCredential"],
  "issuer": "did:aroha-web:your-org.example.com",
  "credentialSubject": {
    "id": "did:aroha:AgentPublicKey…",
    // ✅ Capability claims — not personal data
    "tier": "tier-2",
    "capabilities": ["book-hotel", "pay-invoice"],
    // ⚠️  Only include PII if strictly necessary with a documented lawful basis
    // "operatorEmail": "ops@your-org.example.com"
  }
}

Rule 4 — Cross-Border Transfers

If your agent calls agents in other jurisdictions (e.g. US → EU), and those calls involve personal data, you need a transfer mechanism. The Aroha registry does not handle this automatically — it is your responsibility as data controller.

// Registry entry — declare your data residency policy
{
  "agentDid": "did:aroha-web:your-agent.example.com",
  "capabilities": ["book-hotel"],
  "dataResidency": {
    "regions": ["EU"],               // where data is processed
    "transferMechanisms": ["SCCs"],  // Standard Contractual Clauses
    "dpaContact": "dpa@your-org.example.com"
  }
}

Lawful Basis Quick Reference

Basis	Art.	When to use
Consent	6(1)(a)	User has freely given, specific, informed, unambiguous consent
Contractual necessity	6(1)(b)	Processing required to perform a contract with the data subject
Legal obligation	6(1)(c)	Processing required to comply with a legal obligation (e.g. AML)
Legitimate interests	6(1)(f)	Fraud prevention, security, reputation scoring — must pass balancing test

Resources

Back to Docs Financial Regulation