Secure Resource Layer (SRL) Core
draft-zerobankx-srl-core-02

Internet-Draft                                      Yoshio Murofushi
Intended status: Informational                ZEROBANKX PTE. LTD.
Expires: 27 June 2026                               January 27, 2026

                 Secure Resource Layer (SRL) Core
                   draft-zerobankx-srl-core-02

Abstract

   This document defines the Secure Resource Layer (SRL), a global trust
   layer that evaluates 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, browsers, or operating
   systems.

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.

   SRL enables pre-reference verification, in which a referenced resource
   is evaluated before any redirection or access occurs.

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.

   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.

   Pre-Reference Verification:
      A process by which a referenced digital resource is evaluated for
      trust, governance, and revocation status before any user-initiated
      access or redirection occurs.

   Trust Signal:
      A human- and machine-readable output produced by SRL or SRP
      indicating whether a resource is safe to proceed (e.g., SAFE or
      NOT SAFE), and optionally why.

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
   - Operational deployability in existing environments (resolver-first)
   - Clear safety signaling for end users and operators

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.

   SRL allows a resolver to return either:
   (a) a proceed decision with a resolved URL, or
   (b) a stop decision that prevents access and provides a trust signal.

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.

   Note: These checks are performed before the reference is opened and do
   not require changes to existing QR codes, URLs, or operational
   workflows.

4.2. Deployment Model (Informative)

   SRL is intended to be deployable without changes to existing Internet
   protocols, browsers, or operating systems.

   Typical SRL deployments include:
   - Resolver-based verification prior to redirection (network or cloud)
   - Scanner-level verification for QR code capture flows
   - Application-level verification for link previews and in-app browsers

   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:
   - status (MUST)
   - resolved_url (MAY)
   - expires_at (MAY)
   - issuer_verified (MUST)
   - revocation_checked (MUST)

   The "status" field indicates the trust decision. Common values include:
   - valid
   - not_verified
   - revoked
   - expired
   - blocked
   - error

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.

5.7. Human-readable Trust Signal (Informative)
   An SRP responder MAY provide a human-readable trust signal for display.
   Such signals are informational and do not replace policy decisions.

   Examples include:
   - SAFE
   - NOT SAFE

   Such signals are intended to reduce operator error and improve
   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.

   A positive trust decision indicates that SRL checks (issuer,
   governance, and revocation) have been evaluated under the deployment's
   policy. It does not guarantee the safety of the content itself and
   does not replace malware scanning or endpoint security.

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.

   Registries maintain issuer identity and governance assertions.
   Resolvers enforce policy decisions based on registry data and local
   rules.

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.

   Revocation MAY be represented as:
   - immediate revocation (deny)
   - time-based expiration (deny after time)
   - conditional revocation (deny under conditions such as region,
     channel, or incident response policies)

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.

   SRL reduces risks caused by mistaken references, including opening
   phishing links, poisoned redirects, or outdated operational
   instructions.

   SRL does not mandate a single global trust authority and is compatible
   with local or federated policy decisions.

10. Privacy Considerations

   SRL minimizes the collection of personal data.

   SRP requests SHOULD avoid including user-identifiable information.
   Deployments SHOULD minimize logging and apply appropriate data
   retention limits.

11. Use Cases

   SRL supports consumer web navigation, creator economies, medical
   information distribution, public administration, and platform-level
   link mediation.

   SRL is suitable for environments where operational mistakes are
   costly, including terminals, logistics, education, healthcare, and
   finance, because verification occurs before access and can be
   integrated into existing workflows.

12. IANA Considerations

   This document has no IANA actions.

13. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119.
   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", RFC 8174.
   [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
             Interchange Format", RFC 8259.

14. Future Work

   Future specifications MAY define cryptographic signing, issuer-bound
   keys, and interoperability with existing PKI systems, while
   preserving resolver-first deployability for early adoption.

Authors' Addresses

   Yoshio Murofushi
   ZEROBANKX PTE. LTD.
   Email: fin.zerobankx@gmail.com