Aplikacje Web services komunikują się za pomocą wiadomości SOAP (Simple Object Access Protocol zdefiniowany w XML). Takie wiadomości są często transportowane protokołem HTTP, ale - w zasadzie – mogą być przenoszone dowolnym protokołem warstwowym. WSS zapewnia strukturę dla szyfrowania, podpisywania i uwierzytelniania wiadomości SOAP.

WSS definiuje także elementy XML, które mogą być używane do zapewnienia ochrony integralności (zapis), poufności (odczyt) i uwierzytelnienia. Osiąga się to wykorzystując inne specyfikacje, chociaż pewne kluczowe elementy są własnymi rozwiązaniami WSS.

Zobacz również:

• Czy Elon Musk reaktywuje usługę Vine?

WSS implementuje podpisy cyfrowe i szyfrowanie wykorzystując rekomendacje XML digital signature i XML encryption, zaprojektowane przez W3C.

Przetwarzanie podpisów cyfrowych w dokumentach XML jest złożone, ponieważ niewielkie różnice w formatach tego samego dokumentu są traktowane jako bez znaczenia (na przykład: dodawanie lub usuwanie nic nieznaczących spacji). Ponieważ takie ‘odchylenia’ mogą wpływać na zmianę wartości podpisu cyfrowego, koniecznym jest definiowanie standaryzowanego lub, inaczej mówiąc, „kanonicznego” formatu dokumentu XML. Nadawca generuje podpis w oparciu o taką kanoniczną formę dokumentu, a odbiorca przetwarza kanoniczną formę dokumentu w celu weryfikacji podpisu.

Ponieważ Web services będą używane w wielu środowiskach, WSS ma umożliwić używanie różnorodnych systemów dystrybucji kluczy i innych informacji uwierzytelniających, które w specyfikacji określane są jako tokeny. Certyfikaty X.509 i bilety Kerberos są przenoszone w tokenach binarnych, podczas gdy asercje SAML i licencje XrML są tokenami XML. WSS definiuje także tzw. tokeny usere-name, które mogą być używane w powiązaniu z hasłami.

Najważniejszy, nowy element definiowany przez WSS nazywa się Security i zawiera elementy XML powiązane z ochroną wiadomości. Element Security pojawia się w nagłówku SOAP i może być osobny dla każdego węzła, który odbiera wiadomość. Informacja, jaka może być zawarta w elemencie Security pozwala nadawcy powiadamiać odbiorę o tym, które dane zostały podpisane, w jakim porządku mają być wykonywane operacje i jakich kluczy należy użyć. WSS pozwala także nadawcy ustalić datę i czas ważności informacji ochronnych.

Istnieją także odniesienia do tokenów bezpieczeństwa, które są używane do wskazania tokenów w różnych układach, takich np. jak używanie tokenu więcej niż jeden raz w ramach tej samej wiadomości.

WSS nie określa poszczególnych zestawów operacji wymiany i szyfrowania wiadomości, tak jak Kerberos czy SSL/TLS (Secure Socket Layer/Transport Layer Security). Zakłada, że szczegółowe wzorce postępowania czy elementy dla implementacji i optymalizacji złożonych możliwości, opisują inne specyfikacje. Jednakże WSS może być używana bezpośrednio do realizacji prostych potrzeb, takich jak podpisywanie i szyfrowanie fragmentów pojedynczej wiadomości.

WSS składa się z specyfikacji podstawowej i profili dla każdego typu tokenu. Prace nad specyfikacją rozpoczęły się na jesieni roku 2002.

W kwietniu b.r. OASIS zaaprobowała specyfikacje WSS: SOAP Message Security 1.0 oraz WSS: Username Token Profile 1.0 i WSS: X509 Token Profile 1.0. Komitet techniczny WSS pracuje obecnie nad profilami tokenów SAML, Kerberos i XrML.

Do ochrony wiadomości Web services mogą być używane alternatywne mechanizmy, takie jak SSL/TLS. Wielu aplikacjom mogą one zapewnić dostateczny poziom ochrony, ale też mają dużo więcej ograniczeń niż WSS. WSS pozwala np. na podpisywanie i szyfrowanie wybranych fragmentów wiadomości. Możliwym jest też podpisanie wiadomości w jednym węźle i następnie dodanie nowych danych w innym i podpisanie ich przez ten węzeł – wszystko to może być finalnie zweryfikowane przez odbiorcę. Ponadto węzeł pośredni może przetwarzać fragment wiadomości nawet wtedy, gdy pozostałe fragmenty są zaszyfrowane.

W miarę, jak Web services stawać się będą coraz bardziej złożone, będzie też rosnąć potrzeba stosowania specyfikacji WSS.