]>

fakedme@gmail.com https://soniex2.autistic.space/

art Internet Engineering Task Force This document describes an URI scheme capable of susbtituting userinfo in traditional URIs, in machine-to-machine contexts, allowing for the deprecation and, in some applications, complete elimination of userinfo from URIs. In particular, the nature of the proposed URI scheme makes it unsuitable for use in semantic attacks, without compromising legitimate use-cases.

Introduction Userinfo in URIs has been around since the introduction of URIs, but this is widely considered a historical mistake, as, due to the way userinfo is constructed, it enables some semantic attacks on URIs . Unfortunately, in machine-to-machine contexts, the ability to shove an userinfo-shaped peg into just about any URI-shaped hole turned out to be highly useful. The auth URI builds on this context and enables the complete removal of the userinfo syntax in at least some applications.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Background: Considerations for a new way of encoding authentication The primary goal of a replacement for the userinfo syntax should be mitigating and/or eliminating the userinfo-related semantic attacks currently applicable to URIs. However, this does not preclude secondary goals such as improved support for secret storage (password managers). Making it an URI enables the following features in alignment with the primary goal: The auth URI generally prohibits operating system-level handling. When one program attempts to open an auth URI, the operating system MUST NOT open another program to handle the auth URI. Like userinfo, the auth URI shows up first/early in the URI, but unlike userinfo, it is not recognizable as a website or web address. This makes the auth URI easier to identify as an auth URI or at least "not a normal web address" than the equivalent userinfo. The auth URI explicitly uses syntax that is not usually detected by existing link recognition/extraction systems or "linkifiers". While this doesn't really add anything beyond the previously mentioned mitigations, it does help to reiterate that these URIs, while valid URIs, are not hyperlinks. Additionally, and in alignment with secondary goals, the auth URI can support "advanced" auth methods, including secret storage integration.

The auth URI: syntax and semantics The auth URI is a meta-URI, in that it carries an URI within itself. The auth URI syntax is defined here in Augmented BNF , borrrowing the terms 'URI', 'unreserved', and 'pct-encoded' from . As an additional requirement, the embedded URI MUST NOT contain userinfo. Semantically, the auth URI attaches auth details (not necessarily credentials themselves, but possibly how to locate the credentials) to the embedded URI. This embedded URI MAY itself be another auth URI, and an implementation MAY retry auth with the inner details, but SHOULD limit the maximum number of retries. An implementation MUST be able to parse at least 3 auth URIs before an embedded URI.

Fragment Handling specifies how fragments should be handled, and said specification is reiterated by . For the sake of clarification, the auth URI does not affect fragment resolution. However, care must be taken when parsing auth URIs with RFC3986 libraries: the fragment identifier will be extracted with the full URI and any "%23" in the embedded URI MUST NOT be unescaped before further parsing.

The "info" method The "info" method is a direct replacement for traditional userinfo. As such, it takes two attributes: "name" and "ad" (short for "auth data"). As with traditional userinfo, only the "name" attribute is required. As with traditional userinfo, applications are encouraged to not render in cleartext the value of the "ad" attribute.

IANA Considerations In accordance with the guidelines and registration procedures for new URI schemes , this section provides the information needed to register the 'auth' URI scheme. Scheme name: auth Status: Permanent Applications/Protocols that use this scheme name: At the time of writing, no applications use this scheme name. The intent is for this scheme to gradually replace userinfo in applications that currently make use of userinfo. Contact: Soni L., fakedme@gmail.com Change controller: [Note to RFC Editor: Replace with standard IETF language] References: RFC XXXXX [Note to RFC Editor: Replace with final RFC number] Additionally, in accordance IANA Considerations , the IANA is asked to create a registry for auth URI methods. Registry Name: 'auth' URI Methods Registry Group: Uniform Resource Identifiers (URI) Schemes Registry Information: Method Name, References Assignment Policy: IETF review

Initial assignments

The 'info' method Method Name: info References: This document, .

Security Considerations Borrowing from , the 'auth' URI must consider the following: Does the user need to be warned that such a thing is happening without an explicit request? This will generally depend on the auth method used, but in particular the "info" method does not require it. Is it possible to fake URLs of this type in a dangerous way? No. In fact, the primary purpose of the auth URI is to forbid this. Are there mechanisms for identifying the requester? None that are known. Does the mechanism contains passwords or other security information that are passed inside the referring document in the clear? Yes, but no more than existing mechanisms, and only for compatibility purposes. This last point should sufficiently meet the requirements of .

Interoperability Considerations The 'auth' URI explicitly breaks interoperability with existing userinfo-based systems, possibly necessitating conversions between them. Also, as described in , care must be taken when parsing the embedded URI.

Encoding considerations [genuinely unsure what to put here... it's not entirely uncommon to find binary data encoded in an userinfo?]

References Normative References Informative References

Acknowledgements Many of the ABNF rules in this document were adapted from . Some of the structure of this text was adapted from .