Rights Layer Specification

Interoperability

Status: Draft v0.1.0 — This section is informative.

Rights Layer is a conceptual, descriptive layer (Principle P7) built for maximal reuse of existing standards (Principle P8). This document explains how Rights Layer expressions interoperate with the identifiers, rule languages, credential formats, vocabularies, and registries that already exist — without depending on any of them (Principle P1). For what each neighboring standard is and how it is positioned, see Comparison with Existing Standards.

1. Identifier-Scheme Neutrality

Every Rights Layer entity is identified by a URI, and no URI scheme is required or privileged (see Data Model, §1.1):

• https: URLs, urn: URNs, did: identifiers, and any other URI scheme are equally conformant.
• Identifiers denote; they do not authenticate. How (or whether) control over an identifier is verified belongs to the adopting systems.
• Consequence for interoperation: any external system whose entities are URI-addressable — a registry record, a SCIM resource, a DID subject, a statute locator — can be referenced from a Rights Layer expression without translation. Where an external system uses non-URI keys, deployments map them into a URI form of their choosing (e.g., a URN namespace); Rights Layer does not prescribe the mapping.

This neutrality is what allows the same expression structure to point into a land registry, a licensing register, and a shareholder register in one document.

2. Serialization: Canonical JSON, JSON-LD for RDF

• JSON is the canonical interchange form. A conforming expression is a JSON document as defined in Data Model, §4, validating against the JSON Schema.
• JSON-LD is the bridge to graph and RDF ecosystems. The published context (context/rights-layer.jsonld) maps Rights Layer terms to IRIs, so a document that includes @context can be processed as an RDF graph — enabling SPARQL querying, merging with other linked data, and vocabulary alignment (e.g., with Schema.org).
• Plain-JSON consumers stay conformant. @context is OPTIONAL; a consumer that ignores it processes the same document with identical meaning. No implementation is forced into RDF tooling.
• Other serializations (XML, CBOR, relational, …) are conformant if they preserve the model (Data Model, opening rules).

3. External Requirement Definitions via requirementRef

Rights Layer defines no rule language of its own, and evaluates nothing. An Eligibility carries:

• requirement — the human-readable statement of exactly one requirement (always present), and
• requirementRef — an OPTIONAL URI pointing at the requirement’s authoritative definition in an external system: a statute clause, a published policy, an ODRL policy, an XACML policy, a LegalRuleML representation of a norm, or any other external definition. Evaluation of the requirement is outside the layer.

Interoperation pattern:

1. The requirement’s definition lives, versioned and governed, in its own system — Rights Layer references it and never restates it (Principle P2 applied to requirements).
2. An external party that understands the referenced definition — a Response issuer — evaluates it outside the layer, by whatever method it uses, and presents the outcome as a Boolean Eligibility Response, verifiable in authenticity and integrity. The issuance is recorded via an EligibilityResponseIssued Event; when every Eligibility of the Action has a verifiable true Response, a Decision is established and recorded via a DecisionEstablished Event.
3. A consumer that does not understand the referenced definition still reads a conforming expression: the requirement text preserves human meaning, and the Responses and Decision history preserve what was actually answered and established.

This keeps Rights Layer stable while any number of policy languages evolve underneath it.

4. Credentials and Attestations Behind Responses and Evidence

External proof formats plug in through the ProofReference of an Eligibility Response, and through Evidence (see Terminology):

• An Eligibility Response’s proof MAY reference a W3C Verifiable Credential or Verifiable Presentation, a signed document, a registry lookup endpoint, or a paper record locator as the means of establishing the Response’s authenticity and integrity — proofKind labels the mechanism as a free-form string. VCs and attestations are one possible mechanism among many; none is required (NR-10).
• An Evidence entity’s proof MAY reference the same range of mechanisms for verifying the Evidence itself.
• The issuer of a credential maps to a Response issuer or an Evidence Source (and often to an Authority in the attester role).
• Validity periods of a credential map to Evidence validFrom / validUntil.
• No proof mechanism is required. A deployment using only paper records and one using cryptographic credentials produce equally conformant expressions; they differ only in what their ProofReferences point at.

The rule of separation: a credential proves a fact; the Eligibility Response is the Boolean answer it stands behind; the Rights Layer expression states the Right the fact bears on. Verification procedures, reliance decisions, and revocation checking belong to the governing systems, not to this specification.

5. Profiles and Extensions

Rights Layer extends without fragmenting (Principle P10) through two mechanisms defined in the Data Model:

• The extensions object. Any entity MAY carry additional properties under extensions, keyed by profile-defined names. Consumers MUST ignore unknown extensions, and extensions MUST NOT alter core property semantics.
• Profile types appended to type. An entity’s type is a core term optionally followed by additional profile types (e.g., a Right that a land profile also types with its own term). Consumers that know only the core specification read the core type and remain able to interpret the expression.

A profile is a named set of such extensions for a domain: controlled Action vocabularies (e.g., for land, licensing, or insurance), requirement vocabularies for Eligibilities, extension property definitions, and JSON-LD context additions. Profiles interoperate because every profiled expression is still a conforming core expression; two consumers sharing only the core can always exchange documents, and consumers sharing a profile exchange richer meaning.

Interoperability rules for profile authors and consumers:

• Producers SHOULD identify the profiles they use (e.g., via profile types and profile-scoped extension keys).
• Consumers MUST ignore unknown extensions and unknown additional types rather than rejecting the document.
• Profiles MUST NOT redefine core semantics; a document that only makes sense under a profile’s reinterpretation of a core term is non-conforming.

6. Versioning: specVersion

Every Rights Layer document declares the specification version it was produced under:

{ "type": "RightsExpression", "specVersion": "0.1.0", "entities": [ ... ] }

• specVersion follows a major.minor.patch pattern. This draft is 0.1.0; while the major version is 0, any minor version MAY introduce breaking changes as the specification stabilizes.
• Consumers SHOULD read specVersion before interpreting a document and SHOULD accept documents whose version they support; behavior for unsupported versions is deployment-defined (reject, or best-effort read of core terms).
• The intent from 1.0.0 onward is conventional compatibility: patch and minor versions add without breaking (consumers ignore what they do not know, consistent with the extension rules above); breaking changes require a major version. Version-negotiation protocols are out of scope — Rights Layer defines documents, not transports.
• Changes to the specification itself are governed by the RFC process and constrained by the Core Principles.

7. Existing Registries as Evidence Sources

The registries the world already runs on — land registries, licensing registers, corporate and shareholder registers, court records, policy administration systems — interoperate with Rights Layer as themselves:

• Each is modeled as an Evidence Source, and remains the system of record for its domain (Principle P2). Rights Layer never mirrors or supersedes it.
• A registry entry becomes Evidence (evidenceType such as registry-extract or licence-record) with evidenceSourceRef pointing at the registry and a ProofReference describing how the entry can be verified — a lookup, an extract, a certified copy — in whatever manner the registry provides.
• A registry can simultaneously appear on the existence side: a registration in it is a Source (sourceKind: "registration") grounding a Right, with reference locating the registration.
• When the registry’s content changes, the change surfaces in Rights Layer as Events (SourceChanged, RightRevoked, …) — append-only, so the expression’s history remains a faithful trail of what the systems of record said, and when (Principle P6).

This is the general interoperation stance of Rights Layer: reference, never replace. Existing standards carry sessions, proofs, rules, and records; Rights Layer supplies the neutral vocabulary that lets one structure — a right, grounded in a source, exercised through actions under eligibility requirements — be expressed across all of them.

This site is open source. Improve this page.