This TransportProtocol sends OPC UA Connection Protocol messages over WebSockets.

WebSockets is a bi-directional protocol for communication via a web server which is commonly used by browser-based applications to allow the web server to asynchronously send information to the client. WebSockets uses the same default port as HTTP or HTTPS and initiates communication with an HTTP request. This makes it very useful in environments where firewalls limit traffic to the ports used by HTTP or HTTPS.

WebSockets use HTTP, however, in practice a WebSocket connection is only initiated with a HTTP GET request and the web server provides an HTTP response. After that exchange, all traffic uses the binary framing protocol defined by RFC 6455.

A Server that supports the WebSockets transport shall publish one or more Endpoints with the scheme ‘opc.wss’. The TransportProfileUri shall be one of the URIs for WebSockets transports defined in OPC 10000-7. The TransportProfileUri specifies the encoding and security protocol used to construct the OPC UA messages sent via the WebSocket.

The SecurityMode and SecurityPolicyUri of the Endpoint control the security applied to the messages sent via the WebSocket. This allows the messages to be secure even if the WebSocket connection is established via untrusted HTTPS proxies.

Figure 22 summarizes the complete process for establishing communication over a WebSocket.

Figure 22 – Setting up Communication over a WebSocket

Figure 22 assumes the opcua+uacp sub-protocol (see 7.5.2). There is no SecureChannel negotiation when using opcua+json sub-protocol.

The default UserIdentity for any Session-less Service calls made over the WebSocket is specified by the opcua+token sub-protocol. It may also be used to determine if the Client is allowed to create a Session.

The WebSocket protocol allows clients to request that servers use specific sub-protocols with the “Sec-WebSocket-Protocol” header in the WebSocket handshake defined in RFC 6455. The sub-protocols defined by this document are shown in Table 79.

Table 79 – WebSocket Sub-Protocols

Sub-Protocol	Description
opcua+uacp	Each WebSocket frame is a MessageChunk as defined in 6.7.2. After the WebSocket is created, the handshake described in 7.1.3 is used to negotiate the maximum size of the MessageChunk. The maximum size for a buffer needed to receive a WebSocket frame is the maximum length of a MessageChunk plus the maximum size for the WebSocket frame header. When using this sub-protocol, the payload in each frame is binary (OpCode 0x2 in RFC 6455).
opcua+uajson	Each WebSocket frame is a Message encoded using the JSON encoding described in 5.4.9. There is no mechanism to negotiate the maximum frame size. If the receiver encounters a frame that exceeds its internal limits it shall close the WebSocket connection and provide a 1009 status code as described in RFC 6455. This sub-protocol is not recommended. The opcua+openapi sub-protocol should be used instead.
opcua+openapi	Each WebSocket frame is a ServiceMessageEnvelope de scribed in G.3. There is no mechanism to negotiate the maximum frame size. If the receiver encounters a frame that exceeds its internal limits it shall close the WebSocket connection and provide a 1009 status code as described in RFC 6455. When using this sub-protocol, the payload in each frame is text (OpCode 0x1 in RFC 6455) if the frame contains UTF8 encoded JSON. If the frame contains JSON compressed with RFC 1952 then the frame is binary (OpCode 0x2 in RFC 6455).
opcua+openapi+<accesstoken>	This sub-protocol is only used in addition to the opcua+openapi sub-protocol.and specifies the default UserIdentity for all Requests sent over the WebSocket. The <accesstoken> is the JSON WebToken (see 6.5.2) and is normally passed in the HTTPS Authentication header. Using a sub-protocol to provide an AccessToken is a widely used design pattern needed to deal with limitations of common WebSocket implementations.

Each WebSocket sub-protocol defined has a TransportProfileUri defined in OPC 10000-7.

The Client shall request a sub-protocol. If the Server does not support the sub-protocol requested by the Client, the Client shall close the connection and report an error.

The WebSockets protocol requires that the Server have a Certificate, however, the Client may have a Certificate. The Server Certificate should have the domain name as the common name component of the subject name however, Clients that are able to override the Certificate validation procedure can choose to accept Certificates with a domain mismatch.

When using the WebSockets transport from a web browser the browser environment may impose additional restrictions. For example, the web browser may require the Server have a valid TLS Certificate that is issued by CA that is installed in the Trust List for the web browser. To support these Clients, a Server may use a TLS Certificate that does not conform to the requirements for an ApplicationInstance Certificate. In these cases, the TLS Certificate is only used for TLS negotiation and the Server shall use a valid ApplicationInstance Certificate for other interactions that require one. Servers shall allow administrators to specify a Certificate for use with TLS that is different from the ApplicationInstance Certificate.

Clients running in a browser environment specify the ‘Origin’ HTTP header during the WebSocket upgrade handshake. Servers should return the ‘Access-Control-Allow-Origin’ to indicate that the connection is allowed.

Any Client that does not run in a web browser environment and supports the WebSockets transport shall accept OPC UA ApplicationInstance Certificate as the TLS Certificate provided the correct domain is specified in the subjectAltName field.

A Client may use its ApplicationInstance Certificate as the TLS Certificate and Servers shall accept those Certificates if they are valid according to the OPC UA Certificate validation rules.

Some operating systems will not give the application any control over the set of algorithms that TLS will negotiate. In some cases, this set will be based on the needs of web browsers and will not be appropriate for the needs of an OPC UA Application. If this is a concern, applications should use OPC UA Secure Conversation in addition to TLS.

Clients that support the WebSocket transport shall support explicit configuration of an HTTPS proxy. When using an HTTPS proxy, the Client shall first send an HTTP CONNECT message (see HTTP) before starting the WebSocket protocol handshake. Note that explicit HTTPS proxies allow for man-in-the-middle attacks. This threat may be mitigated by using OPC UA Secure Conversation in addition to TLS.