OPC UA Connection Protocol (UACP) is an abstract protocol that establishes a full duplex channel between a Client and Server. Concrete implementations of the UACP can be built with any middleware that supports full-duplex exchange of messages including TCP/IP and WebSockets. The term “TransportConnection” describes the specific connection used to exchange messages. For example, a socket is the TransportConnection for TCP/IP. TransportConnections allow responses to be returned in any order. If the TransportConnection breaks the SecureChannel is interrupted and a new SecureChannel needs to be created.

The OPC UA Connection Protocol is designed to work with the SecureChannel implemented by a layer higher in the stack. For this reason, the OPC UA Connection Protocol defines its interactions with the SecureChannel in addition to the wire protocol.

Figure 17 illustrates the structure of a Message placed on the wire. This also illustrates how the Message elements defined by the OPC UA Binary Encoding mapping (see 5.2) and the OPC UA Secure Conversation mapping (see 6.7) relate to the OPC UA Connection Protocol Messages.

Figure 17 – OPC UA Connection Protocol Message structure

Every OPC UA Connection Protocol Message has a header with the fields defined in Table 71.

Table 71 – OPC UA Connection Protocol Message header

Name	Type	Description
MessageType	Byte [3]	A three byte ASCII code that identifies the Message type. The following values are defined at this time: HEL a Hello Message. ACK an Acknowledge Message. ERR an Error Message. RHE a ReverseHello Message. The SecureChannel layer defines additional values which the OPC UA Connection Protocol layer shall accept.
Reserved	Byte [1]	Ignored. shall be set to the ASCII codes for ‘F’ if the MessageType is one of the values supported by the OPC UA Connection Protocol.
MessageSize	UInt32	The length of the Message, in bytes. This value includes the 8 bytes for the Message header.

The layout of the OPC UA Connection Protocol Message header is intentionally identical to the first 8 bytes of the OPC UA Secure Conversation Message header defined in Table 56. This allows the OPC UA Connection Protocol layer to extract the SecureChannel Messages from the incoming stream even if it does not understand their contents.

The OPC UA Connection Protocol layer shall verify the MessageType and make sure the MessageSize is less than the negotiated ReceiveBufferSize before passing any Message onto the SecureChannel layer.

The Hello Message has the additional fields shown in Table 72.

Table 72 – OPC UA Connection Protocol Hello Message

Name	Data Type	Description
ProtocolVersion	UInt32	The version of the UACP protocol requested by the Client. If Server does not support the requested version or any lower version it rejects the Client by returning Bad_ProtocolVersionUnsupported. If the Server supports the requested version or a lower version it shall return the version it will use in the Acknowledge Message. The ProtocolVersion for this version of the standard is 0.
ReceiveBufferSize	UInt32	The largest MessageChunk that the sender can receive. Shall be at least 1024 bytes if the sender intends to use an ECC SecurityPolicy. Shall be at least 8192 bytes otherwise.
SendBufferSize	UInt32	The largest MessageChunk that the sender will send. Shall be at least 1024 bytes if the sender intends to use an ECC SecurityPolicy. Shall be at least 8192 bytes otherwise.
MaxMessageSize	UInt32	The maximum size for any response Message. If MessageChunks have not been sent, the Server shall return an Error Message with a Bad_ResponseTooLarge error if a response Message exceeds this value. If MessageChunks have already been sent the Server shall abort the Message as described in 6.7.3. The Message size is calculated using the unencrypted Message body. A value of zero indicates that the Client has no limit.
MaxChunkCount	UInt32	The maximum number of chunks in any response Message. The Server shall abort the Message with a Bad_ResponseTooLarge Error Message if a response Message exceeds this value. The mechanism for aborting Messages is described fully in 6.7.3. A value of zero indicates that the Client has no limit.
EndpointUrl	String	The URL of the Endpoint which the Client wished to connect to. The encoded value shall be less than 4096 bytes. Servers shall return a Bad_TcpEndpointUrlInvalid Error Message and close the connection if the length exceeds 4096 or if it does not recognize the resource identified by the URL.

