The Anatomy of RSM ID

The RID: identity with nothing in it

An RID is the permanent canonical identity of one resource referent. It has two halves. The prefix identifies a registered issuance namespace, and the suffix is generated by the issuer — by default sixteen Crockford Base32 characters carrying eighty bits of cryptographic randomness. The specification's illustrative example is 451.7K4M9Q2X8D5P0R6T. Comparison is exact: a lower-case variant is not the same RID, although a user interface may help someone type it.

The prefix deserves a second look, because it is the one part of an RID that looks meaningful. It is not a hostname and it does not reveal the current owner of anything. It names a namespace in the Prefix Registry, which records the namespace's controller, issuance permissions, delegation, signing keys, and succession arrangements (§3.2). A resolver must never assume that the prefix tells it which server to ask. The 451 prefix used throughout these materials is proposed for the 451 federation and has not been registered, so no identifier in this Journal has actually been issued.

The RRN and RSN: names with structure

Where the RID is deliberately silent, the RRN is deliberately informative. Its form is rrn:<realm>:<authority>:<jurisdiction>:<space>:<kind>/<resource-id>, and each segment records context about how the resource was named: the federation realm, the issuing authority, the jurisdiction under which the name was issued, the logical Semantic Space namespace, the resource's registered kind, and its local name. The specification's example is rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model, which maps to the RID above.

Version 1.1 closed a gap that the website had to work around in earlier releases: the grammar is now published as ABNF, and the bounds are stated. A segment begins with a lowercase letter or digit and continues with lowercase letters, digits, hyphens, or underscores. Parsers reject uppercase input rather than silently lowering it, and they never decode percent escapes, because a registered name must compare byte for byte. You can see the full grammar on the Identifiers page.

The kind segment now draws on a versioned registry. Its minimum initial profile lists twelve kinds — space, concept, document, person, organization, place, facility, observation, instrument, formation, outcome, and relationship — and an unregistered kind may parse lexically but is rejected at authoritative registration (§18.3). The kind is a naming classification, not an RDF vocabulary term and not a property of the RID. That is why a Musewoods fieldnote is named with kind document: fieldnote is a form of writing in an application, not a registered kind.

The relationship between names and identities runs in one direction. Every registered RRN maps to exactly one RID, but one RID may collect several names over time — after a transfer between namespaces, for instance. Old names are never reassigned; they stay reserved and keep resolving to the identity they always named. The RSN is not a separate scheme at all. It is an RRN whose kind is exactly space, such as rrn:451:451labs:us-ca:wellzai:space/root, and the Semantic Space it names has its own RID — the demonstration uses 451.SD27J6QHDVEF0DYY for Wellzai. The Fieldnote Why a Semantic Space has both an RID and an RSN explains why both are needed.

The Identity Record: what the registry remembers

Identifiers and names need somewhere durable to live. The Identity Record binds one RID to one registered referent descriptor and preserves the issuing namespace, lifecycle status, issuance provenance, and enough information to prevent reassignment. Where applicable it also holds registered RRNs and their effective history, the authoritative space binding, delegated authority history, and audit events.

What the record leaves out is as instructive as what it holds. It contains no required copy of the resource body. Semantic attributes, content revisions, relationships, and application projections remain with the Semantic Space that is authoritative for the resource. Document 08 gives an illustrative envelope rather than a schema, and it explicitly marks its tokens as placeholders. Its first lines are:

rid: 451.7K4M9Q2X8D5P0R6T
referentDescriptor: Wellzai Outcome Formation Model
kind: document
primaryRrn: rrn:451:451labs:us-ca:wellzai:document/outcome-formation-model
issuerPrefix: "451"
identityStatus: active
authoritativeSpace:
  rsn: rrn:451:451labs:us-ca:wellzai:space/root
  rid: <registered-space-rid>

The envelope continues with issuanceProvenance, registeredNames, and authorityBinding, each also a placeholder in the specification.

In the reference implementation, the record is not a single row. Document 09 assembles it from several tables, each preserving a different kind of history with effective dates, and it warns that its SQLite schema is representative rather than production-complete. The useful lesson for any implementer is that the record is a contract about what must be preserved and disclosed, while the storage behind it is a choice.

Four registries and the authority to issue

The registry is not one database in the logical model. The Prefix Registry allocates globally unique RID prefixes. The Authority Registry records authenticated namespace controllers and the delegations they grant. The Resource Identity Registry holds permanent RID records and their lifecycle mappings. The Space Registry records Semantic Space identities, capabilities, and authoritative resolution endpoints. Keeping their contracts separate is what allows them to be replicated or federated later without changing what an RID means. The Seednote on the registry summarizes the four.

