childsafe: vocabulary, Version 1.0

This is the versioned context document for the IFC-SiS Content Metadata Standard. A conforming child-safe namespace record binds to it with:

The childsafe: prefix is invariant in every national instance. Field names are never localised and the vocabulary is closed at a given version: a record may carry only terms defined in the version it declares, so an unrecognised term is a validation error rather than a silently ignored extension.

Status. This is a working draft published for technical review. It does not constitute a final normative instrument. Field semantics are defined normatively in the Content Metadata Standard; where this document and the Standard differ on a field's meaning, the Standard governs. Comments on version 1.0 are invited until 30 September 2026 and should be sent to shknudson@ifcsis.org. Substantive comments received before that date are considered for version 1.1, and the disposition of each is recorded.

Record validity and integrity

Term	Type	Status	Permitted values
childsafe:valid-from	ISO date-time	Required	Instant from which the record is operative
childsafe:valid-until	ISO date-time	Required	Instant after which the record MUST be rejected
childsafe:sequence	Integer	Required	Monotonic per domain; a relying party SHOULD reject a lower sequence than one already seen
childsafe:canonicalization	String	Required	RFC8785

Why these exist. Without a bounded validity window, an evicted or superseded registrant could continue serving an old but validly signed record indefinitely, and no relying party could detect it. The window and the sequence number make staleness detectable without requiring real-time revocation infrastructure. Canonicalization is fixed at RFC 8785 (JSON Canonicalization Scheme) because JSON serialisation is otherwise non-deterministic and signatures would fail to verify across implementations.

Scope and dependencies

Term	Type	Status	Permitted values
childsafe:scope	String	Required	domain-and-subdomains \| domain-only
childsafe:excluded-hosts	Array	Conditional	Hostnames beneath the domain not covered by this record. Only meaningful where scope is domain-and-subdomains
childsafe:external-resources	String	Required	conforming-only \| declared \| none

What is admitted. The admitted object is the registrant and the delegation granted to it, not a page or a corpus. scope declares whether subordinate hosts are covered. external-resources declares the rule for resources a browser fetches while rendering the site but which the registrant does not serve: conforming-only means displayed or executed third-party resources must themselves originate from conforming delegations; declared means external dependencies are enumerated and assessed with the record; none means no external resources are loaded. Which rule is workable at registry scale is among the questions a first trial exists to answer.

Machine-readable artifacts

The vocabulary

Artifact	Location
JSON-LD context	/v1/index.jsonld
JSON Schema (shape validation)	/v1/record.schema.json
Example record	/v1/example.json

These tables are generated from /v1/record.schema.json at page load. They are not a hand-maintained description of the schema; they are the schema, rendered. If a field is added, removed or constrained, this page changes with it, and documentation cannot drift from the artifact implementers actually validate against.

What the vocabulary does not contain

There is no field describing the faith, religious tradition, political alignment, or value system of a domain, and there will not be. Pluralism is delivered at the curator layer: independent curators read the neutral record and build guides reflecting a particular pedagogical, cultural, linguistic or family-values perspective. Curators read the schema; only the Foundation, through consultation, writes it.

Signing and freshness

Two implementation traps, named so implementers do not find them the hard way. Under RFC 8785, object keys sort by UTF-16 code-unit sequence — not by UTF-8 bytes, not by code point, and not by any locale-aware collation. A naive sort passes most tests and diverges on supplementary-plane characters. And numbers serialise by ECMAScript rules, so 333333333.33333329 canonicalises to 333333333.3333333. An implementation that gets either wrong produces signatures that verify locally and fail everywhere else.

Before any signature profile is locked, the same records should be canonicalised through at least three independent implementations in different languages and the output compared byte for byte. Libraries verified against the reference vectors exist for Python, JavaScript, Go, Java and Rust; the reference test data, including the Unicode key-sorting vector and the number edge cases, is published alongside the RFC. A conforming implementation should be tested against those vectors rather than against our example record alone.

The signature profile must also state precisely what is canonicalised — the whole unsigned record or a defined subset — and how the signature is attached. That is specification work still outstanding, and it is listed here rather than left to be discovered.

The vocabulary does not define a cryptographic format and does not intend to. A conforming implementation uses a published signature profile specifying canonicalisation (fixed here at RFC 8785), permitted algorithms, key discovery, rotation and revocation, built on existing internet standards rather than on primitives of our own.

A signature attests that the record is the attesting party's current conformity record for that delegation. It does not independently establish the truth of any representation the record contains. Cryptographic authenticity is not substantive truth.

A relying party MUST reject a record outside its validity window, and SHOULD reject a record whose sequence number is lower than one already observed for the same domain. Behaviour where a record cannot be retrieved at all — whether to fail open or fail closed — is a deployment policy question and is deliberately not fixed here.

Versioning

The context URL embeds the major version. A consuming implementation pins to the major versions it understands and refuses records declaring a major version it does not. Minor, backward-compatible clarifications are published without changing the URL; field additions or removals require a major version and follow the consultation and advance-notice procedure in the Standard. The immediately preceding major version is maintained for no less than twelve months after a release.