RS-DM-CLAIM: Registry Notary claim definition data model

View as Markdown

This document defines the target data model of a Registry Notary claim definition: the configuration artifact that declares what Notary can evaluate, whether evidence is registry-backed or self-attested, what typed inputs and Relay consultations it may use, what it discloses, and what it can issue. It is the structural counterpart to the Registry Notary protocol.

Where this document and RS-PR-NOTARY state the same constraint, RS-PR-NOTARY is the protocol-level (wire) form and this document is the data-model form. Both refine the Registry Notary component of RS-ARC-G Section 3 (REQ-ARC-G-007) one level of detail down, from architectural boundary to the structure a claim takes in configuration. Security-model concerns (the scope and authentication machinery a claim relies on) belong to RS-SEC-G; this document refers to them only where they shape the model.

The key words in this document are interpreted per RS-DOC Section 2. Defined terms are used per RS-TERMS.

Version history

Version	Date	Status	Change
0.1.0	2026-06-13	draft	Initial claim-definition data model, distilled from the Registry Notary source-and-claim modeling guide, the operator configuration reference, and the two-way credential-eligibility and matching-policy validations the configuration loader enforces.
0.2.0	2026-07-07	draft	Reworded REQ-DM-CLAIM-005 so the controlled-environment restriction on disabling matching-failure collapse reads as operational guidance rather than a runtime-enforced constraint, and documented the extract/exists value-type-checking gap and the empty-`formats`-list evaluation gap in Limitations.
0.3.0	2026-07-13	draft	Replaced direct source bindings and Notary matching with registry-backed Relay consultations and self-attested evidence modes.
0.3.1	2026-07-14	draft	Updated load-time validation limits after duplicate ids, disclosure defaults, evidence-mode rules, and registry-backed output types became startup checks.
0.3.2	2026-07-14	draft	Aligned credential eligibility with Registry Stack project authoring: profiles declare claims once, and the compiler derives the product-level reverse index.
0.3.3	2026-07-17	draft	Made omitted claim `formats` default to the canonical claim-result JSON representation and made an explicitly empty list a configuration-load error.
0.3.4	2026-07-17	draft	Made the evaluation response-format set closed: the canonical claim-result JSON format is required, CCCEV-shaped JSON-LD is the only additional renderer, and credential issuance formats are rejected.
0.4.0	2026-07-17	draft	Restricted credential membership to mutually bound registry-backed claims and made source-free claims evaluation-only.

1. Scope and references

This specification covers the structure and invariants of a claim definition:

The claim’s identity and the value it evaluates.
Inputs: the request lookup paths a claim consumes.
Evidence mode and compiler-pinned Relay consultation bindings for registry-backed claims.
The rule and its dependencies.
The disclosure policy.
Response formats and value typing.
Credential eligibility.
Batch behavior.

This specification does not define:

The exact configuration schema: Every field, its YAML key, and its default belong to the Registry Notary operator configuration reference and to the generated OpenAPI document rendered as the Registry Notary API reference. This document states the model’s structure and the invariants a deployment enforces, and does not restate field schemas that would drift from the source.
Protocol and wire behavior: How a caller submits an evaluation, negotiates a format, or receives an error belongs to RS-PR-NOTARY.
The security model: How scopes, authentication, workload credentials, and key material are configured and enforced belongs to RS-SEC-G.
The other data models of the stack: The Registry Relay dataset surface and the portable metadata manifest are separate data models, reserved for their own RS-DM-* specifications.

For the authoring guidance behind this model, see Author an HTTP Registry Stack project. For the worked claim pipeline, see Evidence issuance, end to end.

2. Anatomy of a claim definition

A claim definition is a named capability. It declares an identity, one evidence mode, the typed inputs and Relay consultations it may use, the single rule that decides its value, and the disclosure, format, and credential rules that shape what leaves the service.

flowchart TD
    claim["Claim definition<br/>id · subject_type · value type"]
    inputs["Typed inputs<br/>target · requester · declared variables"]
    evidence["Evidence mode<br/>registry-backed consultation · self-attested"]
    rule["Rule (exactly one)<br/>consultation output · consultation matched · cel (+ depends_on)"]
    disclosure["Disclosure policy<br/>default and allowed modes"]
    formats["Evaluation render formats<br/>claim-result JSON · CCCEV JSON-LD"]
    creds["Credential profiles<br/>authored claim membership, issues SD-JWT VC"]
    claim --> inputs --> evidence --> rule
    rule --> disclosure
    rule --> formats
    rule -.-> creds

