The LinkID URI Scheme and Resolution Model

Status of This Memo

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 11 April 2027.¶

Copyright Notice

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.¶

Table of Contents

1. Introduction

Hyperlinks commonly couple resource identity to a current network location. When domains, paths, repositories, content-management systems or hosting infrastructure change, references fail even though the referenced resource may still exist.¶

LinkID separates persistent identity from mutable location. The core invariant is: identity is persistent, location is mutable, and resolution is the controlled mapping between the two.¶

Persistence is not a purely technical property. HTTP(S) URIs can be highly persistent when managed responsibly, and any persistent identifier system can fail if the organization behind it disappears. This document therefore does not claim that indirection alone guarantees persistence. It aims to ensure that a LinkID and its authorized mapping survive changes of custody and hosting, by separating identifier syntax from resolver operation.¶

LinkID does not replace HTTP(S) or existing persistent identifier systems; see Section 8.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

LinkID:

A persistent identifier expressed using the "linkid" URI scheme.¶

Identifier authority:

The party authorized to maintain a LinkID's mapping and associated records. Authority is established independently of the UUID text; it is not encoded in the identifier.¶

Resolver:

A service or software component that maps a LinkID to a resolution result.¶

Resolution result:

The authorized current mapping and lifecycle status for a LinkID returned by a resolver (Section 5.2).¶

Actionable URI:

A URI in a resolution result that a client can use to access or interact with the identified resource.¶

3. URI Scheme Syntax

The syntax is specified using ABNF [RFC5234]; HEXDIG is imported from that specification. The UUID text representation is defined by [RFC9562].¶

linkid-URI = "linkid:" uuid
uuid       = 8HEXDIG "-" 4HEXDIG "-" 4HEXDIG "-"
             4HEXDIG "-" 12HEXDIG

A LinkID URI has no authority, namespace, path, query or fragment component. Whitespace, percent-encoded characters, braces and suffixes are not permitted.¶

The scheme name is case-insensitive [RFC3986], and UUID hexadecimal text is case-insensitive [RFC9562]. Producers MUST emit the complete URI in lowercase. Consumers MUST accept either case. Two LinkIDs are equivalent if and only if their UUID values are equal. Lowercasing a conforming LinkID yields its canonical form. Canonicalization MUST NOT turn a non-conforming string into a LinkID by discarding characters.¶

Matching the grammar does not establish that the UUID was allocated, that a resource exists, or who controls it.¶

linkid:00c538ea-846b-47a6-a3d4-70a9ebd29d7c

4. Identifier Semantics

A LinkID identifies a resource; it does not encode the resource's network location. 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.¶

One LinkID has one persistent identity. Multiple target addresses, historical addresses, language or format variants, and authorized fallback addresses can be associated with it without creating alternative identifier forms. Changing an address or transferring stewardship does not create a new identity; a resource version that is identified separately receives its own UUID.¶

A resolver MUST NOT select an unrelated resource merely because it is reachable. Automatic recovery does not override the authority governing the original mapping.¶

Successful resolution establishes the currently authorized mapping. It does not establish that destination content is safe, correct, trustworthy or unchanged.¶

5. Resolution Model

A client resolves a LinkID by validating it against Section 3, selecting a resolver, requesting the resolution result, validating that result, applying local policy, and returning or navigating to the actionable URI.¶

A LinkID MUST NOT depend semantically on a single resolver operator: the meaning of a LinkID does not change when the resolver that serves it changes.¶

https://resolver.example/resolve/{identifier}

{
  "id": "linkid:00c538ea-846b-47a6-a3d4-70a9ebd29d7c",
  "status": "active",
  "target_url": "https://example.org/resource"
}

6. Resolution States

Resolvers SHOULD distinguish the following conditions where applicable.¶

An unknown LinkID MUST NOT be redirected to unrelated content. A revoked or tombstoned LinkID MUST NOT be reassigned.¶

7. Allocation and Governance

