Seednote

Resolver

From an identifier to permitted information

Connects identifiers to verified, policy-permitted identity information and available representations.

RSM ID Learning Center2 min read

A resolver accepts an identifier and returns what is trustworthy and permitted about the identity it names. The primary input is a canonical RID; a registered RRN or RSN, or an HTTPS identifier on an approved host, is first mapped to its RID. The resolver then validates the RID, verifies the prefix and the authority, locates the Identity Record, evaluates lifecycle and disclosure policy, selects a representation, and returns metadata, a representation, a permitted redirect, or a typed status.

Any conforming resolver with access to trusted registry information may resolve an RID. A public gateway is a convenience and an interoperability point, not the sole authority over every resource, and the RID does not change with the gateway that answers for it.

Example

Asking a conforming gateway for GET /451.7K4M9Q2X8D5P0R6T with Accept: application/json would return an identity response carrying at least the RID, kind, identity status, and resolution status. The demonstration resolver shows each stage and the response a gateway would give, labelled as simulated.

A common misconception

“Running a resolver makes you the authority.” A resolver must verify authority, not assert it. It must not accept an endpoint's own claim as proof, follow unverified endpoints, or forward credentials to them; when trust cannot be established, the honest answer is untrusted.

The resolver reads the Identity Record and applies the identity lifecycle. Why this is more than fetching a file is the subject of a Fieldnote, and the resolution sequence draws every step.

In the specification

Inputs: Document 08 §6.2. Logical sequence: §6.3. Portability: §6.10. Status-to-HTTP mapping: §18.7.