-
MUST support ID-WSF 2.0 SOAP Binding [SOAPBinding2] (this document is highly recommended reading).
-
MAY support ID-WSF 1.2
-
An implementation MUST support the following sec mechs, see [SecMech2]:
-
"urn:liberty:security:2005-02:TLS:Bearer"
-
"urn:liberty:security:2006-08:TLS:SAMLV2" (Holder-of-Key, HoK)
A deployment MAY, as a configuration option, choose either.
-
MAY support following sec mechs for testing, but MUST NOT permit their use in production environments:
-
"urn:liberty:security:2005-02:null:Bearer"
-
"urn:liberty:security:2006-08:null:SAMLV2" (Holder-of-Key, HoK)
-
MAY support other TLS [RFC2246] based sec mechs, including ClientTLS.
-
MUST NOT permit non-TLS sec mechs in production environments
-
Implementations SHOULD be Liberty Alliance certified, see [IDWSF2SCR].
-
Implementations MUST support <ProcessingContext> "urn:liberty:sb:2003-08:ProcessingContext:Simulate"
SOAP header and implement a "dry-run" feature using it.
A deployment MAY, as a configuration option, enable this feature.
Partially satisfies Reqs. D1.2-12.13-Vfy and D1.2-12.16-OnlineTst.
-
An implementation MUST support a health check feature. We RECOMMEND that the health check uses the "dry-run" feature mentioned in the
previous item.
-
<sbf:Framework> SOAP header MUST be supplied and MUST have version XML attribute with value "2.0"
-
<wsse:Security> SOAP header MUST be supplied
-
<wsu:TimeStamp> MUST be included in the <wsse:Security> SOAP header.
-
<a:MessageID> SOAP header MUST be included in all messages.
-
<a:RelatesTo> SOAP header MUST be included in all responses, unless response is an unsolicited (spontaneous, without request) response. Including <a:RelatesTo>
is especially important from audit trail perspective so that pledges
in the request can be linked to the data and obligations delivered in
the response. This rule satisfies message correlation requirement.
This rule upgrades the SHOULD of [SOAPBinding2], p.23, ll.818-822, to MUST.
-
<a:ReplyTo> SOAP header MUST be included in all requests and MUST have value http://www.w3.org/2005/03/addressing/role/anonymous
-
<a:FaultTo> SOAP header MUST NOT be supplied. All faults are sent to <a:ReplyTo> address, i.e. in the same HTTP request-response pair.
-
<b:Sender> SOAP header MUST be included in each web service message. [SOAPBinding2] section 5.9, pp.21-22, is vague about when this is needed.
To simplify matters we make it always mandatory.
-
Request-Response message exchange patterm MUST be supported.
