Rights Layer Specification

Security Considerations

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

Rights Layer is descriptive, not enforcing (Principle P7 in Core Principles): it does not authenticate Subjects, authorize requests, or enforce Decisions. It is also technology-neutral (Principle P1): no security technology is mandated anywhere in this specification. What follows is a threat-model-style discussion for anyone exchanging Rights Layer expressions, identifying the risks that deployments MUST or SHOULD address — with mechanisms of their own choice, appropriate to their assurance needs.

Throughout, “deployment” means any arrangement of producers, consumers, and intermediaries exchanging expressions, in any topology described in Architecture.

1. Expressions Are Claims, Not Proof

Threat: a consumer treats possession of a well-formed expression as proof that the described Right exists, that its Events happened, that its Eligibility Responses were genuinely issued, or that a Decision was established.

An expression is a claim. Nothing in the format makes it true. Verification is a separate act that goes through the reference chain: Proof References on Evidence and Events, evidenceSourceRef to the Evidence Sources, and Source reference locators into the systems of record (Architecture, section 3).

• Consumers SHOULD verify claims that matter to them via Proof References against the relevant Evidence Sources, rather than trusting the expression itself.
• Deployments MUST NOT represent conformance to Rights Layer (a property of the expression’s structure) as evidence of the truth of its content.

2. Integrity and Authenticity in Transit and at Rest

Threat: an expression is altered between producer and consumer, or an attacker forges an expression that appears to come from a legitimate producer.

Rights Layer defines no integrity or authenticity mechanism of its own, and deliberately names none.

• Deployments that exchange expressions are REQUIRED to address the integrity and authenticity of expressions in transit and at rest. The mechanism is the deployment’s choice: transport security, message-level integrity protection, storage-level controls, organizational procedures, or any combination appropriate to the assurance needs at hand.
• Producers and consumers SHOULD document, in their own deployment agreements, which mechanism classes they rely on, so counterparties can judge whether those meet their needs.

3. Spoofed Identifiers

Threat: an attacker mints or reuses identifiers — a subjectRef, an authorityRef, an Evidence Source id — that look legitimate but denote nothing, or denote a different real-world entity than the consumer assumes.

Identifiers in Rights Layer denote; they do not authenticate (Data Model, section 1.1). Verification of control over an identifier, and identifier binding generally, are out of scope of this specification.

• Deployments MUST define how the identifiers they accept are bound to real entities — which identifier schemes they recognize, who may assert an identifier for whom, and how a consumer checks the binding. Rights Layer is neutral as to the binding mechanism.
• Consumers SHOULD reject or treat as unverified any expression whose key identifiers (Subject, Authority, Evidence Source) they cannot bind under their deployment’s rules.

4. Stale State

Threat: a consumer relies on a materialized status value (active, suspended, …) or an old copy of an expression, after the underlying Right has been suspended, revoked, or has expired.

The status property of a Right is explicitly informative (Data Model, section 3.4); normative state is derived from the append-only Event history (Principle P6).

• Consumers SHOULD derive the state of a Right from its Events rather than from status, and SHOULD check validFrom / validUntil periods on Sources and Evidence against the time of the intended exercise.
• Consumers whose decisions carry significant consequences SHOULD obtain fresh Events (for example via a GetEvents(aboutRef, since)-style retrieval — see the non-normative Example API Draft) or verify against the Evidence Source at exercise time, rather than relying on cached expressions.

5. Replay and Duplication of Events

Threat: the same Event is delivered or ingested more than once — through retries, multi-path aggregation, or deliberate replay — inflating or distorting a history; or an old Event is replayed as if new.

Every Event has a URI id, and Events are append-only: a recorded Event MUST NOT be modified or deleted, and corrections are later Events (Data Model, section 3.13).

• Deployments SHOULD deduplicate Events by Event id: receiving an Event whose id is already recorded is a no-op, not a new fact.
• Consumers SHOULD treat two distinct Events with the same id but different content as an integrity failure, not as an update.
• The occurredAt / recordedAt distinction lets consumers detect suspiciously late recording; deployments MAY define acceptance windows.

6. Response Authenticity and Integrity

Threat: an Eligibility Response is forged in the name of a legitimate issuer, or a genuine Response is altered after issuance — turning a false into a true, or changing what it answers.

The normative rule is NR-9 in the Data Model: “An Eligibility Response SHALL be verifiably attributable to its legitimate issuer and SHALL provide a means to establish that it has not been altered after issuance.” The mechanism by which authenticity and integrity are realized is deliberately not constrained by the specification (NR-10): digital signatures, PKI, verifiable credentials, authenticated channels, institutional infrastructures, or any other verifiable method may serve.

• Consumers SHOULD verify each Response via its proof before relying on it, and SHOULD treat a Response whose authenticity or integrity cannot be established under the deployment’s rules as if it did not exist — that is, as an unanswered Eligibility.
• Deployments MUST define which verification mechanisms they accept for Responses, with mechanisms of their own choice.

7. Response Issuer Identification

Threat: a Response is verifiably intact but its issuerRef denotes an entity that is not who the consumer assumes, or an entity with no standing to answer the requirement.

The issuer of a Response must be identifiable or referenceable, but the core does not restrict issuer kinds, and identifiers denote without authenticating (section 3).

