2.1 Transport

The wsignin1.0 (section 2.2.3), wsignout1.0 (section 2.2.5), and wsignoutcleanup1.0 (section 2.2.6) requests MUST be transmitted using the GET method; they MUST NOT be transmitted using the POST method. This protocol also restricts wsignin1.0 (section 2.2.4) responses; such responses SHOULD<3> be transmitted to relying parties using the POST method.

The requestor IP/STS and relying party SHOULD<4> use the HTTPS URL scheme to identify each IP/STS  and WS resource for processing wsignin1.0 requests, wsignin1.0 responses, wsignout1.0 requests, and wsignoutcleanup1.0 requests. If the HTTPS URL scheme is not used, each IP/STS and WS resource is assumed to have other protection mechanisms or decided that protection is not necessary.

This protocol uses the redirection facilities of HTTP 1.1, as specified in [WSFederation1.2] section 13, to automate message exchange using the web browser requestor. Compliant web browser requestors MUST support HTTP 1.1 status code 302 redirection.

For wsignin1.0 requests, as depicted in the diagram in [WSFederation1.2] section 13.1.1, the web browser requestor MUST authenticate each IP/STS and the WS resource, using SSL/TLS transport security (for more information, see [RFC2246] and [RFC3546]) and X.509 certificates (as specified in [X509]). Before a security token is issued in response to a wsignin1.0 request message, the user MUST be authenticated to the IP/STS. The method by which the IP/STS verifies the user's identity is not addressed in this protocol. It is assumed here that the user's identity is verified in some way by the IP/STS. Requests for wsignout1.0 and wsignoutcleanup1.0, as depicted in the diagram of [WSFederation1.2] section 13.1.2, are not required<5> to be authenticated.