The EndpointUrl parameter is used to allow multiple Servers to share the same endpoint on a machine. The process listening (also known as the proxy) on the endpoint would connect to the Server identified by the EndpointUrl and would forward all Messages to the Server via this socket. If one socket closes, then the proxy shall close the other socket.

If the Server does not have sufficient resources to allow the establishment of a new SecureChannel it shall immediately return a Bad_TcpNotEnoughResources Error Message and gracefully close the socket. Client should not overload Servers that return this error by immediately trying to create a new SecureChannel.

The Acknowledge Message has the additional fields shown in Table 73.

Table 73 – OPC UA Connection Protocol Acknowledge Message

Name	Type	Description
ProtocolVersion	UInt32	A protocol version supported by the Server that is less than or equal to the protocol version requested in the Hello Message. If the Client accepts the protocol version it shall ensure that it sends Messages that conform to this version. The ProtocolVersion for this version of the standard is 0.
ReceiveBufferSize	UInt32	The largest MessageChunk that the sender can receive. This value shall not be larger than the SendBufferSize requested in the Hello Message. Shall be at least 8192 bytes if the SendBufferSize requested in the Hello Message is >= 8192 bytes. Shall be at least 1024 bytes otherwise.
SendBufferSize	UInt32	The largest MessageChunk that the sender will send. This value shall not be larger than the ReceiveBufferSize requested in the Hello Message. Shall be at least 8192 bytes if the ReceiveBufferSize requested in the Hello Message is >= 8192 bytes. Shall be at least 1024 bytes otherwise.
MaxMessageSize	UInt32	The maximum size for any request Message. If a request Message exceeds this value the Client shall report a Bad_ Bad_RequestTooLarge error to the application. If MessageChunks have already been sent the Client shall also abort the Message as described in 6.7.3. The Message size is calculated using the unencrypted Message body. A value of zero indicates that the Server has no limit.
MaxChunkCount	UInt32	The maximum number of chunks in any request Message. The Client shall abort the Message with a Bad_RequestTooLarge StatusCode if a request Message exceeds this value. The mechanism for aborting Messages is described fully in 6.7.3. A value of zero indicates that the Server has no limit.

The Error Message has the additional fields shown in Table 74.

Table 74 – OPC UA Connection Protocol Error Message

Name	Type	Description
Error	UInt32	The numeric code for the error. Possible values are listed in Table 77.
Reason	String	A more verbose description of the error. This string shall not be more than 4096 bytes. A Client shall ignore strings that are longer than this.

The socket is always closed gracefully by the Client after it receives an Error Message.

The ReverseHello Message has the additional fields shown in Table 75.

Table 75 – OPC UA Connection Protocol ReverseHello Message

Name	Data Type	Description
ServerUri	String	The ApplicationUri of the Server which sent the Message. The encoded value shall be less than 4096 bytes. Client shall return a Bad_TcpEndpointUrlInvalid error and close the connection if the length exceeds 4096 or if it does not recognize the Server identified by the URI.
EndpointUrl	String	The URL of the Endpoint which the Client uses when establishing the SecureChannel. This value shall be passed back to the Server in the Hello Message. The encoded value shall be less than 4096 bytes. Clients shall return a Bad_TcpEndpointUrlInvalid error and close the connection if the length exceeds 4096 or if it does not recognize the resource identified by the URL. This value is a unique identifier for the Server which the Client may use to look up configuration information. It should be one of the URLs returned by the GetEndpoints Service.

For connection-based protocols, such as TCP, the ReverseHello Message allows Servers behind firewalls with no open ports to connect to a Client and request that the Client establish a SecureChannel using the socket created by the Server.

