The LinkID URI Scheme and Resolution Model

Introduction Hyperlinks commonly couple resource identity to a current network location. When domains, paths, repositories, content-management systems, or hosting infrastructure change, references may fail even though the referenced resource still exists. LinkID separates persistent identity from mutable location. The core invariant is that identity is persistent, location is mutable, and resolution is the controlled mapping between the two.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

LinkID: A persistent identifier expressed using the "linkid" URI scheme.
Resolver: A service or software component that maps a LinkID to an authorized resolution result.
Actionable URI: A URI returned by resolution that a client can use to access or interact with the identified resource.
Authoritative Resolution Record: The authorized current mapping and associated metadata for a LinkID.

URI Scheme Syntax The scheme name is "linkid". Producers MUST emit the scheme name in lowercase. The scheme-specific identifier is case-sensitive unless an applicable namespace profile explicitly specifies otherwise. The productions "unreserved", "pct-encoded", "sub-delims", "query", and "fragment" are defined by RFC 3986. Generic clients MUST treat the identifier as opaque unless a recognized LinkID namespace profile defines additional semantics.

Examples

Identifier Semantics A LinkID identifies a resource; it does not directly encode the current network location of that resource. Once assigned, a LinkID MUST NOT be reassigned to an unrelated resource. The actionable URI associated with a LinkID MAY change without changing the LinkID. Successful resolution establishes the currently authorized mapping. It does not establish that destination content is safe, correct, trustworthy, or unchanged.

Resolution Model A client resolves a LinkID by parsing and validating the URI, selecting a trusted resolver, requesting the authorized resolution record, validating the result, applying local policy, and returning or navigating to the actionable URI. Resolver selection is intentionally separate from identifier syntax. Version 1 of this specification permits explicit local configuration, enterprise or application configuration, and implementation-defined default resolvers. A future specification may define interoperable resolver discovery. A LinkID MUST NOT depend semantically on a single resolver operator. Public Internet resolvers MUST provide authenticated HTTPS transport. HTTP redirection MAY be used for interactive Web compatibility, but LinkID resolution MUST NOT be defined solely as an HTTP redirect service.

Resolution States Resolvers SHOULD distinguish at least the following states: active, unknown, inactive, deprecated, revoked, tombstoned, temporarily-unavailable, policy-denied, and integrity-failure. An unknown LinkID MUST NOT be redirected to unrelated content. A revoked or tombstoned identifier MUST NOT be reassigned to an unrelated resource.

Use Cases The following use cases illustrate general utility of the scheme; they do not restrict its use.

Web and domain migration, where a resource moves while references remain unchanged.
PDF, Office, and other long-lived documents containing persistent references.
Enterprise knowledge systems, including content-management, document-management, and collaboration platforms.
Government, legal, policy, and public-record references that must survive infrastructure changes.
Academic and scientific references to publications, datasets, and research outputs.
Archives and digital preservation, including transfer of custody between organizations.
Machine-to-machine and API references where software requires a stable identifier independent of endpoint location.
Resource ownership or stewardship transfer between organizations without changing the persistent reference.
Tombstoning, where a resource no longer exists but its identifier and historical identity are preserved.
Content-integrity and content-drift workflows in which reachability and content continuity are evaluated separately.

Interoperability LinkID is designed to coexist with HTTP, HTTPS, DNS, CDNs, archives, DOI, Handle, ARK, document formats, content-management systems, APIs, databases, QR codes, browser extensions, and native protocol handlers. An HTTPS resolver representation is a transport-compatible representation of a LinkID and MUST NOT be confused with either the persistent identifier itself or the final actionable URI.

Caching and Failure Handling Resolution responses MAY be cached. Authoritative responses SHOULD provide an explicit validity period or cache policy. Cached data MUST NOT be treated as authoritative after its validity period expires. Clients and resolvers MUST detect and bound resolution, delegation, and redirect loops. Resolution failures MUST fail safely. A client MUST NOT guess a destination for an unknown identifier.

Security Considerations LinkID resolution introduces an indirection layer. Unauthorized modification of a mapping can redirect all references using an affected LinkID. Authoritative update interfaces MUST therefore be strongly authenticated and access controlled. Public resolvers MUST protect against resolver impersonation, mapping hijacking, unrestricted open redirects, phishing, malicious destination schemes, denial of service, replay of stale records, identifier enumeration, and resolution loops. Resolvers that fetch or inspect destinations MUST defend against server-side request forgery, including requests to loopback, link-local, cloud metadata, and policy-protected internal addresses, and MUST account for redirects and DNS rebinding. High-assurance deployments SHOULD support cryptographic integrity protection for resolution records. This version does not mandate a particular signature algorithm.

Privacy Considerations Resolution requests can reveal user interest in particular resources. Resolver operators SHOULD minimize collection and retention of personal data. Public resolution SHOULD NOT require user authentication unless required by the resource or applicable policy. LinkID values SHOULD NOT contain credentials, secrets, access tokens, or directly identifying personal information. Resolvers SHOULD avoid unnecessary forwarding of client information.

IANA Considerations The "linkid" URI scheme is currently registered in the IANA Uniform Resource Identifier (URI) Schemes registry with Provisional status. This document specifies the syntax, semantics, resolution model, interoperability, security, and privacy considerations for that existing registration. Subject to the applicable review and approval process, this document requests that IANA update the existing "linkid" registration to reference this specification and change its status from Provisional to Permanent.

Scheme name: linkid
Status: Permanent (requested)
Applications/protocols: Persistent identification and resolution for Web, document, archival, scientific, government, enterprise, and machine-to-machine resources.
Contact: Link Genetic GmbH <info@linkgenetic.com>
Change controller: Link Genetic GmbH, on behalf of the LinkID specification maintainers.
Reference: This document.