The diagram restates the model: a claim receives either compiler-pinned Relay outputs or permitted self-attestation inputs, a single rule decides the value, and the disclosure policy and formats govern the result. Credential profiles may select only registry-backed claims. A claim definition describes one decision or one extracted value; a claim that tries to return a whole record over-collects and is hard to authorize.

REQ-DM-CLAIM-001: A claim definition MUST carry a stable identifier (id); the id is the reference callers use to evaluate the claim and the reference a credential profile uses to name it. The id SHOULD be stable, specific, and unique across the configuration.

3. Inputs and evidence modes

A claim’s inputs are the named request paths it may consume, drawn from the target subject, requester, and declared variables. A claim selects one evidence mode. registry_backed binds compiler-pinned Relay consultations whose typed outputs feed the rule. self_attested uses only the configured authenticated context and request inputs. Notary has no direct registry source mode.

REQ-DM-CLAIM-002: Each claim MUST declare exactly one evidence mode. A registry-backed claim MUST bind every Relay consultation by profile id and contract hash and MUST map only declared typed request inputs. A self-attested claim MUST NOT declare a Relay consultation. Registry Notary MUST enforce the claim’s required scopes before either mode performs work.

REQ-DM-CLAIM-003: A registry-backed claim SHOULD bind only the Relay outputs its rule needs. Consultation input mapping MUST NOT select a Relay origin, credential, method, capability, output projection, or response mapper. Request paths outside the closed mapping MUST be rejected.

For target-derived inputs, the closed project mapping admits request.target.id, request.target.identifiers.<stable-id>, and request.target.attributes.<stable-name>. A target attribute stable name MUST match [a-z][a-z0-9_]{0,63}. An authored mapping admits only that named caller-supplied target value; it does not authenticate the value or authorize arbitrary traversal of the target object.

4. Relay consultation contract

A Registry Stack project compiles subject selection, cardinality, source adaptation, and output minimization into Relay. Notary sees only the consultation inputs and typed output contract.

REQ-DM-CLAIM-004: A registry-backed claim MUST require the request purpose, Relay profile id, contract hash, input map, and output contract to match the compiled consultation before Relay work. A mismatch MUST fail closed and MUST NOT fall back to another profile or evidence mode.

REQ-DM-CLAIM-005: Relay no-match, ambiguity, contract, and source failures MUST map into the configured Notary public error posture without exposing raw source rows or unreviewed source diagnostics. Delegated proof failures MUST use the stable delegated denial codes defined by RS-PR-NOTARY.

5. Rule and dependencies

The rule is the single decision at the center of a claim. Registry Notary implements three rule kinds: consultation_matched (whether the Relay consultation matched), consultation_output (a typed value from one named consultation output), and cel (a value derived from closed evidence inputs or earlier claim results through a hardened expression).

REQ-DM-CLAIM-006: A claim definition MUST declare exactly one rule, and that rule MUST be one of the implemented kinds consultation_output, consultation_matched, or cel. Any other rule kind MUST be rejected as unknown. This is the data-model form of REQ-PR-NOTARY-007.

REQ-DM-CLAIM-007: A cel rule MAY reuse earlier claim results through depends_on. Every depends_on entry MUST name a claim defined in the same configuration, and the dependency graph MUST be acyclic; a deployment MUST reject a configuration whose depends_on names an unknown claim or forms a cycle.

6. Disclosure policy

A claim’s disclosure policy is a default mode and an allowed set drawn from the three disclosure profile modes defined in RS-TERMS Section 2: value (the full value), predicate (only the true/false satisfaction), and redacted (the value fully hidden).

REQ-DM-CLAIM-008: Registry Notary MUST apply a claim’s default disclosure mode when the caller requests none, and MUST refuse a mode that is not in the claim’s allowed set. This is the data-model form of REQ-PR-NOTARY-009. A claim’s default SHOULD be a member of its allowed set, and a privacy-sensitive claim SHOULD default to the least-revealing useful mode.

7. Response formats and value typing

A claim’s formats list declares the response formats it can render, and its value descriptor declares the type the evaluated value takes.

REQ-DM-CLAIM-009: A claim’s formats MUST include application/vnd.registry-notary.claim-result+json, and MAY additionally include only application/ld+json; profile="cccev" (the data-model form of REQ-PR-NOTARY-011). When formats is omitted, Registry Notary uses the claim-result JSON media type. An explicitly empty list, an unknown format, or a list that omits the canonical format MUST be rejected at configuration load. SD-JWT VC issuance uses application/dc+sd-jwt in credential profiles and MUST NOT appear in a claim evaluation render formats list. A claim declares the type its evaluated value takes; where that type is one Registry Notary recognizes, the evaluated value MUST conform to it or the evaluation is refused rather than returned.

