WS-Policy ist eine Spezifikation des W3C im Rahmen der WS-*-Spezifikationen, die es dem Serviceanbieter ermöglicht, die Richtlinien bezüglich Sicherheit, Qualität und Version seines Services in Form von maschinenlesbaren XML-Daten für den Servicenutzer bereitzustellen. Umgekehrt kann der Servicenutzer seine Anforderungen ebenfalls in Form von XML-Daten spezifizieren. Diese Policies werden dann an entsprechenden Stellen in die WSDL-Beschreibung des Service (oder auch im BPEL-Prozess) eingefügt und gelten als Mindestrichtlinien auch für alle in der Hierarchie tiefer stehenden Elemente. Umgekehrt kann auch ein Servicenutzer seine Anforderung an einen Service in Form von Policies formulieren, so dass dann zur Laufzeit „ausgehandelt“ werden muss, was denn nun die effektive Policy wird.

Zu WS-Policy gehören mehrere Unterspezifikationen:

WS-Policy Assertions beschreibt eine Menge an Standardrichtlinien, die innerhalb einer Policy verwendet werden können.

WS-Policy Attachment beschreibt, in welcher Form Policies mit bestehenden Technologien aus dem Bereich Web Services verknüpft werden können. Wahlweise können sie direkt innerhalb des Elements deklariert werden, auf das sie sich beziehen, oder auch separat und nur referenziert werden.

Eine Policy besteht immer aus einem Element:

<wsp:Policy xmlns:wsp="someURI">

Dieses Element enthält immer eine Auflistung an Alternativen, so könnte beispielsweise ein Bankwebservice vorschreiben, dass die Übertragung verschlüsselt zu erfolgen hat und dabei die konkreten Alternativen DES und AES anbieten. Ein Nutzer des Service müsste demnach, um den Service überhaupt nutzen zu können, die Daten in jedem Fall mit einem der beiden Verfahren verschlüsseln. Ein anderes Verfahren wäre nicht zulässig. Jede Alternative kann aus beliebig vielen Assertions bestehen. Eine Auflistung von Policyalternativen besteht immer aus einem Element <wsp:ExactlyOne> oder einem Element <wsp:All>. Ersterer Fall bedeutet, dass von allen darin enthaltenen Alternativen genau eine gelten muss, zweiterer bedeutet, dass alle darin genannten Alternativen erfüllt sein müssen. Diese beiden Elemente können auch weiter in sich verschachtelt werden. Allerdings hat man sich zur leichteren Verarbeitung von Policies auf eine Normalform geeinigt, so dass sich folgende Struktur ergibt:

<wsp:Policy>
    <wsp:ExactlyOne>
        <wsp:All>
            <!--Liste von Assertions-->
        </wsp:All>
        <wsp:All>
            <!--Liste von Assertions-->
        </wsp:All>
        <wsp:All>
            <!--Liste von Assertions-->
        </wsp:All>
        <!--beliebig viele weitere Elemente vom Typ wsp:All-->
    </wsp:ExactlyOne>
</wsp:Policy>

Gibt es nur eine Alternative, so kann das Element <wsp:ExactlyOne> natürlich entfallen; gleiches gilt für <wsp:All>, wenn eine Alternative nur aus einer Assertion bestehen würde.

Jede Assertion hat ein optionales Attribut wsp:Usage, was angibt, wie diese Assertion zu verwenden ist. Dabei unterscheidet man folgende mögliche Werte:

• Required: Die Assertion wird in jedem Fall angewendet. Sollte sie verletzt werden, wird ein Fehler ausgelöst.
• Rejected: Die Assertion wird explizit nicht unterstützt. Sollte sie dennoch gefordert werden, wird ein Fehler ausgelöst.
• Optional: Die Assertion muss nicht angewendet werden, wird es aber, wenn sie vorhanden ist.
• Observed: Die Assertion wird in jedem Fall angewendet.
• Ignored: Die Assertion wird verarbeitet, aber ignoriert, d. h., sie kann angegeben sein, hat aber keinerlei Einfluss auf die Weiterverarbeitung. Sowohl Serviceanbieter als auch -nutzer werden darüber informiert, dass sie ignoriert wird.

Sowohl Serviceanbieter als auch Servicenutzer können Policies spezifizieren. Dies hat zur Folge, dass die effektive Policy erst zur Laufzeit ausgehandelt werden kann. Genauere Algorithmen, die auf Basis der beiden Requirements die effektive Policy bestimmen, sind noch Gegenstand aktueller Forschung. Zunächst einmal wird es sich bei der effektiven Policy immer um den "kleinsten gemeinsamen Nenner" der jeweiligen Anforderungen handeln. Allerdings ist noch offen, wie dabei auch eine semantische Auswertung der Policy erfolgen soll, da WS-Policy nur die äußere Form einer Policy festlegt und weder etwas über den Inhalt aussagt noch darüber, wie der Inhalt codiert werden soll.

• Eine Policy kann auch leer sein (keine Alternativen enthalten).
• Die Alternativen sind ungeordnet.
• Alternativen in einer Policy können sowohl sehr ähnlich sein als auch völlig verschieden (d. h. die gleiche Assertion kann in mehreren Alternativen vorkommen).
• WS-Policy schreibt vor, wie Policies von Anbieter und Nutzer verbunden werden sollen. Dabei wird die Semantik allerdings ignoriert, bspw. wäre folgende effektive Policy möglich:

<wsp:Policy>
    <SomeAssertion apply="true"/>
    <SomeAssertion apply="false"/>
</wsp:Policy>

• Dezember 2002 vorgestellt von BEA, IBM, Microsoft und SAP
• Mai 2003 aktualisiert
• September 2004 aktualisiert unter Mitarbeit von Sonic und Verisign
• März 2006 erneut aktualisiert
• April 2006 bei W3C eingereicht, so dass eine Arbeitsgruppe eingerichtet werden konnte
• September 2007 als W3C-Recommendation veröffentlicht

• Spezifikation des W3C
• Pressemitteilung WS Policy