| Internet-Draft | `s://` as a Secure URL Scheme | January 2025 |
| Ranalvi | Expires 28 July 2025 | [Page] |
This document proposes the introduction of `s://` as a universal shorthand for secure URLs, replacing the explicit use of `https://`. The proposed scheme simplifies URL syntax, assumes secure connections by default, and aligns with the modern web's security-first approach. The adoption of `s://` is expected to enhance user experience, improve efficiency, and reinforce secure practices across the internet.¶
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 28 July 2025.¶
Copyright (c) 2025 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.¶
URLs are a foundational element of the internet, allowing users to locate resources using protocols such as HTTP, HTTPS, and FTP. In recent years, HTTPS adoption has grown significantly, driven by security concerns and performance improvements offered by TLS [RFC8446]. Despite this shift, URLs still explicitly distinguish between `http://` (insecure) and `https://` (secure). This explicit declaration is redundant in a web environment where security should be the default [RFC9110]. This document proposes the introduction of `s://` as a shorthand for secure URLs, simplifying the syntax and reinforcing the norm of secure connections.¶
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.¶
The `s://` scheme is defined as a shorthand for `https://`. When a client encounters `s://`, it MUST interpret and process it as a secure HTTPS connection [RFC3986]. Existing URLs using `https://` remain fully functional, ensuring no disruption to current systems. The `http://` scheme may continue to function during a transition period but is expected to be deprecated in the future.¶
The `s://` scheme SHALL remain compatible with HTTP/1.1 [RFC9112] and HTTP/3 semantics [RFC9114].¶
This document requests the registration of the `s://` scheme in the Uniform Resource Identifier (URI) Schemes registry [RFC9110].¶
The introduction of `s://` does not alter the underlying security model of HTTPS [RFC9110]. It is essential that implementations ensure `s://` is interpreted as a secure connection using TLS [RFC8446]. Proper validation and error handling must be maintained to prevent misuse or vulnerabilities.¶
The author would like to acknowledge his parents (Abbas & Parveen), wife (Shaheen) and his two daughters (Zoya & Anaya) for their love and support, always.¶