The WebRTC URI Scheme

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."¶

This Internet-Draft will expire on 21 October 2023.¶

Copyright Notice

Copyright (c) 2023 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.¶

Table of Contents

1. Introduction

URI is short and compact, convenient for transmission. You can even send it offline to others without using any server, for example, you can generate a QR Code for use.¶

WebRTC is a widely used real-time connection protocol, but unlike WebSocket, it has no URI scheme.¶

This document registers the "wr://" and "wrs://" URI schemes to supplement such gaps. When use the URI quickly open the connection, you can immediately to realize communication between two clients.¶

Use this URI Scheme to easily open a connection. You can open a data channel, then the connection can be used as a file transfer or signalling server, etc. You can also directly open a stable and complex connection by passing more parameters.¶

WebRTC URI Scheme defines one endpoint of the connection, rather than one port of the device. It defines the connection mode of WebRTC in the Internet/LAN that conforms to human intuition. One device can open multiple connections, corresponding to multiple endpoints, without paying special attention to which port is currently used for connection.¶

WebRTC URI Scheme may look like a compressed version of the SDP file. It avoids the trouble of inconvenient transmission of SDP newline characters, and does not expose more information in the first connection.¶

In addition, the WebRTC URI Scheme facilitates communication between two computers through browser application under the premise of light server or no server. Changing connections on the network connect pairs of endpoints. WebRTC endpoints are characterized by great variability and fast variability. We can dynamically connect these points to form a dynamic network.¶

2. WebRTC URIs

This specification defines two URI schemes, using the ABNF syntax defined in RFC 5234 [RFC5234], and terminology and ABNF productions defined by the URI specification RFC 3986 [RFC3986].¶

       wr-URI = "wr" ":" [ host-part ] "/" endpoint [ "?" query ]
       wrs-URI = "wrs" ":" [ host-part ] "/" endpoint [ "?" query ]
       host-part = "//" [ hostport ]

       hostport = host [ ":" port ]
       host = <host, defined in [RFC3986], Section 3.2.2>
       port = <port, defined in [RFC3986], Section 3.2.3>
       endpoint = basehash pwd ufrag
       query = <query, defined in [RFC3986], Section 3.4>

       basehash = 44<pchar>
       pwd = *255<pchar>
       ufrag = *255<pchar>

See [RFC3986], Section 3.3 for a definition of pchar. Disallowed characters -- including non-ASCII characters -- MUST be encoded into UTF-8 [RFC3629] and then percent-encoded ([RFC3986], Section 2.1).¶

The hostport component is OPTIONAL; By default, WebRTC connection without STUN or TURN.¶

The port component is OPTIONAL; By default, "wr" runs on the same ports as STUN and TURN: 3478 for "wr" over UDP and TCP, and 5349 for "wrs" over TLS.¶

The ufrag component, pwd component and fingerprint used in basehash component below can be find in attributes ([RFC8859], Section 5.12) of SDP ([RFC8864], Section 5.12).¶

The basehash component MUST be calculated by the following steps:¶

1. get the length of pwd component¶
2. convert length of pwd component to hexadecimal (1 Byte)¶
3. get the fingerprint hexadecimal (32 Byte)¶
4. connect the length hexadecimal after the fingerprint hexadecimal¶
5. Calculate the Base64([RFC3986], Section 2.1) of the result
   (33 Byte)¶

The advantage of this is to take endpoint component as a whole while taking readability into consideration.¶

Fragment identifiers are meaningless in the context of WebRTC URIs and MUST NOT be used on these URIs. As with any URI scheme, the character "#", when not indicating the start of a fragment, MUST be escaped as %23.¶

Example URIs are listed in Appendix A.¶

3. IANA Considerations

4. Security Considerations

The token ABNF rule allows tokens as small as 0 character. This is not recommended practice; applications should evaluate their requirements for entropy and issue tokens correspondingly. See [RFC8445] for more information.¶

This document not solve the problem that attackers can flood stun/turn servers. Too many open ports may cause network layer rejection.¶

Although the WebRTC URI Scheme makes connections easy to open, you may connect untrusted nodes in static pages, just like click the link of a phishing website. Before connecting, you must confirm whether the URI provider is trusted.¶

If the stun/turn server is not trusted, man-in-the-middle attack may occur on the "ws://" connection. "wrs://" is intended to reduce the incidence of man-in-the-middle attack; it cannot prevent man-in-the-middle attack on client to client connections.¶

And The server side of "wrs://" protocol SHALL ensure the security of each link and the handling of blacklist.¶

Appendix A. Example URIs

The content of sdp is as follows:¶

a=ice-ufrag:Yb1d
a=ice-pwd:uCiLWVRLVIKkrl14SzyO4TMF
a=fingerprint:sha-256 B6:9E:F3:DD:8B:83:8D:F6:95:4E:76:40:AF:F2:78
:0B:CA:78:DA:0B:73:21:1E:28:93:4F:70:DA:47:B4:41:7E

The ufrag component is "Yb1d".
The pwd component is "uCiLWVRLVIKkrl14SzyO4TMF"
The basehash component before Base64 is
0xB69EF3DD8B838DF6954E7640AFF2780BCA78DA0B73211E28934F70DA47B4417E18,
The basehash component is
"tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2ke0QX4Y"¶

So, the endpoint component is
"tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2ke0QX4YuCiLWVRLVIKk
rl14SzyO4TMFYb1d"¶

Without STUN or TURN:¶

o  If no STUN or TURN, expressed in "wr:///". For example:¶

   *  "wr:///tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2ke0QX4YuCiLWVRLVI
      Kkrl14SzyO4TMFYb1d?query=required&for&connect"

o  Or omit "//", expressed in "wr:/". For example:¶

   *  "wr:/tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2ke0QX4YuCiLWVRLVIKk
      rl14SzyO4TMFYb1d?query"

With STUN or TURN:¶

o  Use STUN or TURN server, For example:¶

   *  "wr://host.example.com/tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w2
      ke0QX4YuCiLWVRLVIKkrl14SzyO4TMFYb1d?query"

o  Use STUNs or TURNs server, For example:¶

   *  "wrs://host.example.com/tp7z3YuDjfaVTnZAr/J4C8p42gtzIR4ok09w
      2ke0QX4YuCiLWVRLVIKkrl14SzyO4TMFYb1d?query"

Acknowledgements

Frankly speaking, the document format refers to [RFC8959] when writing.
Thank you~¶

Author's Address