Rights Layer Specification

Privacy Considerations

Status: Draft v0.1.0 — This section is informative except where RFC 2119 keywords are used.

Rights Layer expressions can contain personal data. A Subject is often a natural person; a Right can reveal what a person is entitled to do; and the append-only Event history of Exercises is, for a natural person, a behavioral history. This document discusses the privacy properties of the model and the obligations that fall on deployments. As everywhere in this specification, no technology is mandated (Principle P1 in Core Principles); deployments choose mechanisms appropriate to their obligations.

1. Where Personal Data Appears

• Subject. id identifies the holder; the optional name is directly identifying for natural persons.
• Rights themselves. That a Subject holds a given Right (a medical qualification, an insurance policy, a driving licence) is personal data about that Subject.
• Events and Exercises. ExerciseRequested, EligibilityResponseIssued, DecisionEstablished, ExerciseStarted, and ExerciseEnded Events, with occurredAt and actorRef, together form an exercise history — a behavior trail. This is typically the most sensitive data in the model.
• Eligibility Responses. A Response’s Boolean value is a statement about whether the Subject satisfies a requirement; a false value in particular can reveal sensitive facts about a person. The issuerRef and the Response’s proof can themselves identify natural persons where the issuer is one. Responses and issuer identifiers may therefore be personal data in their own right.
• Evidence. Evidence and its Proof References can point at records that are themselves sensitive.

2. Data Minimization

The model is built around references rather than copies (Principle P2), and deployments should use that property deliberately:

• Expressions SHOULD carry references, not personal attributes. The facts behind an Eligibility (age, health status, examination results) belong in the Evidence Source, reached by reference — not restated inline in the expression.
• The Subject name property is optional and SHOULD be omitted where the identifier suffices. The same applies to any optional human-readable property (description, reason) when it would carry personal data that the consuming purpose does not need.
• Producers SHOULD emit the minimal expression sufficient for the consuming purpose: the Rights, Actions, and Events the consumer actually needs, not the Subject’s full portfolio.

3. Purpose Limitation

An expression produced for one purpose (say, verifying eligibility to drive) can technically serve many others (profiling the Subject’s movements from Exercise Events). Rights Layer cannot prevent this — it is a descriptive layer — so purpose limitation is a deployment obligation:

• Deployments SHOULD bind the exchange of expressions to declared purposes in their own agreements and rules, and SHOULD scope what they emit to those purposes (see minimization above).
• The core model deliberately carries no purpose, session, or environment container (there is no Context in the core). Where a deployment records purposes — of an exchange, or of an exercise — it does so in its own systems or in profile extensions, and such a record is not a purpose-limitation mechanism for the data. Deployments should not confuse the two.

4. Event Histories Are Sensitive

Because Events are append-only and explain the present (Principle P6), a Right’s history accumulates indefinitely by design. For natural persons this means an ever-growing behavior trail.

• Access control over Event histories is a deployment obligation. Deployments MUST NOT treat the readability of a Right as implying the readability of its full Event history; these SHOULD be separately controllable.
• Retention is a deployment obligation. Append-only semantics constrain modification within a maintained history; they do not oblige anyone to retain expressions forever or to distribute histories in full. Deployments SHOULD define retention periods for expressions they hold, consistent with their legal obligations.
• Consumers SHOULD request Events scoped to what they need (for example, by aboutRef and since) rather than whole histories.

5. Pseudonymous Identifiers

Rights Layer is identifier-scheme-neutral (Data Model, section 1.1): any URI scheme may be used, and none is privileged. Pseudonymous identifiers are therefore fully compatible with the model:

• A deployment MAY identify Subjects by pseudonymous, purpose-specific, or pairwise identifiers, resolving them to real entities only within the system that needs to (identifier binding is a deployment matter — see Security Considerations, section 3).
• Deployments handling natural persons SHOULD prefer identifiers that do not themselves embed personal data.

6. Erasure and Append-Only Events

Many jurisdictions grant natural persons a right to erasure of personal data. This is in tension with append-only Events (a recorded Event MUST NOT be modified or deleted; Data Model, section 3.13). Guidance:

• Personal data SHOULD live behind references, in the referenced systems of record — so that erasure, where owed, happens in the referenced system, under that system’s rules. An Event whose actorRef is an identifier, and whose substance is a reference, survives as a structural fact even after the referenced personal data is erased or the identifier binding is severed.
• Expressions SHOULD carry the minimum inline personal data (section 2), so that there is as little as possible in the expression to erase.
• Where inline personal data was nonetheless recorded and must be erased, the deployment faces a genuine conflict between its legal obligations and the append-only conformance rule. Rights Layer does not resolve legal obligations; a deployment in this position should recognize that removing the data takes the affected history outside strict conformance, and should design its expressions from the start so the situation does not arise.

7. Aggregation and Linkage Across Domains

A common expression layer lowers the cost of correlating a person’s rights across domains — that is partly its purpose, and it is also its principal privacy risk. A directory that aggregates a person’s driving licence, medical qualification, insurance policies, and shareholdings, each with exercise histories, is a profile of unprecedented breadth.

• Rights Layer does not require any cross-domain correlation, any shared identifier across domains, or any aggregation topology (Architecture, section 2). The fully decentralized and point-to-point topologies exist precisely so that deployments can avoid central aggregation.
• Deployments and policy makers MUST weigh linkage risk when choosing topologies and identifier schemes: a single identifier reused across domains makes linkage trivial; per-domain pseudonymous identifiers make it deliberate.
• Aggregators, where they exist, SHOULD treat linkage itself — not only disclosure — as a regulated act under their governing rules.

8. Jurisdictional Compliance

Compliance with jurisdiction-specific privacy and data-protection law is out of scope of this specification, but it is flagged deliberately: almost every deployment handling natural persons will be subject to such law, and the obligations above (minimization, purpose limitation, access control, retention, erasure) are where that law will bite. Deployments are responsible for their own legal analysis in every jurisdiction they touch.

9. Summary of Deployment Obligations

Concern	Obligation
Inline personal data	Express references, not attributes; omit name where the identifier suffices
Purpose limitation	Bind exchanges to declared purposes; scope what is emitted
Event histories	Control access separately; define retention; scope retrieval
Identifiers	Pseudonymous identifiers are compatible; prefer non-identifying schemes for persons
Erasure	Keep personal data behind references so erasure happens in the referenced system
Linkage	Weigh aggregation topology and identifier reuse; no correlation is required by this specification
Privacy law	Out of scope here; the deployment’s own obligation everywhere

This site is open source. Improve this page.