For message-based protocols the ReverseHello Message allows Servers to announce their presence to a Client. In this scenario, the EndpointUrl specifies the Server’s specific address and any tokens required to access it.

Connections may be initiated by the Client or by the Server when they create a TransportConnection and establish a communication with their peer. The connection is initiated by using an EndpointUrl that specifies a network address where a peer listens for new connections. The EndpointUrl specifies a network address that is accessible to the initiator. If the listener is behind a NAT firewall, the EndpointUrl specifies an address outside the firewall. If the EndpointUrl specifies a domain name then the initiator requires access to a domain name resolution service (e.g., the DNS protocol) that maps the domain name onto a usable network address. OPC 10000-7 defines Profiles for different name resolution protocols that Clients and Servers may support.

If the Client creates the TransportConnection, the first Message sent shall be a Hello which specifies the buffer sizes that the Client supports. The Server shall respond with an Acknowledge Message which completes the buffer negotiation. The negotiated buffer size shall be reported to the SecureChannel layer. The negotiated SendBufferSize specifies the size of the MessageChunks to use for Messages sent over the connection.

If the Server creates the TransportConnection the first Message shall be a ReverseHello sent to the Client. If the Client accepts the connection, it sends a Hello message back to the Server which starts the buffer negotiation described for the Client initiated connection.

The Hello/Acknowledge Messages may only be sent once. If they are received again the receiver shall report an error and close the TransportConnection. Applications accepting incoming connections shall close any TransportConnection after a period of time if it does not receive a Hello or ReverseHello Message. This period of time shall be configurable and have a default value which does not exceed two minutes.

The Client sends the OpenSecureChannel request once it receives the Acknowledge back from the Server. If the Server accepts the new channel, it shall associate the TransportConnection with the SecureChannelId. The Server uses this association to determine which TransportConnection to use when it has to send a response to the Client. The Client does the same when it receives the OpenSecureChannel response.

The Server application does not do any processing while the SecureChannel is negotiated; however, the Server application shall provide the Stack with the list of trusted Certificates. The Stack shall provide notifications to the Server application whenever it receives an OpenSecureChannel request. These notifications shall include the OpenSecureChannel or Error response returned to the Client.

The sequence of Messages when establishing a Client initiated OPC UA Connection Protocol connection is shown in Figure 18.

Figure 18 – Client initiated OPC UA Connection Protocol connection

The sequence of Messages when establishing a Server initiated OPC UA Connection Protocol connection is shown in Figure 19.

Figure 19 – Server initiated OPC UA Connection Protocol connection

For Server-initiated connections, the Server needs to be configured and enabled by an administrator to connect to one or more Clients. For each Client, the administrator shall provide an EndpointUrl which may be use to establish a connection. If the Client EndpointUrl is not known, the administrator may provide the EndpointUrl for a GDS (see OPC 10000-12) which knows about the Client. In this case, the administrator shall also provide an ApplicationUri which can be used to find the Client in the GDS.

Servers shall maintain at least one open socket without an active Session with each Client it is configured to connect to. Servers may delay re-connecting if the Client reports an error. Table 76 describes the process in full and how the Server is expected to react to different actions by the Client.

Table 76 – Client and Server Handshake during Reverse Connect

Action	Notes
Open Connection	Server creates a socket to a URL specified in its configuration. Client shall close the socket after short delay if no ReverseHello Message received. Server shall create a new socket because it cannot know if it was a network issue or due to action by the Client.
Reverse Hello	Server sends ReverseHello with its ApplicationUri. Client may check the ApplicationUri. If it is not acceptable it shall close the socket. Client shall send an Error Message with the code Bad_ServerTooBusy if it does not have enough resources to keep the socket open. Client may save socket for use in the future (the sequence may pause here). If the Server receives an Error Message it shall close the socket, log the error and reconnects after a delay specified in its configuration. If the socket is closed without an Error Message, the Server shall create a new socket with or without a delay and sends a new ReverseHello Message.
HelloAcknowledgeOpen Secure Channel RequestOpen Secure Channel Response	Client establishes a SecureChannel and verifies that it trusts the Server. Client may save the SecureChannel for use in the future (the sequence may pause here). Client may use SecureChannel for Discovery or Session-less Service invocations. Once a SecureChannel is established, the Server shall create a new socket if there is not already one without an active SecureChannel. If the SecureChannel is closed, the Server shall create a new socket if there is not already one without an active SecureChannel.
Create Session	Client establishes a Session.

