Original text:
as shown here. This document follows terminology defined in Section 1.2 of OVERVIEW.  2. When a client requests a QuicTransport to be created, the user agent establishes a QUIC connection to the specified address.  It verifies <del> that the the server is a QuicTransport endpoint using ALPN, and that the client is allowed to connect to the specified endpoint using "web_accepted_origins" transport parameter.  Once the verification succeeds and the QUIC connection is ready, the client can send and receive streams and datagrams. </del>  WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation <del> RFC7301.  The user agent MUST request the ALPN value of "wq" and it MUST NOT establish the session unless that value is accepted. </del>  3.2. <del> In order to verify that the client is authorized to access a specific WebTransport server, QuicTransport has a mechanism to verify the origin RFC6454 associated with the client.  The server MUST send a "web_accepted_origins" transport parameter which SHALL be one of the following: </del>  <del> A value "*", indicating that any origin is accepted. </del>  <del> A comma-separated list of accepted origins, serialized as described in Section 6 of RFC6454. </del>  <del> In the latter case, the user agent MUST verify that one of the origins is identical (as defined in Section 5 of RFC6454) to the origin of the client; otherwise, it MUST abort the session establishment. </del>  3.3. handshake will fail.  It will also fail unless the "web_accepted_origins" is present. <del> QuicTransport uses a QUIC transport parameter to provide the user agent with an origin whitelist.  The origin is not sent explicitly, as TLS ClientHello messages are sent in cleartext; instead, the server provides the user agent with a whitelist of origins that are allowed to connect to it. </del>  In order to avoid the use of QuicTransport, the user agents MUST NOT allow the clients to distinguish different connection errors before The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: <del> The "wq-draft01" label identifies QUIC used as a protocol for </del>  WebTransport: QuicTransport <del> 0x77 0x71 0x2d 0x64 0x72 0x61 0x66 0x74 0x30 0x31 ("wq-draft01") </del>  This document 8.2. <del> The following entry is added to the "QUIC Transport Parameter Registry" registry established by QUIC-TRANSPORT: </del>  <del> The "web_accepted_origins" parameter allows the server to indicate origins that are permitted to connect to it: </del>  <del> 0xffc8 </del>  <del> web_accepted_origins </del>  <del> This document </del> 

Reviewer comments:
What is the uri-scheme used in an origin? ( It may be discussed as a separate issue.
Well, the origin sent here is the origin of the webpage that created QuicTransport; so, for instance, if connects using QuicTransport to , the origin send would be . I don't think a QuicTransport connection can be an origin by itself. We are currently considering giving it its own URL scheme, but a URL can only act as an origin if a user can to it, or if the URL has storage attached to it (which QuicTransport doesn't, since it doesn't support HTTP cookies).
I misunderstood the URI schema as that of QuicTransport itself Your kind explanation made me understand. thanks

Revised text:
as shown here. This document follows terminology defined in Section 1.2 of OVERVIEW. <ins> The diagrams describe encoding following the conventions described in Section 1.3 of QUIC-TRANSPORT. </ins> 2. When a client requests a QuicTransport to be created, the user agent establishes a QUIC connection to the specified address.  It verifies  <ins> that the the server is a QuicTransport endpoint using ALPN, and sends a _client indication_ containing the origin of the initiating website to the server.  At that point, the connection is ready from the client's perspective.  The server MUST wait until the indication is received before processing any application data. </ins> WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation  <ins> RFC7301.  The user agent MUST request the ALPN value of "wq-vvv-01" and it MUST close the connection unless the server confirms that ALPN value. </ins> 3.2.  <ins> In order to verify that the client's origin is allowed to connect to the server in question, the user agent has to communicate the origin to the server.  This is accomplished by sending a special message, called _client indication_, on stream 2, which is the first client- initiated unidirectional stream. </ins>  <ins> The client indication is a sequence of key-value pairs that are formatted in the following way: </ins>  <ins> The pair includes the following fields: </ins>  <ins> Indicates the field that is being expressed. Indicates the length of the value (the length of the key and the length itself are not included). The value of the field, the semantics of which are determined by the key. A FIN on the stream 2 SHALL indicate that the message is complete. The client MUST send the entirety of the client indication and a FIN immediately after opening the connection.  The server MUST NOT process any application data before receiving the entirety of the client indication.  The total length of the client indication MUST NOT exceed 65,535 bytes. The server MUST ignore the fields it does not recognize.  All of the fields MUST be unique; the server MAY close the connection if any of the keys is used more than once. 3.2.1. In order to allow the server to enforce the origin policy, the user agent has to communicate the origin in the client indication.  This can be accomplished using the "Origin" field: Origin 0x0000 The origin RFC6454 of the client initiating the connection. The user agent MUST send the Origin field.  The origin field MUST be set to the origin of the client initiating the connection, serialized as described in serializing a request origin [1] of FETCH. </ins> 3.3. handshake will fail.  It will also fail unless the "web_accepted_origins" is present.  <ins> QuicTransport uses a unidirectional QUIC stream to provide the server with the origin of the client. </ins> In order to avoid the use of QuicTransport, the user agents MUST NOT allow the clients to distinguish different connection errors before The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301:  <ins> The "wq-vvv-01" label identifies QUIC used as a protocol for </ins> WebTransport: QuicTransport  <ins> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x31 ("wq-vvv-01") </ins> This document 8.2.  <ins> IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the following fields: </ins>  <ins> The name of the field. </ins>  <ins> The 16-bit uniquie identifier that is used on the wire. </ins>  <ins> A brief description of what the parameter does. </ins>  <ins> The document that describes the parameter. The IANA policy, as descrbied in RFC8126, SHALL be Standards Action for values between 0x0000 and 0x03ff; Specification Required for values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff. 9.  References 9.1.  URIs [1] https://fetch.spec.whatwg.org/#serializing-a-request-origin </ins>