Internet-Draft Yoshio Murofushi Intended status: Informational ZEROBANKX PTE. LTD. Expires: 27 June 2026 January 10, 2026 Secure Resource Layer (SRL) Core draft-zerobankx-srl-core-01 Abstract This document defines the Secure Resource Layer (SRL), a global trust layer that verifies digital resources before they are accessed. SRL introduces governance, verification, and revocation mechanisms that complement existing URL, QR code, and short URL systems. SRL is designed to be deployable incrementally and is already being validated through live resolver deployments without requiring changes to existing Internet standards. 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". 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. 1. Introduction URLs, QR codes, and short URLs are widely used to reference digital resources. However, these mechanisms provide no native way to verify whether a referenced resource is trustworthy, revoked, or still valid at the time of access. As a result, users and platforms face increasing risks, including phishing, malicious redirects, outdated links, and the distribution of unsafe or unauthorized content. Despite widespread use of URLs and QR codes, the Internet currently lacks a standardized mechanism to express trust, governance, or revocation at the reference layer itself. Responsibility for link safety is fragmented across applications, platforms, and proprietary services, resulting in inconsistent security outcomes and limited accountability. Secure Resource Layer (SRL) introduces a reference-layer trust model that operates independently of transport protocols and application platforms. SRL enables verification, governance, and revocation of digital resources before they are accessed, while remaining backward compatible with existing Internet mechanisms. This document defines the core concepts and architecture of SRL. 2. 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. SRL: Secure Resource Layer. SRP: Secure Resolution Protocol. Resource Identifier: An identifier referencing a digital resource. Issuer: An entity that registers or publishes a resource. Verifier: A component that validates SRL information. Registry: A system that maintains trust and governance data. Revocation: The act of invalidating a previously trusted resource. 3. Design Goals SRL is designed with the following goals: - Platform and vendor neutrality - Backward compatibility with existing Internet mechanisms - Minimal disclosure of user information - Explicit governance and accountability - First-class support for revocation 4. Architecture Overview SRL operates as a logical layer between resource references and resource access. Client | | URL / QR / Short URL v SRP Resolver | v Secure Resource Layer (SRL) | v Trust Registry / Verification / Revocation The architecture is implementation-agnostic and does not mandate a specific transport, programming language, or cryptographic mechanism. 4.1. Integration with Short URLs and QR Codes SRL is designed to integrate seamlessly with existing short URL and QR code mechanisms, including managed short URL systems. Trust validation, governance, and revocation are handled entirely by SRL prior to resource access. The QR code or short URL itself remains unchanged. 4.2. Deployment Model (Informative) SRL is intended to be deployable without changes to existing Internet protocols, browsers, or operating systems. Typical deployments include resolver-based validation prior to redirection, platform-level verification for QR code scanners, and application-level trust checks for link previews. An SRL deployment MAY operate as a local resolver, a network service, or an embedded component within an application. 5. Secure Resolution Protocol (SRP) Secure Resolution Protocol (SRP) enables clients to query SRL for trust and validity information before accessing a resource. SRP is transport-agnostic and MAY be carried over HTTPS, local inter-process communication, or other suitable mechanisms. 5.1. Protocol Model SRP follows a request/response model. A client submits an SRP Request containing a resource identifier and optional metadata. SRL returns an SRP Response containing a trust decision. 5.2. Message Encoding SRP messages are encoded using JSON [RFC8259] and MUST support UTF-8. 5.3. SRP Request Message An SRP Request is a JSON object containing the following fields: srl_version (MUST), resource_id (MUST), issuer (SHOULD), timestamp (SHOULD), nonce (SHOULD), requested_action (MAY). 5.4. SRP Response Message An SRP Response includes a status (MUST), resolved_url (MAY), expires_at (MAY), issuer_verified (MUST), and revocation_checked (MUST). 5.5. Error Handling If an SRP Request cannot be processed, SRL SHOULD return an SRP Response with an appropriate status value. 5.6. Security Considerations for SRP The absence of mandatory cryptographic signing in the current SRP design is an intentional design decision to prioritize deployability and early adoption. 6. Secure Resource Layer (SRL) SRL evaluates SRP requests and determines the trust status of the referenced resource. SRL explicitly separates resource trust from resource access. A positive trust decision does not imply endorsement of content, only that governance, issuer identity, and revocation status have been evaluated. SRL MAY return trust decisions such as valid, revoked, expired, unknown, or blocked. Policy decisions MAY vary by deployment environment. SRL does not require modification of the underlying resource, URL, or QR code. 7. Trust Registry and Governance SRL relies on registries that maintain issuer information, trust status, and governance rules. Registries MAY be centralized, federated, or distributed. Specific governance policies are intentionally out of scope for this document and may be defined by individual deployments. 8. Revocation Model Revocation is a core feature of SRL. Supported models include immediate revocation, time-based expiration, and conditional revocation. Revocation information MUST be retrievable by verifiers in a timely manner. 9. Security Considerations SRL mitigates threats including phishing, redirect poisoning, replay attacks, and reference-layer spoofing. SRL complements, but does not replace, transport-layer security such as TLS. SRL trust decisions do not constitute an endorsement or certification of the referenced content. 10. Privacy Considerations SRL minimizes the collection of personal data. SRP requests SHOULD avoid including user-identifiable information. 11. Use Cases SRL supports consumer web navigation, creator economies, medical information distribution, public administration, and platform-level link mediation. 12. IANA Considerations This document has no IANA actions. 13. Normative References [RFC2119] Bradner, S., RFC 2119. [RFC8174] Leiba, B., RFC 8174. [RFC8259] Bray, T., RFC 8259. 14. Future Work Future specifications MAY define cryptographic signing, issuer-bound keys, and interoperability with existing PKI systems. Authors' Addresses Yoshio Murofushi ZEROBANKX PTE. LTD. Email: fin.zerobankx@gmail.com