The Client closes the connection by sending a CloseSecureChannel request and closing the socket gracefully. When the Server receives this Message, it shall release all resources allocated for the channel. The body of the CloseSecureChannel request is empty. The Server does not send a CloseSecureChannel response.

If security verification fails for the CloseSecureChannel Message, then the Server shall report the error and close the socket.

The sequence of Messages when closing an OPC UA Connection Protocol connection is shown in Figure 20.

Figure 20 – Closing a OPC UA Connection Protocol connection

The Server application does not do any processing when the SecureChannel is closed; however, the Stack shall provide notifications to the Server application whenever a CloseSecureChannel request is received or when the Stack cleans up an abandoned SecureChannel.

When a protocol level error occurs that cannot be recovered, the Server shall send an Error Message to the Client and closes the TransportConnection gracefully. When the Client receives an Error Message it reports the error to the application and closes the TransportConnection gracefully. If a Client encounters a fatal error, it shall report the error to the application and send a CloseSecureChannel Message. The Server shall close the TransportConnection gracefully when it receives the CloseSecureChannel Message.

The possible OPC UA Connection Protocol errors are defined in Table 77.

Table 77 – OPC UA Connection Protocol error codes

Name	Description
Bad_TcpServerTooBusy	The Server cannot process the request because it is too busy. It is up to the Server to determine when it needs to return this Message. A Server can control the how frequently a Client reconnects by waiting to return this error.
Bad_TcpMessageTypeInvalid	The type of the Message specified in the header invalid. Each Message starts with a 4-byte sequence of ASCII values that identifies the Message type. The Server returns this error if the Message type is not accepted. Some of the Message types are defined by the SecureChannel layer.
Bad_TcpSecureChannelUnknown	The SecureChannelId and/or TokenId are not currently in use. This error is reported by the SecureChannel layer.
Bad_TcpMessageTooLarge	The size of the MessageChunk specified in the header is too large. The Server returns this error if the MessageChunk size exceeds its maximum buffer size or the receive buffer size negotiated during the Hello/Acknowledge exchange.
Bad_Timeout	A timeout occurred while accessing a resource. It is up to the Server to determine when a timeout occurs.
Bad_TcpNotEnoughResources	There are not enough resources to process the request. The Server returns this error when it runs out of memory or encounters similar resource problems. A Server can control the how frequently a Client reconnects by waiting to return this error.
Bad_TcpInternalError	An internal error occurred. This should only be returned if an unexpected configuration or programming error occurs.
Bad_TcpEndpointUrlInvalid	The Server does not recognize the EndpointUrl specified.
Bad_SecurityChecksFailed	The Message was rejected because it could not be verified.
Bad_RequestInterrupted	The request could not be sent because of a network interruption.
Bad_RequestTimeout	Timeout occurred while processing the request.
Bad_SecureChannelClosed	The secure channel has been closed.
Bad_SecureChannelTokenUnknown	The SecurityToken has expired or is not recognized.
Bad_CertificateUntrusted	The sender Certificate is not trusted by the receiver.
Bad_CertificateTimeInvalid	The sender Certificate has expired or is not yet valid.
Bad_CertificateIssuerTimeInvalid	The issuer for the sender Certificate has expired or is not yet valid.
Bad_CertificateUseNotAllowed	The sender’s Certificate may not be used for establishing a secure channel.
Bad_CertificateIssuerUseNotAllowed	The issuer Certificate may not be used as a Certificate Authority.
Bad_CertificateRevocationUnknown	Could not verify the revocation status of the sender’s Certificate.
Bad_CertificateIssuerRevocationUnknown	Could not verify the revocation status of the issuer Certificate.
Bad_CertificateRevoked	The sender Certificate has been revoked by the issuer.
Bad_IssuerCertificateRevoked	The issuer Certificate has been revoked by its issuer.
Bad_SequenceNumberInvalid	The sequence number on the message was not valid.
Bad_ServiceUnsupported	The Service Request contained in the body of the message is not supported. This error is only returned when the Request represents a security risk and it is necessary to immediately close the SecureChannel. For example, calling CreateSession on a SecureChannel that does not allow Sessions.