8. Credential eligibility

A claim is not issuable as a credential by default. In a Registry Stack project, the credential profile is the single authored direction: it lists the claims it may issue. The compiler derives the reverse claim-to-profile index required by Registry Notary’s product configuration.

REQ-DM-CLAIM-010: A credential profile MUST list at least one claim. The Registry Stack project compiler MUST derive each listed claim’s product-level credential_profiles reverse index from that membership and MUST reject unknown or source-free claims. Registry Notary MUST require every credential profile claim, credential-capable subject-access allow-list entry, and OID4VCI projection to resolve through mutually consistent bindings to non-delegated registry_backed evidence. Delegated relationship and dependent-claim credential bindings MUST be rejected. Registry Notary MUST issue a claim only when the compiled profile membership and derived reverse index agree and exact compiler pins plus normalized unique Relay execution records are retained for its full dependency closure. Those private execution identifiers MUST be retained only for a credential-capable selection, not for a registry-backed evaluation-only claim. The issued credential is an SD-JWT VC bound to its holder by did:jwk, per REQ-PR-NOTARY-013 and REQ-PR-NOTARY-015.

9. Batch behavior

Batch evaluation lets one request evaluate claims for several subjects. It is an outer Notary API envelope, not a second evidence model: it adds no authorization, disclosure, consultation, or issuance behavior of its own.

REQ-DM-CLAIM-011: Batch evaluation MUST be semantically equivalent to evaluating each item independently. Registry-backed batches MUST validate the complete outer request before the first Relay call, require idempotency where the API contract specifies it, preserve item order, and MUST NOT coalesce duplicate subjects across item positions or bypass single-evaluation authorization and disclosure.

10. Limitations

These constraints are stated so a reader does not infer a capability from a declared but unusable shape.

Non-CEL value-type conformance: evaluation does not yet verify the value descriptor for the non-CEL rule paths. Tracked in GH#232.

Conformance

A claim definition, and the Registry Notary deployment that serves it, conforms to the target model in this specification when it:

carries a stable identifier by which it is evaluated and named (REQ-DM-CLAIM-001);
declares exactly one evidence mode, pins every registry-backed Relay consultation, enforces caller scopes before work, and rejects inputs outside the closed mapping (REQ-DM-CLAIM-002, REQ-DM-CLAIM-003);
verifies the complete Relay consultation contract before work and preserves the configured public error posture without source leakage (REQ-DM-CLAIM-004, REQ-DM-CLAIM-005);
declares exactly one implemented rule kind and rejects every unknown kind (REQ-DM-CLAIM-006);
keeps depends_on references resolvable and acyclic (REQ-DM-CLAIM-007);
applies the default disclosure mode and refuses modes outside the allowed set (REQ-DM-CLAIM-008);
renders the claim-result format and produces a value matching its declared type (REQ-DM-CLAIM-009);
issues a credential only under compiler-closed profile membership (REQ-DM-CLAIM-010);
treats batch evaluation as equivalent to repeated single evaluation and never as a way around per-evaluation rules (REQ-DM-CLAIM-011).

Conformance to this specification does not imply conformance to any external standard cited in the standards_referenced frontmatter field. Each standard’s adoption mode and scope are documented in the standards register.

Evidence

This specification is partial: most requirements describe shipped behavior a reader can inspect, per RS-DOC REQ-DOC-014, but Section 10 records the remaining target-model gap that keeps REQ-DM-CLAIM-009 from being fully verified today.

Registry Stack project authoring walks the authored claim, Relay consultation, disclosure, fixture, review, and unsigned-build workflow.
The Registry Notary operator configuration reference lists the claim, Relay, self-attestation, and credential-profile fields.
RS-PR-NOTARY carries the protocol-level form of the scope, rule, disclosure, format, and credential requirements this document gives a data-model form (REQ-PR-NOTARY-004/006/007/009/011/013/015).
RS-ARC-G Section 3 holds the Registry Notary component invariant (REQ-ARC-G-007) that both this document and RS-PR-NOTARY refine.
The standards register records the adoption mode for SD-JWT VC and the W3C DID method named in standards_referenced.
GH#232 tracks the non-CEL value-type conformance gap called out in Section 10.

RS-PR-NOTARY is the protocol contract that operates on this data model.
RS-ARC-G places Registry Notary and its claim model in the registry stack architecture.
RS-SEC-G holds the security model the scope and credential rules here rely on.
RS-TERMS defines the claim and credential vocabulary used here.
Evidence issuance, end to end is the narrative walk-through of a claim from request to credential.