• Deployments MUST define which issuers they accept for which Eligibilities, and how an issuerRef is bound to the real entity behind it (see section 3 on identifier binding).
• Consumers SHOULD treat a Response from an issuer they cannot identify, or cannot bind under their deployment’s rules, as unverified.

8. Response Binding: Strict One-to-One

Threat: a genuine Response issued for one Eligibility is replayed against a different Eligibility — a legitimate true redirected to answer a requirement it was never issued for. This is the Rights Layer analogue of a confused-deputy attack.

The binding is strictly one-to-one (NR-3, NR-4): one Eligibility has at most one valid Response, and one Response corresponds to exactly one Eligibility. Structurally, a Response appears in exactly one place — the response property of its Eligibility — and carries its own id.

• A Response MUST NOT be replayed against, or accepted for, any Eligibility other than the one it answers. The binding is established by the Response’s placement in its Eligibility’s response property and by its id; deployments SHOULD additionally cover the Response-to-Eligibility binding with the Response’s verification mechanism, so a relocated Response fails verification.
• Consumers SHOULD treat the same Response id appearing under two Eligibilities as an integrity failure.

9. Response Freshness and Replay

Threat: an old but genuine Response is presented long after the facts it answered have changed — the licence has since been suspended, but a true Response from before the suspension is still in circulation.

Every Response carries issuedAt. The core model does not define a validity period for Responses; how long a Response remains acceptable is a deployment concern.

• Deployments SHOULD define acceptable Response age per requirement, and consumers whose reliance carries significant consequences SHOULD require fresh Responses rather than accepting arbitrarily old ones.
• Deployments MAY use profile extensions to express validity conventions, without introducing new core values.

10. Unanswered Is Not an Answer

Threat: an implementation coerces the absence of a Response into a value — treating an unanswered Eligibility as false (“deny by default”) or, worse, as true (“assume satisfied”).

Absence of a Response means the Eligibility is unanswered (NR-8). It is not a third value, and there are no intermediate values (unknown, pending, indeterminate) in the core.

• An unanswered Eligibility MUST NOT be treated as false and MUST NOT be treated as true. The only consequence of an unanswered Eligibility is that no Decision is established for the Action.
• Communication failures, pending review, timeouts, and evaluation errors are institutional or implementation states; deployments SHOULD track them outside the expression (or in extensions) rather than encoding them as Response values.

11. Decision Integrity and Completeness

Threat: a Decision entity is fabricated, or a genuine Decision is presented whose responseRefs do not actually cover every Eligibility of the Action — so “established” rests on an incomplete or unverifiable basis.

A Decision is established only when every Eligibility of the Action has exactly one verifiable Response and all are true (NR-11). The JSON Schema cannot check this cross-entity rule; it is a semantic conformance rule.

• Consumers SHOULD verify that a Decision’s responseRefs cover all Eligibilities of the referenced Action — exactly one Response per Eligibility — and SHOULD verify each referenced Response’s authenticity, integrity, and true value before relying on the Decision.
• Producers SHOULD populate establishedBy and record a DecisionEstablished Event so the establishment enters the append-only history.
• Consumers SHOULD treat a Decision whose basis they cannot trace or verify as weak, and MAY re-derive establishment from the Responses themselves.

12. Availability of Evidence Sources and Issuers

Threat: verification depends on Evidence Sources, systems of record, and Response issuers; if they are unreachable — through outage, decommissioning, or denial of service — consumers face a choice between refusing service and accepting unverified claims.

• Deployments SHOULD plan for Evidence Source unavailability: define degraded-mode behavior, acceptable evidence age, and which Actions may proceed on cached Evidence within its validFrom / validUntil window.
• Operators of Evidence Sources SHOULD treat verification availability as part of their service obligation; a reference chain is only as useful as its resolvable end.
• When an issuer is unavailable and an Eligibility therefore remains unanswered, no Decision is established — and per section 10, deployments MUST NOT coerce that absence into false or true.

13. Summary of Deployment Obligations

Concern	Obligation
Truth of expressions	Verify via Proof References against Evidence Sources; expressions are claims
Integrity and authenticity, in transit and at rest	REQUIRED to be addressed; mechanism is the deployment’s choice
Identifier binding	Deployments MUST define how identifiers are bound to real entities
State freshness	SHOULD derive state from Events; check validity periods
Event replay/duplication	SHOULD deduplicate by Event id; append-only semantics
Response authenticity and integrity	Verify each Response via its proof (NR-9); accepted mechanisms are the deployment’s choice (NR-10)
Issuer identification	Deployments MUST define accepted issuers and how issuerRef is bound
Response binding	A Response MUST NOT be replayed against another Eligibility
Response freshness	SHOULD define acceptable Response age; validity is a deployment concern
Unanswered Eligibilities	MUST NOT be treated as false or true; no Decision is established
Decision completeness	SHOULD verify responseRefs cover all Eligibilities of the Action
Evidence Source and issuer availability	SHOULD define degraded-mode behavior

None of these obligations names a technology. Each deployment chooses mechanisms — transport security, an authentication mechanism, an integrity mechanism, operational procedure — appropriate to its own assurance needs. See also Privacy Considerations, which overlaps wherever expressions carry personal data.

This site is open source. Improve this page.