The numeric values for these error codes are defined in A.2.

NOTE: The ‘Tcp’ prefix for some of the error codes in Table 77 was chosen when TCP/IP was the only implementation of the OPC UA Connection Protocol. These codes are used with any implementation of the OPC UA Connection Protocol.

TCP/IP is a ubiquitous protocol that provides full-duplex communication between two applications. A socket is the TransportConnection in the TCP/IP implementation of the OPC UA Connection Protocol.

The URL scheme for endpoints using OPC UA TCP is ‘opc.tcp’.

The TransportProfileUri shall be a URI for the TCP transport defined in OPC 10000-7.

Note: Deprecated in Version 1.03 because WS-SecureConversation has not been widely adopted by industry.

HTTPS refers HTTP Messages exchanged over a TLS connection (see HTTPS). The syntax of the HTTP Messages does not change and the only difference is a TLS connection is created instead of a TCP/IP connection. This implies that profiles which use this transport can also be used with HTTP when security is not a concern.

HTTPS is a protocol that provides transport security. This means all bytes are secured as they are sent without considering the Message boundaries. Transport security can only work for point-to-point communication and does not allow untrusted intermediaries or proxy servers to handle traffic.

The SecurityPolicy shall be specified, however, it only affects the algorithms used for signing the Nonces during the CreateSession/ActivateSession handshake. A SecurityPolicy of None indicates that the Nonces do not need to be signed. The SecurityMode is set to Sign unless the SecurityPolicy is None; in this case the SecurityMode shall be set to None. If a UserIdentityToken is to be encrypted, it shall be explicitly specified in the UserTokenPolicy.

An HTTP Header called ‘OPCUA-SecurityPolicy’ is used by the Client to tell the Server what SecurityPolicy it is using if there are multiple choices available. The value of the header is the URI for the SecurityPolicy. If the Client omits the header, then the Server shall assume a SecurityPolicy of None.

All HTTPS communications via a URL shall be treated as a single SecureChannel that is shared by multiple Clients. Stacks shall provide a unique identifier for the SecureChannel which allows applications correlate a request with a SecureChannel. This means that Sessions can only be considered secure if the AuthenticationToken (see OPC 10000-4) is long (>20 bytes) and HTTPS encryption is enabled.

The cryptography algorithms used by HTTPS have no relationship to the EndpointDescription SecurityPolicy and are determined by the policies set for HTTPS and are outside the scope of OPC UA.

Figure 21 illustrates a few scenarios where the HTTPS transport could be used.

Figure 21 – Scenarios for the HTTPS Transport

In some scenarios, HTTPS communication will rely on an intermediary which is not trusted by the applications. If this is the case, then the HTTPS transport cannot be used to ensure security and the applications will have to establish a secure tunnel like a VPN before attempting any OPC UA related communication.

Applications which support the HTTPS transport shall support HTTP and TLS.

Some HTTPS implementations require that all Servers have a Certificate with a Common Name (CN) that matches the DNS name of the Server machine. This means that a Server with multiple DNS names will need multiple HTTPS certificates. If multiple Servers are on the same machine they may share HTTPS certificates. This means that ApplicationCertificates are not the same as HTTPS Certificates. Applications which use the HTTPS transport and require application authentication shall check application Certificates during the CreateSession/ActivateSession handshake.