New LinkIDs MUST use UUID version 4 as defined in Section 5.4 of [RFC9562], with the random bits generated by a cryptographically secure random source. Random generation allows allocation by independent parties without coordination. Implementations MUST NOT knowingly allocate an assigned UUID to an unrelated resource; a detected collision MUST NOT overwrite the existing identity. Previously assigned identifiers MUST NOT be renumbered to satisfy this rule.¶

Registration agencies, enterprises and resolver operators can have separate responsibilities and allocation policies. These are administrative relationships associated with records, not subdivisions of the identifier.¶

A transfer of stewardship or hosting MUST NOT change an assigned UUID. It requires authorization and preservation of mapping provenance; changing a resolver address alone does not transfer control. Where continuity cannot be established, resolution fails safely rather than granting an unrelated operator authority. A service interruption does not prove that the resource has ceased to exist.¶

DOI, ARK, URN and Handle identifiers retain their own syntax and governance. An association with them is held in metadata or targets, not embedded in the LinkID.¶

Accreditation of resolver operators, service levels and dispute resolution are outside the scope of this document.¶

8. Relationship to Existing Identifier Systems

URNs [RFC8141]:

URNs provide persistent names within registered namespaces but do not define a general resolution mechanism. LinkID combines a persistent identifier with a defined resolution model.¶

Handle System and DOI [RFC3650] [ISO26324]:

DOIs resolve through the Handle System. LinkID does not replace DOI names or governance; a LinkID can be associated with a DOI-identified resource through its targets or metadata.¶

ARK [ARK]:

ARKs encode a Name Assigning Authority Number and use organization-operated resolvers. A LinkID does not encode an assigning authority.¶

PURL [PURL]:

PURLs are HTTP URIs redirected by a PURL server and bound to its domain. A LinkID is not bound to a resolver's domain.¶

9. Interoperability Considerations

10. Use Cases

Use cases include Web and domain migration; long-lived documents (PDF, office formats) with embedded references; enterprise knowledge systems; government, legal and public-record references; scientific publications and datasets; archives and custody transfer; machine-to-machine references; and tombstoning of resources that no longer exist.¶

11. Caching and Failure Handling

Resolution results MAY be cached according to HTTP caching [RFC9111]. Cached results MUST NOT be treated as authoritative after their freshness lifetime. HTTP freshness is not an assertion about identifier lifetime or destination health.¶

Clients and resolvers MUST detect and bound resolution and redirect loops. Failures MUST fail safely: a client MUST NOT guess a destination for an unknown LinkID.¶

12. Security Considerations

LinkID resolution introduces an indirection layer. Unauthorized modification of a mapping redirects every reference using the affected LinkID. Interfaces for updating records MUST be strongly authenticated and access controlled, and changes SHOULD be auditable.¶

Public resolvers MUST protect against resolver impersonation, mapping hijacking, open redirects, phishing, malicious destination schemes, denial of service, replay of stale records, identifier enumeration and resolution loops. Clients SHOULD restrict the schemes of actionable URIs they follow (for example to "https").¶

Resolvers that fetch or inspect destinations MUST defend against server-side request forgery, including requests to loopback, link-local, cloud metadata and internal addresses, and MUST account for redirects and DNS rebinding.¶

Misconfigured or compromised resolver configuration can misdirect lookups even though the LinkID is unchanged. Discovering an endpoint or a public key does not establish authority over an identifier. High-assurance deployments SHOULD protect the integrity of resolution results cryptographically; a common format is an open issue (Appendix B).¶

13. Privacy Considerations

Resolution requests reveal interest in particular resources. Resolver operators SHOULD minimize collection and retention of personal data and SHOULD publish their logging and retention policies. Public resolution SHOULD NOT require user authentication unless required by the resource or applicable policy.¶

A LinkID contains no credentials or resource names, but can become a correlatable reference when linked to personal information. Operators SHOULD NOT place secrets in public metadata or unnecessarily forward client information to targets.¶

14. IANA Considerations

The "linkid" URI scheme is registered in the "Uniform Resource Identifier (URI) Schemes" registry with Provisional status. This document requests that IANA update the registration as follows, in accordance with [RFC7595]. The syntax below narrows the previously registered syntax to the UUID form.¶

Scheme name:

linkid¶

