Change:
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> <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. <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> <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> <del> A value "*", indicating that any origin is accepted. </del> <ins> The client indication is a sequence of key-value pairs that are formatted in the following way: </ins> <del> A comma-separated list of accepted origins, serialized as described in Section 6 of RFC6454. </del> <ins> The pair includes the following fields: </ins> <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> <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.

Discussion:
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