HTTPS Certificates can be automatically generated; however, this will cause problems for Clients operating inside a restricted environment such as a web browser. Therefore, HTTPS certificates should be issued by an authority which is accepted by all web browsers which need to access the Server. The set of Certificate authorities accepted by the web browsers is determined by the organization that manages the Client machines. Client applications that are not running inside a web may use the trust list that is used for application Certificates.

A Server that is configured to use an HTTPS proxy shall have a mechanism to ensure that requests only come from that HTTPS proxy. The exact mechanism, such as binding to the loopback address, is implementation dependent.

HTTPS connections have an unpredictable lifetime. Therefore, Servers must rely on the AuthenticationToken passed in the RequestHeader to determine the identity of the Client. This means the AuthenticationToken shall be a randomly generated value with at least 32 bytes of data and HTTPS with signing and encryption shall always be used.

HTTPS allows Clients to have certificates; however, they are not required by the HTTPS transport. A Server shall allow Clients to connect without providing a Certificate during negotiation of the HTTPS connection.

HTTP 1.1 supports Message chunking where the Content-Length header in the request response is set to “chunked” and each chunk is prefixed by its size in bytes. All applications that support the HTTPS transport shall support HTTP chunking.

The URL scheme for endpoints using the HTTPS transport is ‘opc.https’. Note that ‘https’ is the generic URL scheme for the underlying transport. The opc prefix specifies that the endpoint accepts OPC UA messages as defined in this document.

Session-less Services (see OPC 10000-4) may be invoked via HTTPS POST.

The HTTP Authorization header is used to specify the UserIdentity used to determine what permissions are available to the caller. The Authorization header may specify a Basic token with a UserName/Password or a Bearer token (see RFC 6750) with an AccessToken provided by an AuthorizationService.

The HTTP Accept-Language header is used to specify the locales to use for the request. The locales are sorted based on their quality value and then by the order they appear in the header.

The Content-Type header in the HTTP request and response shall specify the DataEncoding of the message. Well known media types should be used to ensure interoperability with standard HTTP infrastructure. The application/opcua+uabinary media type is also defined, however, it is not registered with IANA and is only specified for backward compatibility.

Table 78 – HTTP Content-Type Header

Content-Type	Description
application/octet-streamapplication/opcua+uabinary	The body is encoded using the OPC UA Binary DataEncoding defined in 5.2.
application/soap+xml	The body is encoded using the XML DataEncoding defined in 5.3.
application/json	The body is encoded using the OPC UA JSON Compact DataEncoding defined in 5.4.

XML and JSON messages always use the UTF8 encoding. The charset parameter (i.e. ‘application/json; charset=utf-8’) may be appended to the media type to indicate this.

JSON messages may be compressed with RFC 1952. If compression is used the Content-Encoding HTTP Header is ‘gzip’.

This TransportProtocol implements the OPC UA Services using a SOAP request-response message pattern over an HTTPS connection.

The body of the HTTP Messages shall be a SOAP 1.2 Message (see SOAP Part 1). WS-Addressing headers are optional.

The OPC UA XML Encoding specifies a way to represent an OPC UA Message as an XML element. This element is added to the SOAP Message as the only child of the SOAP body element. If an error occurs in the Server while parsing the request body, the Server may return a SOAP fault or it may return an OPC UA error response.

The SOAP Action associated with an XML encoded request Message always has the form:

http://opcfoundation.org/UA/2008/02/Services.wsdl/<service name>

Where <service name> is the name of the OPC UA Service being invoked.

The SOAP Action associated with an XML encoded response Message always has the form:

http://opcfoundation.org/UA/2008/02/Services.wsdl/<service name>Response

