Internet-Draft Yoshio Murofushi Intended status: Informational ZEROBANKX PTE. LTD. Expires: 31 January 2027 July 30, 2026 Secure Resource Layer (SRL) Core draft-zerobankx-srl-core-03 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, barcode, RFID, and short URL systems. SRL is designed to be deployable incrementally through resolver-based, scanner-level, reader-level, and application-level integrations, without requiring changes to existing Internet standards, browsers, operating systems, or identifier formats. This revision extends the document with implementation testing and operational validation of hybrid resource identifiers in logistics and supply-chain environments. The testing combines QR codes, barcodes, and RFID-derived identifiers under a common SRL trust framework while preserving compatibility with existing operational 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. Physical Identifier: A machine-readable identifier attached to, embedded in, or associated with a physical object. Examples include QR codes, barcodes, and RFID tags. RFID-derived Identifier: A Resource Identifier obtained from an RFID tag identifier or from data encoded in an RFID tag by an RFID reader. Hybrid Resource Identifier: A Resource Identifier that can be represented or obtained through more than one identifier technology, such as a QR code, barcode, or RFID tag. Identifier Binding: An association between a Physical Identifier and the Resource Identifier evaluated by SRL. 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 identifiers and resource access. Client / Scanner / Reader | | URL / QR / Barcode / RFID-derived Identifier / 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, identifier technology, or cryptographic mechanism. SRL allows a resolver to return either: (a) a proceed decision with a resolved URL or resource reference, or (b) a stop decision that prevents access and provides a trust signal. 4.1. Integration with Existing Identifier Technologies SRL is designed to integrate with existing URL, short URL, QR code, barcode, and RFID systems. Trust validation, governance, and revocation are handled by SRL before the referenced digital resource is accessed. The existing identifier format MAY remain unchanged. A QR code or barcode MAY directly encode a Resource Identifier. An RFID deployment MAY derive a Resource Identifier from a tag identifier or from data encoded in the tag. The resulting Resource Identifier is then evaluated through SRP. SRL does not assume that an RFID tag directly contains a URL. The mapping between a Physical Identifier and a Resource Identifier is an implementation-specific Identifier Binding. 4.2. Deployment Model (Informative) SRL is intended to be deployable without changes to existing Internet protocols, browsers, operating systems, or identifier formats. Typical SRL deployments include: - Resolver-based verification prior to redirection - Scanner-level verification for QR code and barcode capture flows - Reader-level verification for RFID-derived identifiers - Application-level verification for link previews and in-app browsers - Enterprise integration with logistics and warehouse systems An SRL deployment MAY operate as a local resolver, a network service, an embedded application component, or an integration component connected to scanners, RFID readers, or enterprise systems. 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. In hybrid identifier deployments, additional threats include copied barcodes, duplicated QR codes, cloned RFID identifiers, unauthorized identifier-to-resource substitution, compromised readers, and incorrect Identifier Bindings. SRL can evaluate governance, issuer identity, binding status, and revocation information associated with a Resource Identifier. However, SRL alone does not prove the physical authenticity of a tag or object and does not replace tamper-resistant hardware, reader security, anti-cloning controls, or physical inspection. SRL trust decisions do not constitute an endorsement or certification of the referenced content or physical object. SRL reduces risks caused by mistaken references, including opening phishing links, following poisoned redirects, or using 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. RFID and other persistent Physical Identifiers can enable tracking when the same identifier is observed across locations or over time. Deployments SHOULD avoid binding persistent identifiers directly to individuals unless required by the application and supported by an appropriate privacy policy. Logs containing identifier observations, reader locations, timestamps, or shipment information SHOULD be treated as potentially sensitive. Access controls, retention limits, and data minimization SHOULD be applied. 11. Use Cases SRL supports environments in which digital resource verification occurs before operational actions are performed. This revision focuses on implementation testing of Hybrid Resource Identifiers in logistics and supply-chain environments. The testing combines QR codes, barcodes, and RFID-derived identifiers while using SRL as a common trust framework. By operating above the identifier technology, SRL can evaluate the associated Resource Identifier independently of whether that identifier was obtained from a QR code, barcode, RFID tag, URL, or short URL. Representative test scenarios include transportation, warehouse management, shipment verification, inventory management, distribution management, and food supply-chain operations. 11.1. Hybrid Identifier Validation Implementation testing evaluates how QR codes, barcodes, and RFID tags can refer to the same or related digital resources through Identifier Bindings. A scanner or reader obtains a Resource Identifier directly from an encoded value or indirectly through an implementation-specific mapping. The Resource Identifier is then submitted to an SRP resolver before the referenced digital resource is accessed or used in an operational workflow. The testing evaluates whether multiple identifier technologies can be processed through a common SRL trust layer without changing existing identifier formats. Verification targets may include: * Issuer identity * Identifier Binding status * Resource validity * Revocation status * Expiration status * Applicable governance policy 11.2. Hybrid Identifier Implementation One implementation under evaluation is OPENQR REID. OPENQR REID combines QR codes, barcodes, and RFID technologies within a common SRL-based trust architecture. It is an implementation example and is not required for conformance with SRL or SRP. The identifier technology remains independent from SRL. A deployment may use one or more identifier technologies, provided that the resulting Resource Identifier can be evaluated through SRP. This model allows heterogeneous identifier technologies to coexist while preserving compatibility with existing scanners, readers, enterprise applications, and operational workflows. 11.3. Logistics and Supply-Chain Testing SRL is being tested in logistics and supply-chain environments where a digital resource is evaluated before an operational action is performed. Representative test targets include: * Transportation instructions * Shipment records * Warehouse records * Inventory information * Delivery records * Distribution instructions * Product traceability information * Food supply-chain records The tests are designed to evaluate integration with existing logistics platforms, warehouse management systems, transportation systems, QR code infrastructure, barcode systems, and RFID deployments. 11.4. Identifier Resolution Flow A representative hybrid identifier flow is: 1. A scanner or reader captures a QR code, barcode, or RFID tag. 2. The implementation obtains or derives a Resource Identifier. 3. The client submits an SRP Request to an SRP resolver. 4. SRL evaluates issuer, governance, Identifier Binding, validity, expiration, and revocation information. 5. The resolver returns a trust decision. 6. The operational system proceeds, stops, or requests additional verification according to local policy. The SRL trust decision is independent of the physical scanning or reading technology. 11.5. Incremental Deployment Existing logistics systems, warehouse management systems, transportation platforms, QR codes, barcodes, RFID infrastructure, URLs, and enterprise applications MAY remain unchanged. SRL introduces an additional trust evaluation before the referenced resource is accessed or used. Integration can therefore be performed incrementally at the resolver, scanner, reader, application, or enterprise integration layer. 11.6. Implementation Test Scope Current implementation testing includes: * QR code, barcode, and RFID-derived identification * Identifier Binding and resolution * Transportation and warehouse workflows * Shipment and inventory verification * Food supply-chain workflows * Resolver-based pre-reference verification * Revocation and expiration handling The testing is intended to determine whether SRL can be introduced without modifying existing Internet standards, browsers, operating systems, identifier formats, or enterprise logistics platforms. This section summarizes the current scope of implementation testing. Future revisions may extend these results as additional operational validation becomes available. 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 stronger cryptographic binding between Physical Identifiers and Resource Identifiers, reader attestation, anti-cloning mechanisms, and additional interoperability profiles. Future revisions may report implementation-test results and extend validation to education, digital ticketing, healthcare, manufacturing, industrial IoT, public-sector resource management, and other operational environments. Authors' Addresses Yoshio Murofushi ZEROBANKX PTE. LTD. Email: fin.zerobankx@gmail.com