Issuance is where the separation becomes an obligation. An issuance authority must prove its permission to issue under a prefix, and the registry must support authenticated administration and auditable delegation changes (§5.4), and registry mutations require authenticated, authorized requests (§11.2). Generating a random suffix is the easy part. What makes an RID authoritative is the atomic insertion that follows: a collision triggers a new suffix, and a failed issuance must never return an identifier that looks authoritative (§3.4).

Document 09 adds the operational detail that keeps issuance safe under retries. Idempotency keys are scoped to the authenticated issuer and a hash of the normalized request, so repeating an identical request returns the original RID while reusing a key with different content is a conflict. It also warns against a subtle failure: authorization errors, malformed input, and storage failures must never be misclassified as collisions, or a broken system will appear to be merely unlucky.

Lifecycle: how an identity ages

Earlier editions listed the lifecycle states without defining them. Version 1.1 defines all five, and the definitions are worth reading as a set, because they describe what an identity is at each stage rather than what a page about it looks like.

The normal transitions are reserved -> active, active -> deprecated, active -> superseded, active -> retired, deprecated -> active, deprecated -> superseded, and deprecated -> retired. Restoring a retired or superseded identity to active requires a separately audited exceptional governance procedure and must never happen implicitly. Just as important is what does not move the lifecycle: content revisions, authorization policies, publication states, and administrative transfers. A paper can be revised seven times, made private, and moved to a new steward while its identity remains active throughout. The identity lifecycle Seednote and the demonstration resolver's deprecated, reserved, superseded, and retired samples show each state in practice.

Resolution: where the parts meet

Resolution is the moment every part of the architecture is consulted at once. A resolver accepts a canonical RID as its primary input and maps registered names or approved HTTPS identifiers to the RID before anything else. It then works through a fixed sequence, and each step can end the process with a typed outcome rather than a guess.

The Fieldnote Why resolution is not simply fetching a document explains why the sequence cannot be shortened to a redirect. The short version is that a resource may be physical, abstract, restricted, or retired, and the resolver's job is to say truthfully what is permitted to be known about it now.

The v1.1 HTTP profile

The largest change in version 1.1 is that resolution now has a wire profile. Before it, the specification named eight logical statuses but left their HTTP form open. Section 18 fixes the routing, the negotiation, the response shapes, and the status mapping. A successful JSON identity response must carry at least rid, kind, identityStatus, and resolutionStatus, and it may add fields such as primaryRrn, spaceRsn, and representations where disclosure permits — but omitted fields must never be replaced by invented values (§18.6). A machine-readable error response should use application/problem+json with a stable code drawn from the eight logical statuses — a SHOULD, not a SHALL.

The most consequential row is forbidden. A restricted identity is still an identity, but announcing that it exists can itself be a disclosure. Unless policy permits acknowledging it, the gateway answers with the same 404 it would give a nonexistent identity, and must not reveal the difference through timing, headers, bodies, redirects, or caches where reasonably controllable. The resolver demonstration shows the exchange for its restricted sample alongside an unknown RID so the two can be compared. It also shows that deprecated and reserved are not resolution statuses: a deprecated identity may resolve with 200 and a deprecation notice, and a reserved one returns a limited record that must not imply an active resource.

Document 09 turns the profile into practical guidance, and one of its points describes this very website. The proposed public pattern is https://rsmid.org/<rid>; Document 08 lets a documentation site share that host with a resolver through path routing, provided valid RID root paths are reserved and not shadowed once resolver service is enabled (§18.5), and Document 09 adds that a site without an operational resolver must not fabricate resolution. That is why RID paths on this site return a plain 404 with an explanation instead of a page that looks like resolution.

The simulation follows the same mapping the profile describes, computed in one module, but Document 08 is explicit that an educational simulation does not count as conformance evidence for a production resolver (§18.10). Where the specification is still silent — for example, which status an unregistered prefix should produce — the demonstration says so rather than choosing quietly.

Conclusion: build each part to its own contract

Taken apart, RSM ID is seven contracts that stay out of each other's way. The RID identifies and carries nothing else. The RRN names and records context, under a grammar that refuses to repair input. The RSN is an RRN for a space that has its own identity. The Identity Record remembers issuance, names, lifecycle, and bindings without holding the resource. The registries separate namespaces, authorities, identities, and spaces. Issuance authority is proven, auditable, and never ownership. Resolution consults all of them and reports what it found as a typed status with a defined wire form.

For implementers, that suggests an order of work that Document 09 also recommends: a pure, deterministic identity and naming library with shared fixtures; a registry that commits issuance atomically with an append-only history; a resolver whose status mapping lives in one place; and only then federation across spaces. Each layer can be tested on its own because its contract does not depend on the others' internals.

The next Journal, From Identity to Federation, follows one resource across independently governed Semantic Spaces to show how these contracts let organizations share references without sharing databases. If you would rather start from the beginning, Why Persistent Identity Matters sets out the problem the architecture solves, and the Viewgraph on the anatomy of an Identity Record draws the record in a single frame.