All requests shall be HTTP POST requests. The Content-type shall be "application/soap+xml" and the charset and action parameters shall be specified. The charset parameter shall be "utf-8" and the action parameter shall be the URI for the SOAP action.

An example HTTP request header is:

POST /UA/SampleServer HTTP/1.1

Content-Type: application/soap+xml; charset="utf-8";

action="http://opcfoundation.org/UA/2008/02/Services.wsdl/Read"

Content-Length: nnnn

The action parameter appears on the same line as the Content-Type declaration.

An example request Message:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">

<s:Body>

<ReadRequest xmlns="http://opcfoundation.org/UA/2008/02/Types.xsd">

…

</ReadRequest>

</s:Body>

</s:Envelope>

An example HTTP response header is:

HTTP/1.1 200 OK

Content-Type: application/soap+xml; charset="utf-8";

action="http://opcfoundation.org/UA/2008/02/Services.wsdl/ReadResponse"

Content-Length: nnnn

The action parameter appears on the same line as the Content-Type declaration.

An example response Message:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">

<s:Body>

<ReadResponse xmlns="http://opcfoundation.org/UA/2008/02/Types.xsd">

…

</ReadResponse>

</s:Body>

</s:Envelope>

This TransportProtocol implements the OPC UA Services using an OPC UA Binary encoded Messages exchanged over an HTTPS connection.

Applications which support the HTTPS Profile shall support HTTP 1.1.

The body of the HTTP Messages shall be encoding using the OPC UA Binary DataEncoding. The Content-Type shall be "application/octet-stream".

An example HTTP request header is:

POST /UA/SampleServer HTTP/1.1

Content-Type: application/octet-stream

Content-Length: nnnn

An example HTTP response header is:

HTTP/1.1 200 OK

Content-Type: application/octet-stream

Content-Length: nnnn

The Message body is the request or response structure encoded as an ExtensionObject in OPC UA Binary. The Authorization header is only used for Session-less Service calls (see 7.4.2).

If the OPC UA Binary DataEncoding is used for a Session-less Service the HTTP request header is:

POST /UA/SampleServer HTTP/1.1Authorization : Bearer <base64-encoded-token-data>

Content-Type: application/octet-stream

Content-Length: nnnn

This TransportProtocol implements the OPC UA Services using JSON encoded Messages exchanged over an HTTPS connection.

Applications which support the HTTPS Profile shall support HTTP 1.1.

The body of the HTTP Messages shall be encoded using the OPC UA JSON DataEncoding and the Content-Type shall be ‘application/json’. If the message is compressed the Content-Encoding shall be ‘gzip’.

An example HTTP request header is:

POST /UA/SampleServer HTTP/1.1Authorization : Bearer <base64-encoded-token-data>

Content-Type: application/json

Content-Length: nnnn

An example HTTP response header is:

HTTP/1.1 200 OK

Content-Type: application/jsonContent-Encoding: gzipContent-Length: nnnn

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.

The Local Discovery Server (LDS) is an OPC UA Server that implements the Discovery Service Set defined in OPC 10000-4. If an LDS is installed on a machine, it shall use one or more of the well-known addresses defined in Table 80.

Table 80 – Well known addresses for Local Discovery Servers

Transport Mapping	URL	Notes
OPC UA TCP	opc.tcp://localhost:4840/UADiscovery
OPC UA WebSockets	opc.wss://localhost:443/UADiscovery
OPC UA HTTPS	opc.https://localhost:443/UADiscovery

OPC UA applications that make use of the LDS shall allow administrators to change the well-known addresses used within a system.

The Endpoint used by Servers to register with the LDS shall be the base address with the path “/registration” appended to it (e.g. http://localhost/UADiscovery/registration). OPC UA Servers shall allow administrators to configure the address to use for registration.

Each OPC UA Server application implements the Discovery Service Set. If the OPC UA Server requires a different address for this Endpoint, it shall create the address by appending the path “/discovery” to its base address.