#DFOS Extension Registry

Status — companion document, no clock of its own. This document defines no protocol rules; it is the single index of the names the specs register — service types under the core's open services namespace, JWS typ values under the core's typ convention, and the names the corpus mints in global registries it does not own (External Registrations). Each name's semantics live in its owner spec, which remains normative wherever the two could be read to disagree. A new name lands by adding its row here in the same PR that specifies it, never by minting locally (CONTRIBUTING, item 2). Discuss in the DFOS space.

#Service Types

The services namespace is open: the two core types are structurally validated by every conformant verifier, and every other registered type is an opaque extension the core preserves verbatim and ignores — registering one requires no protocol or cross-language change. One row per type:

Validation — core: structurally validated by every conformant verifier, and a malformed entry rejects at verification. consumer: opaque to the core (preserved verbatim, ignored); structural validation is an obligation of the owner spec's consumers. Everything else — ambiguity rules (DfosOrigin and DfosAuthorizationServer: one entry or none), field grammar, display discipline — is the owner spec's.

#JWS typ Values

Every DFOS JWS envelope is typ-scoped: the protected header names exactly one registered value, and a verifier rejects any typ other than the one the presented context requires — the gate that keeps a JWS signed for one purpose from ever being presented as another. The cid column marks whether the envelope carries the protocol's cid header.

#External Registrations

The corpus also mints names in two global namespaces DFOS does not own, and there the obligation runs outward: RFC 8615 §3 requires that an application minting a new well-known URI register its suffix in the IANA Well-Known URIs registry, and RFC 8552 §4.1.5 requires that a public specification calling for a global underscored DNS node name enter it in the IANA Underscored and Globally Scoped DNS Node Names registry. This table tracks those registrations the way the tables above track the internal ones — one row per name, corrected in place as the registries change. A Registered cell of — is a name the registry does not list.

Registration is an act of the project's stewards, outside any PR; what a PR owns is this table's accuracy and the registration note in each minting spec. A future spec that mints a well-known path or an underscored name adds its row here in the same PR that specifies it, exactly as internal names do.

#Registries That Live in Their Owner Spec

Names whose grammar is inseparable from their owner's machinery register there, not here — this section only says where:

• Credential resource forms (chain:<contentId>, mailbox:<id>, api:<host>) — CREDENTIALS → Resource Types.
• API action tokens (read:profile, read:email, read:memberships) — API-AUTH's action registry.
• SIWD scope tokens — SIWD → Scopes and Credentials.
• Sign-request payloadTyp families — SIGNING.
• Key-proof ceremony purposes — KEY-PROOF → Purpose Registry (each purpose typ also lands a row above).
• App description members — SIWD → The App Description Document (the member table is the registry).
• Content schemas ($schema vocabulary) — CONTENT-MODEL, hosted at schemas.dfos.com.