Status:

Permanent¶

URI scheme syntax:

See Section 3.¶

URI scheme semantics:

See Section 4 and Section 5.¶

Encoding considerations:

ASCII only; no percent-encoding within the identifier.¶

Applications/protocols:

Persistent identification and resolution of Web, document, archival, scientific, government, enterprise and machine-to-machine resources.¶

Interoperability considerations:

See Section 9.¶

Security considerations:

See Section 12.¶

Contact:

Christian Nyffenegger <christian.nyffenegger@linkgenetic.com>¶

Change controller:

IETF <iesg@ietf.org>¶

Reference:

This document¶

No other IANA action is requested.¶

Appendix A. Implementation Status

This section is to be removed before publishing as an RFC.¶

This section records the status of known implementations at the time of posting, following [RFC7942]. The description is provided for the information of reviewers; inclusion does not imply endorsement by the IETF.¶

Organization:

Link Genetic GmbH¶

Implementation:

LinkID platform and public resolver (proprietary); client SDKs and this specification at https://github.com/Link-Genetic-Inc/lid¶

Licensing:

Platform and resolver: proprietary. SDKs: see the repository.¶

Contact:

christian.nyffenegger@linkgenetic.com¶

Coverage and maturity:¶

• Allocation: all identifier-creating paths, including DOI rescue and test data generation, generate UUID version 4 identifiers from a cryptographically secure source. Records allocated before this revision, including some with non-UUID identifiers, are retained and remain resolvable without renumbering.¶
• Resolution: a public JSON endpoint, /api/public/resolve/{identifier}, returns the members id (always in canonical form), status and target_url as defined in Section 5.3, and 400 invalid_identifier and 404 not_found. It additionally uses more specific errors: 403 region_blocked, 404 no_target and no_reachable_target, 410 for erased, expired, archived and inactive records, and 451 for suspended records. It returns further implementation-specific members (scheme, uuid, last_verified_at, registration_agency, version) and accepts legacy "lid:" input for compatibility. Separate browser routes redirect to targets.¶
• Multiple targets: the data model supports multiple, historical, language-specific and fallback targets per LinkID. A consistent target-selection algorithm across endpoints is not yet defined.¶
• Discovery and integrity: implementation-specific resolver descriptors and a signed record format exist under /.well-known/ paths. They are not registered under [RFC8615] and are not part of this specification.¶
• Federation: independently operated, interoperating resolvers have not yet been demonstrated.¶

Appendix B. Open Issues

The author seeks community input on:¶

1. Interoperable discovery of the authoritative resolver for a LinkID, given that the UUID carries no authority information (for example: configuration only, operator descriptors, a shared directory, or replication).¶
2. A signature format for resolution results and how clients establish trust in identifier-authority keys.¶
3. Which multi-target and lifecycle information should be exposed in an interoperable response, and how target selection (language, format, priority, fallback) should be described.¶
4. Representation of stewardship transfer and lifecycle history.¶
5. Transition handling for identifiers allocated under the broader syntax of the existing provisional registration and revision -00.¶
6. Which governance and operational aspects belong in an IETF specification and which in a separate operational framework.¶

Changes since -00

This section is to be removed before publishing as an RFC.¶

• Narrowed the syntax to "linkid:" followed by a UUID; removed non-UUID examples.¶
• Required UUID version 4 for new allocations, without renumbering existing identifiers.¶
• Separated identity from names, targets, versions, fallbacks and operator relationships.¶
• Defined resolver selection, the resolution result and an HTTPS binding aligned with the existing implementation.¶
• Added allocation, stewardship transfer and continuity rules.¶
• Added relationship to URN, Handle/DOI, ARK and PURL.¶
• Added interoperability considerations on existing uses of "LinkId" and contextual recognition (URI review feedback).¶
• Changed the change controller to the IETF.¶
• Added Implementation Status and Open Issues appendices; updated contact address and references.¶

Acknowledgments

The author thanks Ted Hardie for the URI review, and the participants in the uri-review and DISPATCH discussions and in the W3C TPAC 2025 breakout session for their feedback.¶

Author's Address