RFC-0001: XRN (eXtended Resource Name) Specification
InnoFabric RFC Series — Part of the InnoFabric Standards Track
Status: Draft 01
Version Date: 2026-02-24
Intended Status: Proposed Standard
Authors: InnoFabric Working Group (IWG-CloudId)
ISC Reviewer: TBD
Abstract
This document specifies XRN (eXtended Resource Name), a canonical, provider-neutral identifier model designed for consistent use across the Control and Substrate architectural layers.
XRN provides a globally coherent, structured naming scheme that enables deterministic parsing, comparison, validation, and lifecycle traceability for logical resources, runtime abstractions, and physical assets. It is intended to serve as a stable identity layer for software systems that manage, observe, and orchestrate resources across the Control, Substrate, and Hardware layers.
XRN is intentionally minimal. It defines only the identifier format, syntax rules, and normalisation requirements for globally unique resource identifiers. It does not prescribe how identifiers are consumed, stored, or acted upon. Platform-specific systems and frameworks define their own domain-specific semantics, relationships, and workflows on top of the XRN model.
The XRN model supports reversible mappings from existing provider-native identifiers, allowing existing systems to adopt XRNs without restructuring their internal identity schemes. This enables consistent identity handling across heterogeneous Control and Substrate environments, improves auditability and traceability, and supports robust interoperability between independently developed systems.
XRN can be embedded into higher-level metadata or federation frameworks when required, but its primary purpose is to provide a coherent, precise, and machine-reliable identity foundation for federated, multi-provider infrastructure systems.
Status of This Memo
This document is part of the InnoFabric RFC Series, which defines vendor-neutral technical specifications for consistent and interoperable infrastructure and control software.
This specification defines the XRN identity model only. It standardises the syntax, structure, and normalisation rules for XRN identifiers, but does not define platform-specific usage, domain bindings, or operational semantics. Such usage is specified in separate documents, including RFC-0002: XRN Usage within InnoFabric.
This document is currently published as a Draft. Its contents are subject to revision until the status is updated to Final. Contributions, discussion, and reference implementations are welcomed via the official GitHub repository.
https://github.com/innofabric/rfcs
Contents
1. Introduction
The eXtended Resource Name (XRN) defines a globally unique, structured, and machine-parseable identifier for resources across Control, Substrate, and Hardware layers, ensuring consistent identity across logical, runtime, and physical domains.
XRN provides deterministic identity, traceability, and reversibility across multiple providers while maintaining a strict architectural separation between physical assets, runtime realisation, and logical intent.
XRNs combine human readability with stable, deterministic parsing, and serve as the canonical reference for Control-layer intent, Substrate-layer runtime objects, and Hardware-layer assets.
They are comparable in purpose to cloud-native identifier schemes such as AWS ARNs and Azure Resource IDs — providing a single, unambiguous resource naming model that supports policy evaluation, audit correlation, and cross-system resolution. XRN is designed explicitly for high consistency across implementations and for use in federated, sovereign, and open infrastructure environments.
The design aligns with Europe’s emphasis on digital sovereignty, transparent governance, and multi-provider federation. XRNs enable unified interoperability across independent providers, research institutions, and national cloud capabilities—avoiding vendor lock-in while supporting compliance with frameworks such as Gaia-X, EUCS, and emerging digital infrastructure sovereignty standards.
Each XRN provides:
- Global uniqueness — Every resource receives a deterministic identifier derived from its provider, domain, partition, region, and resource class.
- Interoperability — Common normalisation rules ensure consistent parsing across independent implementations.
- Reversibility — XRNs can be mapped back to provider-native identifiers through registry-based resolution.
- Federation support — Designed for cross-provider discovery, compliance validation, and federated governance.
XRNs form a foundational identity layer for modern infrastructure systems. A unified, canonical identifier model is essential: without XRN, hyperscaler-scale automation, cross-provider orchestration, and end-to-end lifecycle traceability are not achievable.
1.1 Rationale for Rigid Naming
XRN is designed to enable deterministic interoperability between software components operating across multiple architectural layers, providers, and administrative domains.
Modern infrastructure systems consist of independently developed control-layer software, substrate-layer systems, and hardware management domains that must interact reliably without shared internal state or proprietary coupling. A consistent, formal naming scheme is therefore required to ensure:
- Deterministic interoperability between software components across layers
- Unambiguous cross-system and cross-registry resolution
- Reliable provenance tracking and lifecycle traceability
- Robust federation, compliance, and sovereignty enforcement
- Full automation of orchestration, policy evaluation, and attestation flows
Without rigid, globally normalised identifiers, distributed systems cannot reliably reason about resource identity, ownership, scope, or authority. Ambiguity in naming directly undermines trust, automation, and compliance, particularly in federated and multi-provider environments.
XRNs therefore constitute a stable identity foundation beneath higher-order orchestration, governance, and trust mechanisms. They provide a common, machine- reliable reference model that allows heterogeneous control and substrate systems to interoperate deterministically while preserving strict architectural separation.
1.2 Context
This specification distinguishes between three strictly separated architectural layers,
each with a clear responsibility and lifecycle. The layers are identified using
canonical XRN words and described using human-readable architectural terms.
The XRN words are normative and appear directly in XRNs.
| XRN word | Term | Function | Examples |
|---|---|---|---|
control | Control layer | Tenant-scoped logical resources defining intent, policy, and configuration. Objects in this layer are stable and long-lived. | Autoscaling groups, workload definitions, load balancers, policies, certificates, DNS zones. |
substrate | Substrate layer | Provider-managed runtime and placement layer that realises Control-layer intent through indirection over hardware. Objects in this layer are movable, AZ-scoped, and dynamically allocated. | Compute slots, load-balancer listeners, workload instances. |
hw | Hardware layer | Immutable physical assets operated by the provider. These objects represent real-world equipment and have fixed physical identity. | Physical hosts, racks, PDUs, switches, NICs. |
The Control layer defines identity, intent, and desired state, independent of runtime placement and physical realisation.
The Substrate layer is the sole domain responsible for translating Control-layer intent into concrete runtime realisation. It operates strictly above Hardware and never exposes direct hardware identity to the Control layer.
The Hardware layer consists exclusively of immutable physical assets and is not addressable by tenant-scoped logic.
XRNs unify these layers under a single identity model while preserving their strict architectural separation.
Each XRN MAY be associated with an entry in a registry system.
1.3 Human Readability and Interface Integration
XRNs are designed for both machine and human interfaces, and are suitable for:
- CLI tools, dashboards, and logs
- REST, gRPC, or GraphQL APIs
- Configuration management and Infrastructure-as-Code systems
- Audit trails and compliance subsystems
The colon-delimited syntax provides natural hierarchical readability while remaining URI-safe for embedding in URLs and structured documents.
Examples:
xrn:nimbus:control:public:eu-cph-1:tenant-001:autoscaling.group:018f3b70-9a2d-7d44-8b2f-1c3d9e5f7a11
xrn:nimbus:substrate:public:eu-cph-1:az1:tenant-001:instance.workload:018f3b78-2a1c-7f11-9a02-9d3c6b1a0f55
xrn:nimbus:substrate:core:eu-cph-1:az1:-:compute.slot:018f3b7e-2c34-7d56-8e78-334455667788
XRNs can be validated, resolved, and referenced across Control, Substrate, and Hardware domains, enabling deterministic interoperability, full lifecycle traceability, and automation at hyperscaler scale.
2. Terminology and Conventions
The following terms and conventions apply throughout this specification:
| Term | Meaning |
|---|---|
| XRN | eXtended Resource Name. The canonical identifier for any registered resource. |
| Provider | The organisation or operator responsible for issuing and managing XRNs within its namespace. |
| Domain | The top-level architectural layer of a resource: control for identity and intent, substrate for runtime realisation, and hw for physical assets. |
| Partition | A provider-specific sovereignty or operational boundary (e.g., core, public, gov). |
| Region | A geographical or logical resource grouping defined by the provider (e.g., eu-n1, us-w2). |
| AZ | Availability Zone. A provider-defined logical placement and failure domain within a region. AZs are required for substrate domain XRNs and MUST NOT appear in control or hw domain XRNs. |
| Tenant | An external authority or logical namespace. Mandatory in control domain XRNs. In the substrate domain, the tenant field is positionally present and indicates the originating authority context for runtime objects; for provider-intrinsic substrate objects, the tenant field MUST be set to the reserved token - (meaning “not applicable”). |
Tenant sentinel (-) | Reserved token used in the substrate domain tenant field to indicate “not applicable” for provider-intrinsic objects. The token - MUST NOT be used as a tenant identifier. |
| Type | Resource class identifying the semantic category of the resource. |
| ID | Provider-defined opaque identifier for a resource instance. The character / is permitted inside the identifier. |
| Subpath | Optional hierarchical breadcrumb providing fine-grained component identification within a resource. |
| Registry | A catalog or inventory system used to support validation, lookup, or interpretation of XRNs. |
Conventions:
- The keywords MUST, SHOULD, and MAY are to be interpreted as described in RFC 2119 and RFC 8174.
- XRNs are case-normalised according to Section 6 (Normalisation and Encoding).
- Examples in this document are illustrative unless explicitly stated otherwise.
Further sections
The remainder of the current working draft is not included in this published extract.
Additional sections covering the later specification material have been omitted for the present web version.
For access to the fuller draft or to participate in the InnoFabric IWG, please use the Participate in InnoFabric page.
15. Acknowledgments
The editors thank the InnoFabric contributors for their reviews, implementation feedback, and practical use cases.
Their insights and testing experience helped shape the XRN specification into a pragmatic, provider-agnostic standard suitable for real-world deployment across federated and multi-provider environments.
Appendix A. Change Log
Document notable editorial and normative changes between drafts.
| Version | Date | Summary |
|---|---|---|
| Draft 01 | 2026-02-21 | Initial version |
Appendix B. Status and Metadata
This RFC follows the conventions defined in RFC-0000: InnoFabric RFC Process, including stable filenames, header-based versioning, and Git-based draft tracking.
© EUCLORA AISBL 2026 – present
Licensed under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence.