Errata exists for this version of the document.

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 17 summarizes the complete process for establishing communication over a WebSocket.

Figure 17 – Setting up Communication over a WebSocket

The figure assumes the opcua+uacp protocol mapping (see 7.5.2).

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 protocols defined by this standard are shown in Table 56.

Table 56 – WebSocket Protocols Mappings

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 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. When using this protocol the payload in each frame is text (OpCode 0x1 in RFC 6455).

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

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

WebSockets 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 adminstrators to specify a Certificate for use with TLS that is different from 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 Application Instance Certificate as the TLS Certificate provided the correct domain is specified in the subjectAltName field.

A Client may use its Application Instance 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.