NEHTA has produced a number profiles which constrain the published Web service specifications (ie remove some of the optionality) in order to promote interoperability. These profiles have been developed after interoperability testing between several vendor toolkits used to develop Web services (ie they are refinements on the published specifications which take into account practical limitations imposed by technologies which implement the specifications). Each element of a profile is associated with one or more conformance points, which are testable criteria for assessing whether an implementation conforms to the profile. The profiles are:

• Web Services Profile v3.1
• XML Secured Payload Profile v1.1

The Web Services Profile v3.1 includes a base profile for communicating a message and two alternative profiles for securing the communication as follows:

• Base Profile - defines the basic protocols for wrapping a message in an envelope, addressing it and transporting it. It says nothing about what type of messages to send, how they should be constructed (so that some other party can understand them) or how to send them (ie what operations would need to be enacted in order to communicate with another party).These details are addressed in separate Service Interface Specifications.

• Transport Layer Security (TLS) - applies to the transport level (in this case, HTTPS). TLS is robust, proven and widely implemented in a way which is commonly interoperable. Its limitation is that it does not support end-to-end security, providing security only for communication between two parties which are directly connected.
• WS-Security - applies at the message level, independently of the underlying transport mechanism. In theory, it provides support for end-to-end security. However, WS-Security is still relatively new with uneven implementation in vendor toolkits. The XML Secured Payload Profile v1.1 defines the mechanisms to sign and encrypt data represented as XML. It allows messages to be secured independently of whatever security mechanism is used at the Web services level. It is necessary to ensure that messages are secured even if routed via an intermediary (such as a messaging vendor).