Status: Draft v0.1.0 — This section is informative.
Rights Layer is designed under Principle P8 (minimal invention, maximal reuse, see Core Principles): where an existing open standard already solves a problem, Rights Layer reuses it and remains compatible with it. This document positions Rights Layer against the standards and models most often mentioned alongside it, and states — for each — what it is, what it covers relative to Rights Layer, the key difference, and how Rights Layer reuses or interoperates with it.
The recurring pattern: most of the standards below address access, authorization, credentials, or policy for digital resources and sessions. Rights Layer addresses something different — expressing the existence of societal rights, grounded in legal and institutional Sources, exercised through Actions with per-Action Eligibility, and explained by an append-only Event history (see Conceptual Model). These layers do not compete; Rights Layer expressions can flow through, reference, or be evidenced by the standards below.
All standards are discussed neutrally, as open standards, without dependence on any vendor, product, or technology (Principle P1).
What it is. An IETF framework (RFC 6749 and related RFCs) for delegated authorization: a client obtains scoped access tokens to call protected APIs on behalf of a resource owner.
What it covers vs Rights Layer. OAuth 2.0 covers access to digital resources over a protocol, for the duration of a token. Rights Layer covers the existence and exercise structure of rights themselves — a land ownership right or a medical qualification exists independently of any API session.
Key difference. An OAuth scope says what a client may call now; it carries no notion of the legal Source that grounds an entitlement, no per-Action Eligibility, and no Event history. OAuth is enforcement-adjacent machinery at the API layer; Rights Layer is a descriptive layer above and independent of any transport.
Reuse / interoperation. OAuth 2.0 operates at the API/session layer beneath which Rights Layer expressions can flow: a system that exposes Rights Layer documents over an API may protect that API with OAuth, and an authorization server’s decision-making may consult Rights Layer expressions as input. Rights Layer neither requires nor forbids this; access control is out of scope (Principle P7).
What it is. An identity layer on top of OAuth 2.0 that lets a client verify an end user’s authenticated identity and obtain basic profile claims via ID tokens.
What it covers vs Rights Layer. OIDC covers authentication of a person in a session and the transport of identity claims. Rights Layer covers what a Subject is entitled to, on what basis, and under what per-Action requirements — regardless of how or whether the Subject authenticates.
Key difference. OIDC answers “who is at the other end of this connection”; Rights Layer answers “what rights does this Subject hold, why, and what may be exercised”. Rights Layer identifiers denote but do not authenticate (see Data Model, §1.1).
Reuse / interoperation. Like OAuth, OIDC sits at the session layer
beneath Rights Layer. A deployment MAY use an OIDC-authenticated identifier
as (or map it to) a Subject id, since any URI scheme is allowed. OIDC
claims about a person can also serve as Evidence in a deployment-defined
way, with the OIDC provider acting as an Evidence Source.
What it is. A W3C Recommendation defining a data model for cryptographically verifiable claims: an issuer asserts claims about a subject, and a holder presents them to verifiers.
What it covers vs Rights Layer. VCs cover attestation and presentation: a portable, verifiable statement that something is the case. Rights Layer covers the structure of the right itself — Source grounding, Actions, Eligibility, Decisions, Events. A VC can attest a fact relevant to a Right; it is not itself the model of the Right.
Key difference. A VC is a proof artifact; Rights Layer is the conceptual
frame the proof plugs into. A driving-licence VC proves that a licence
record exists; the Rights Layer expression states the Right, its drive
Action, its Eligibility, and its history.
Reuse / interoperation. Direct and concrete: a VC is one possible
mechanism behind an Eligibility Response’s proof or behind Evidence. A
Response’s or Evidence entity’s proof (a ProofReference) MAY reference a
Verifiable Credential or Verifiable Presentation as the verification
material, with proofKind labelling it accordingly — one way, among many,
to realize the authenticity and integrity that NR-9 requires, since NR-10
constrains no mechanism. The issuer maps naturally to a Response issuer,
an Evidence Source, or an Authority. Rights Layer does not require VCs — a
paper record locator is equally conformant (technology neutrality,
Principle P1).
What it is. A W3C Recommendation defining a URI scheme (did:) for
identifiers whose control can be verified without a central registrar, via
DID documents and DID methods.
What it covers vs Rights Layer. DIDs cover identification and proof of control for subjects, issuers, and resources. Rights Layer needs identifiers for every entity but is deliberately identifier-scheme-neutral.
Key difference. DID solves “how do I identify and prove control of this identifier in a decentralized way”; Rights Layer only requires that entities have URIs. Verification of control over an identifier is out of scope for Rights Layer.
Reuse / interoperation. A DID is one allowed identifier scheme, not a
required one. Because every Rights Layer id is a URI, did: identifiers
are conformant as-is for Subjects, Authorities, Objects, or any other
entity — alongside https:, urn:, and any other scheme (Data Model §1.1).
What it is. An IETF standard (RFC 7643/7644) defining a schema and REST protocol for provisioning and managing identity records (users, groups) across domains.
What it covers vs Rights Layer. SCIM covers the lifecycle of identity records in administrative systems — create, update, deprovision. Rights Layer covers rights held by subjects, not the management of the subject records themselves.
Key difference. SCIM manages accounts; Rights Layer describes
entitlements grounded in Sources. A deprovisioned SCIM user is an
administrative fact; a revoked Right is a RightRevoked Event grounded in a
Source change or an Authority’s act.
Reuse / interoperation. SCIM-managed identity records can be
referenced as Subjects: a SCIM resource’s URI is a valid Subject id or
subjectRef. The SCIM service is then simply the system of record for the
Subject’s identity attributes — Rights Layer references it and never
restates it (Principle P2).
What it is. An access-control model (standardized as ANSI/INCITS 359) in which permissions attach to roles and users acquire permissions by role assignment.
What it covers vs Rights Layer. RBAC covers organizing permissions inside a controlled system. Rights Layer covers rights that exist across and outside any single system, grounded in law, contract, or registration.
Key difference. A role is an administrative grouping; a Right is an existence fact with Sources. RBAC has no concept of statutory grounding, per-Action Eligibility answered by external Responses, or append-only history. Notably, RBAC attaches capability to the user’s role as a status; Rights Layer deliberately attaches Eligibility to the Action, not to the Subject as a status (Principle P4).
Reuse / interoperation. A system that enforces access via RBAC can derive role assignments from Rights Layer expressions (e.g., grant an internal role because a Right with a given Action is active), and can record the grounds for a role as a reference to a Right. Rights Layer does not define this mapping; it provides the vocabulary the mapping can cite.
What it is. An access-control model (described in NIST SP 800-162) in which access decisions are computed from attributes of the subject, resource, action, and environment against policies.
What it covers vs Rights Layer. ABAC covers runtime access decisions inside an enforcement system. Its subject/resource/action factoring is structurally close to Rights Layer’s Subject/Object/Action — but applied to system access, not to societal rights.
Key difference. ABAC policies decide access by evaluating attributes
and environment data inside the enforcement system; they do not express the
existence of a right or its legal Source. In Rights Layer, attribute and
environment evaluation happens outside the layer, at the Response
issuer: the core has no evaluation context and no evaluation engine, only
the Boolean Eligibility Response the issuer presents and the Decision
established when all Responses are true.
Reuse / interoperation. ABAC-style attribute rules are a natural target
for requirementRef: an Eligibility MAY reference an externally maintained
attribute policy as the authoritative external definition of its
requirement, while the requirement string remains the human-readable
statement. A deployment’s ABAC engine can act as a Response issuer —
evaluating the policy outside the layer and presenting the outcome as a
verifiable Boolean Response. Conversely, an ABAC engine can treat Rights
Layer expressions as an attribute source.
What it is. An OASIS standard defining an XML policy language and request/response protocol for attribute-based access control, including a reference architecture of policy decision and enforcement points.
What it covers vs Rights Layer. XACML covers policy expression and evaluation for access control. Rights Layer covers the descriptive structure of rights; it defines no policy language of its own (Principle P8).
Key difference. XACML is an enforcement-oriented rule language with a
combining-algorithm evaluation model, an evaluation context of request
attributes, and Permit/Deny/Indeterminate/NotApplicable decision outcomes.
Rights Layer’s core has none of these: no rule language, no evaluation
context, and no graded decision results — only Boolean per-requirement
Eligibility Responses, presented from outside the layer, and Decisions that
are establishment-only (a Decision exists only when every Eligibility has a
verifiable true Response; there is no deny and no indeterminate).
Reuse / interoperation. Direct: an XACML policy can be referenced from
Eligibility.requirementRef as the requirement’s authoritative external
definition. A deployment MAY evaluate that policy in an XACML engine —
outside the layer — and have the operator of that evaluation act as a
Response issuer, presenting the outcome as a Boolean Eligibility Response
(recorded via an EligibilityResponseIssued Event). A Permit maps to
value: true; Deny maps to value: false; Indeterminate and NotApplicable
map to no Response at all — the Eligibility simply remains unanswered.
What it is. A W3C Recommendation defining a policy language and information model for permissions, prohibitions, and obligations over assets — historically rooted in digital content licensing.
What it covers vs Rights Layer. ODRL covers policy statements about assets: what a party is permitted, forbidden, or obliged to do, with constraints. This is the closest existing vocabulary to Rights Layer’s Action-and-constraint territory, but scoped to policies over (mostly digital) assets.
Key difference. An ODRL policy is a normative statement issued by an assigner; it does not model the existence of a right grounded in statute, registration, judgment, or inheritance, nor per-Action Eligibility answered by external Responses, nor an append-only Event history. Rights Layer expresses the right; ODRL expresses usage policy. Where a Right’s Source is an agreement or licence, that agreement may itself be written in ODRL.
Reuse / interoperation. Two concrete paths: (1) an ODRL policy can be
referenced from Eligibility.requirementRef as the requirement’s
authoritative external definition (its evaluation remaining outside the
layer);
(2) an ODRL policy that functions as a Source (e.g., a content licence) can
be the target of a Source reference or an AgreementReference. ODRL action
vocabularies can also inform profile-defined Action vocabularies via JSON-LD
mapping.
Note on IPTC RightsML. RightsML, published by the IPTC, is an ODRL profile for machine-readable rights in the news and media industry. Despite the similar name, it is different in scope from Rights Layer: RightsML expresses usage policies for media assets within the ODRL model, whereas Rights Layer expresses the existence and exercise structure of rights across all domains. The two can coexist exactly as ODRL and Rights Layer do.
What it is. An OASIS standard providing an XML rule interchange format for the legal domain: representing legal norms, deontic modalities, temporality, and defeasibility in machine-processable form.
What it covers vs Rights Layer. LegalRuleML covers the content of legal norms as rules. Rights Layer deliberately does not model the content of Sources — it defines the structure for referencing them (see Terminology, Source).
Key difference. LegalRuleML formalizes what a statute says; Rights Layer records that a Right exists because of that statute and points to it. LegalRuleML operates inside the Source; Rights Layer operates above it.
Reuse / interoperation. A LegalRuleML representation of a norm is a
natural target for a Source reference and, where the norm functions as an
exercisability requirement, for Eligibility.requirementRef. A rule engine
consuming LegalRuleML can act as the evaluator behind an Eligibility
Response — its operator being the Response issuer, with the evaluation
itself outside the layer.
What it is. A collaboratively maintained vocabulary of types and properties (Person, Organization, Place, CreativeWork, …) for structured data on the web, most commonly embedded via JSON-LD.
What it covers vs Rights Layer. Schema.org covers general-purpose description of things for discovery and interchange. It has no model of rights existence, Sources, Eligibility, or Events.
Key difference. Schema.org describes entities; Rights Layer describes the rights relation between them. They are complementary vocabularies at different levels of specificity.
Reuse / interoperation. Schema.org terms can be mapped via JSON-LD:
because Rights Layer provides a JSON-LD context (see
Interoperability), a document or profile MAY align
Rights Layer entities with Schema.org types (e.g., a Subject that is also a
schema:Person, an Authority that is also a schema:GovernmentOrganization)
by adding profile types and context mappings, without changing core
semantics.
What it is. A W3C Recommendation for expressing linked data in JSON: a
@context maps JSON terms to IRIs, making a JSON document interpretable as
an RDF graph.
What it covers vs Rights Layer. JSON-LD is a serialization and semantics technology, not a rights model. It covers how terms in a JSON document are given global, graph-compatible meaning.
Key difference. None in kind — this is pure infrastructure that Rights Layer builds on rather than parallels.
Reuse / interoperation. Directly used: Rights Layer publishes a
JSON-LD context (context/rights-layer.jsonld)
and the canonical JSON document form carries an optional @context (Data
Model §4). Plain-JSON consumers ignore it; JSON-LD consumers obtain RDF
interoperability, term disambiguation, and mapping to external vocabularies
such as Schema.org.
What it is. A family of security models in which authority is conveyed by possession of unforgeable capability tokens that both designate a resource and authorize actions on it, rather than by identity checked against access lists.
What it covers vs Rights Layer. Capabilities cover conveyance and delegation of authority inside computing systems. Their “the token is the permission” stance is philosophically interesting next to Rights Layer’s “the Right exists independently of any token” stance.
Key difference. In a capability system, holding the token is the authority; in Rights Layer, a Right exists by virtue of its Sources, and any token, certificate, or credential is merely Evidence of it. Rights Layer also separates existence (Right) from exercisability (per-Action Eligibility), which capability tokens typically fuse.
Reuse / interoperation. A deployment MAY issue capability tokens as an enforcement consequence of a Rights Layer Decision, and a capability token presented to a system MAY be described as Evidence (with a ProofReference to its verification mechanism). Rights Layer itself mandates no token model (Principles P1, P7).
What it is. The practice area — supported by various standards efforts and many products — of administering fine-grained entitlements (who can access which application resources) across an enterprise: cataloguing, requesting, approving, certifying, and revoking access.
What it covers vs Rights Layer. Entitlement management covers administrative governance of access grants inside organizations. Its request/approve/revoke/recertify lifecycle superficially parallels Rights Layer’s exercise-request/Decision/Event chain.
Key difference. An entitlement is an artifact of an organization’s IT governance; a Right is grounded in legal and institutional Sources and is meaningful across organizational boundaries. Entitlement systems are enforcement-coupled and product-shaped; Rights Layer is a vendor-neutral descriptive vocabulary (Principle P1).
Reuse / interoperation. Entitlement catalogs and approval records can be
referenced as Evidence Sources and Evidence; an approval inside such a
system can be presented as an Eligibility Response — the approving system
acting as the Response issuer, recorded via an EligibilityResponseIssued
Event — where the entitlement corresponds to a requirement for exercising a
Right. Conversely, entitlement systems can consume Rights Layer expressions
as the documented grounds for grants.
Relationship legend — reuse: Rights Layer directly uses or references the standard; complement: the standard operates at an adjacent layer and composes with Rights Layer; different-scope: the standard addresses a problem Rights Layer deliberately does not (and vice versa).
| Standard / model | Layer it addresses | Relationship to Rights Layer |
|---|---|---|
| OAuth 2.0 | Delegated API authorization (sessions, tokens) | Complement — transport/access layer beneath Rights Layer expressions |
| OpenID Connect | Authentication and identity claims in sessions | Complement — authenticated identifiers usable as Subject ids |
| W3C Verifiable Credentials | Verifiable attestation and presentation | Reuse — one possible mechanism behind Response proofs and Evidence |
| W3C DID | Decentralized identifiers and control proof | Reuse — one allowed identifier scheme (not required) |
| SCIM | Identity record provisioning and lifecycle | Complement — SCIM records referenced as Subjects |
| RBAC | Role-based permission administration | Different-scope — roles can be derived from Rights, not vice versa |
| ABAC | Attribute-based access decisions | Complement — attribute policies referenceable via requirementRef; evaluation external, at the issuer |
| XACML | Access-control policy language and evaluation | Reuse — policies referenced from Eligibility.requirementRef; outcomes presentable as Boolean Responses |
| ODRL (incl. IPTC RightsML profile) | Usage policies over assets | Reuse — policies referenced via requirementRef or as agreement Sources |
| LegalRuleML | Machine-readable legal norms | Reuse — norm representations referenced as Sources / requirement definitions |
| Schema.org | General entity description vocabulary | Reuse — mapped via JSON-LD context and profile types |
| JSON-LD | Linked-data serialization and semantics | Reuse — directly used for the Rights Layer context |
| Capability-based security | Token-conveyed authority in systems | Different-scope — tokens are at most Evidence, never the Right |
| IAM entitlement management | Enterprise access-grant governance | Complement — entitlement records as Evidence; approvals presentable as Eligibility Responses |
For the mechanics of these integration points — identifier neutrality,
requirementRef, Response and Evidence proofs, profiles, and extensions —
see Interoperability.