Probably the prime building block of a Service Oriented Architecture (SOA) is the web service which is the item offered by a provider to be used, or consumed, by an application. Web services, from the point-of-view of the consumer of a service, are a set of agreements with the service producer. At the base is an agreement that the process will be executed correctly and that the data returned will be accurate. The form the service would take was also agreed upon by the XML schema used either being an accepted standard or contractually agreed upon. This use of standards helps the consumer take advantage of the interoperable nature of the service to rapidly deploy the application. At the dawn of the move towards designing programs to consume web services there was an idea that such an agreement was all that would be required to use a web service. When I first encountered web services in the form of receiving a list of advertising generated leads from a convention and visitors bureau for the tourism-based company I worked for no security measures were taken at all. This lack of security proved unworkable both from the provider’s point of view as unauthorized users could receive services without paying for them and from the consumer’s point of view since there was danger of the consumer’s request being hijacked by a “man-in-the-middle” attack and inaccurate data being returned. As development of web services matured the need for security spurred the adoption of SOA Governance conventions and security standards such as the WS-Security addition to the SOAP protocol. SOA governance now establishes networks of trust which restricts which providers can list their services in a UDDI directory. Within the developer community there is a debate as to if securing the connection or securing the message is the higher priority in a SOA framework. Both are important and spur the need for additional sets of agreements the consumer must be aware of. First, protocols for securing the connection between the service provider and consumer must be negotiated. Next, message level security requires that the actual XML document which is the result of the service be encrypted and that encryption scheme needs to be defined in an agreement.