Trusted context constraints

View as Markdown

Trusted context constraints are policy facts whose meaning must survive the boundary between a caller, Registry Notary, Registry Relay, and a source registry. Registry Platform supplies shared types and redacted reporting conventions. Each product still owns the decision made at its own boundary.

The shared vocabulary

The shared policy vocabulary covers five families:

Legal basis records why the requested operation is permitted.
Consent records whether a trusted consent reference is required and accepted.
Jurisdiction limits where the request or evidence can be used.
Assurance records the accepted assurance level and the trusted context that supplied it.
Source freshness limits the accepted age of an observation.

Sharing names and report shapes does not make Relay and Notary interchangeable. It prevents a constraint from being silently renamed or weakened as a request crosses products.

Relay owns source context

Relay owns source identity, destinations, credentials, protocol adaptation, selector canonicalization, source observations, and minimized typed outputs. A source freshness check is therefore evaluated from Relay-owned observation semantics.

observed_at means the time represented by the reviewed source observation contract. It is not automatically a domain record date. Birth date, registration date, amendment date, or a spreadsheet update column does not prove when Relay observed the record unless the integration declares that meaning and its fixtures prove it.

If the observation-time contract is not proven, diagnostics must report it as unknown. They must not reinterpret a domain date as source freshness.

Notary owns evidence authorization

Notary authenticates the evidence caller and enforces the compiled service purpose, required scopes, subject binding, legal basis, consent, jurisdiction, assurance, disclosure, and issuance policy before consulting Relay. A failed preflight makes zero Relay calls.

For a registry-backed claim, Notary can invoke only the compiler-pinned Relay consultation named by its evidence mode. The pinned profile fixes the contract hash, purpose, closed input mapping, outcome union, and typed outputs. Notary does not configure a source origin, credential, lookup recipe, freshness field, or adapter runtime.

A Notary-only self-attested service performs no Relay or source I/O. Its constraints apply only to the authenticated subject context and source-free claim policy.

Reports and audit evidence

Product diagnostics expose bounded policy summaries and may include a context_constraints array. An empty array means that the configuration has no additional shared constraint block to report. It does not mean authentication, purpose, scope, consultation pinning, or product-owned policy is disabled.

Reports may identify the policy family, product-owned config location, trusted value class, and whether a presence or allow-list check was applied. They must not expose Relay source credentials, subject identifiers, selectors, raw records, consent values, or authorization details.

Presence and allow-list checks remain distinct. Requiring a legal-basis or consent reference does not imply that every possible value is approved. Authentication-derived assurance also remains distinct from an assurance value asserted in authorization context.

Review questions

Does Notary reject an unauthorized request before any Relay consultation?
Does the compiled Notary contract exactly match the Relay consultation semantics and hash?
Is source freshness derived from a proven Relay observation contract rather than a domain date?
Are reports bounded and redacted at both product boundaries?
Does a self-attested service remain source-free?