| Internet-Draft | LinkID URI | August 2026 |
| Nyffenegger | Expires 23 February 2027 | [Page] |
This document specifies the "linkid" URI scheme and a resolution model for persistent, location-independent identifiers. A LinkID identifies a resource independently of its current network location. Resolution maps the persistent identifier to a current actionable URI using one or more resolvers. The scheme is intended for Web, document, archival, scientific, government, enterprise, and machine-to-machine references where locations may change while reference identity must remain stable.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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.¶
linkid-URI = "linkid:" linkid-id [ "?" query ] [ "#" fragment ] linkid-id = linkid-seg *( "/" linkid-seg ) linkid-seg = 1*( unreserved / pct-encoded / sub-delims / ":" )¶
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.¶
linkid:00c538ea-846b-47a6-a3d4-70a9ebd29d7c linkid:doc:acme/handbook/2026/section-3 linkid:doi:10.1234/example#methods linkid:media:images/product-42?v=2 linkid:archive:ch.admin/finrep/2026/Q4¶
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.¶
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.¶
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.¶
The following use cases illustrate general utility of the scheme; they do not restrict its use.¶
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.¶
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.¶
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.¶
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.¶
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.¶