6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

• Windows Server 2003 R2 operating system

• Windows Server 2008 operating system

• Windows Server 2008 R2 operating system

• Windows Server 2012 operating system

• Windows Server 2012 R2 operating system

• Windows Server 2016 operating system

• Windows Server operating system

• Windows Server 2019 operating system

• Windows Server 2022 operating system

• Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.8: Windows uses the protocol extensions specified in [MS-MWBE]. For further specifications on these extensions, see [MS-MWBE].

<2> Section 1.8: Windows uses the existing extensibility points specified in [WSFederation1.2] as protocol extensions, as specified in [MS-MWBE]. For details on these extensions, see [MS-MWBE].

<3> Section 2.1: Except in the cases specified in [MS-MWBE] section 3.2.5.1.1, Windows uses POST methods to transmit wsignin1.0 responses to relying parties.

<4> Section 2.1: Windows requires use of the HTTPS URL scheme to identify each IP/STS and WS resource participating in the protocol.

<5> Section 2.1: Requests for wsignout1.0 and wsignoutcleanup1.0 are not authenticated by Windows.

<6> Section 2.2: These messages are not supported. For the protocol behavior of Windows for such messages, see section 3.1.5.1.

<7> Section 2.2: Parameters not specified in this document are not supported. For the protocol behavior of Windows on nonspecified parameters, see section 3.1.5.1.

<8> Section 2.2.1: These parameters are not supported. For the protocol behavior of Windows on these parameters, see section 3.1.5.1.

<9> Section 2.2.2: This parameter is supported. For the protocol behavior of Windows on this parameter, see sections 3.1.5.4.7 and 3.3.5.1.2.

<10> Section 2.2.2: This parameter is not supported. For the protocol behavior of Windows for this parameter, see section 3.1.5.1.

<11> Section 2.2.3: On Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 operating system, this message contains either a wtrealm parameter or a wreply parameter. A wtrealm parameter is not mandatory if a wreply parameter is present.

<12> Section 2.2.3: This parameter is supported by Windows. For the protocol behavior of Windows on this parameter, see sections 3.1.5.4.7 and 3.3.5.1.2.

<13> Section 2.2.3: This parameter is supported by Windows. For the protocol behavior of Windows on this parameter, see section 3.3.5.1.2.

<14> Section 2.2.3: The values supported for this parameter are specified in the following table. For the protocol behavior of Windows on this parameter, see sections 3.1.5.4.2 and 3.3.5.1.2

<15> Section 2.2.3: This parameter is conditionally supported. For the supported conditions and processing semantics of Windows for this parameter, see sections 3.1.5.4.2 and 3.3.5.1.2.

<16> Section 2.2.3: The client-request-id parameter is not supported on Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012.

<17> Section 2.2.3: The login_hint parameter is not supported on Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012. Additionally, in Active Directory Federation Services (AD FS), if the ad_fs_behavior_level ADM element, as defined in [MS-OAPX] section 3.2.1.1 (hereafter referred to simply as the AD FS behavior level), is set to AD_FS_BEHAVIOR_LEVEL_2 or higher, this parameter is used to derive the IP/STS that receives the wsignin1.0 request message.

<18> Section 2.2.3: The username parameter is not supported on Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012. Additionally, in AD FS, if the AD FS behavior level is set to AD_FS_BEHAVIOR_LEVEL_2 or higher, this parameter is used to derive the IP/STS that receives the wsignin1.0 request message.

<19> Section 2.2.3: The domain_hint parameter is not supported on Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2. Additionally, it is supported only in AD FS with AD FS behavior level set to AD_FS_BEHAVIOR_LEVEL_2 or higher, and ignored otherwise.

<20> Section 2.2.3: The prompt parameter is not supported on Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012. It is also not supported on Windows Server 2012 R2 unless [MSKB-3172614] is installed.

<21> Section 2.2.3:  Even though AD_FS_BEHAVIOR_LEVEL_3 is supported on Windows Server 2016, the mfa_max_age parameter is supported on Windows Server 2016 only if [MSKB-4088889] is installed.

<22> Section 2.2.4: This parameter is supported. For the protocol behavior of Windows on this parameter, see section 3.1.5.4.7.

<23> Section 2.2.4.1: The AppliesTo element is supported. For the protocol behavior of Windows for the AppliesTo element, see sections 3.1.5.4.7 and 3.3.5.2.2.

<24> Section 2.2.4.1: Optional elements and attributes are not supported. For the protocol behavior of Windows for optional elements and attributes in the RSTR, see 3.1.5.4.7 and 3.3.5.2.2.

<25> Section 2.2.4.2: The Advice element is used by Windows to extend the protocol. These extensions are as specified in [MS-MWBE].

<26> Section 2.2.4.2.1.2: The AttributeStatement is conditionally supported. For more information on the protocol behavior of Windows for AttributeStatements, see sections 3.1.5.4.7 and 3.3.5.2.2.

<27> Section 2.2.4.2.1.2: This namespace is supported. For the protocol behavior of Windows for AttributeNamespace values, see sections 3.1.5.4.7 and 3.3.5.2.2.

<28> Section 2.2.4.2.1.3: On Active Directory Federation Services that shipped with Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2, Windows always specifies the NameIdentifier claim, and the value for the NameIdentifier element is the value of the EmailAddress, user principal name (UPN), or CommonName claim, as specified in the Abstract Data Model in section 3.1.1.4. The NameIdentifier element specifies the Format attribute, as specified in [SAMLCore] section 2.4.2.2. The corresponding value of the Format attribute is one of the following, as specified in the Abstract Data Model (see section 3.1.1.4).

<29> Section 2.2.4.2.1.3: On Active Directory Federation Services that shipped with Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2, the SubjectConfirmation element is not supported. For the protocol behavior of Windows for the SubjectConfirmation element, see sections 3.1.5.4.7 and 3.3.5.2.2.

<30> Section 2.2.4.2.2: Both direct inclusion and SKI are supported for X.509 certificates. For the protocol behavior of Windows for referencing X.509 certificates, see sections 3.1.5.4.7 and 3.3.5.2.2.

<31> Section 2.2.5: The wreply parameter is not supported. For the protocol behavior of Windows for this parameter, see sections 3.1.5.4.7 and 3.3.5.1.2.

<32> Section 2.2.6: The wreply parameter is not supported. For the protocol behavior of Windows for this parameter, see section 3.3.5.4.2.

<33> Section 3.1.1.2: The requestor IP/STS and relying parties use internal data structures similar to Authentication Context and support all of the fields defined for the abstract data model.

<34> Section 3.1.1.3: This information is exchanged using files that can be generated, or consumed, using export or import capabilities. Also, the information can be typed into a management console.

<35> Section 3.1.1.3: Two separate records are used for a federation partner that is capable of playing both roles.

<36> Section 3.1.1.3: Both configurations are supported. If a requestor IP/STS is configured as a farm of servers, each server can use a different private key, or the same private key can be installed on all servers.

<37> Section 3.1.1.3: Metadata exchanged between federation partners includes claims requested by a relying party. A requestor IP/STS stores this information in local configuration data using the ClaimsOut concept.

<38> Section 3.1.1.3: Metadata exchanged between federation partners includes claims requested by a relying party. A relying party stores this information in local configuration data using the ClaimsIn concepts.

<39> Section 3.1.1.3: A requestor IP/STS includes as many claims as possible based on the attributes available for the user that is the subject of the security token. It sends the security token even if not all of the requested claims can be generated.

<40> Section 3.1.1.4: A requestor IP/STS includes optional claims requested by a relying party in the AttributeStatement of the security token issued.

<41> Section 3.1.1.4: Federation partners, performing either the requestor IP/STS or the relying party role, support the EmailAddress, UPN, CommonName, and Group claims, as defined in section 3.1.1.4. Based on local configuration, relying parties interpret Group claims as strings or map them to specific group objects defined in Active Directory.

<42> Section 3.1.1.4: Federation partners, performing either the requestor IP/STS or the relying party role, support the Custom claim as defined. Windows rejects any request containing an AttributeNamespace value other than http://schemas.xmlsoap.org/claims with an HTTP 1.1 status code 500 server error.

<43> Section 3.1.1.5: HTTP session cookies, as specified in [RFC2965], are used to identify individual web browser requestors.

<44> Section 3.1.1.5.1: An HTTP session cookie, as specified in [RFC2965], is issued to a web browser requestor to manage the list of relying parties that are to be sent wsignoutcleanup1.0 messages when the user requests to sign out. The cookie is rewritten for every new security token that is issued for the web browser requestor session.

<45> Section 3.1.1.5.2: An HTTP session cookie, as specified in [RFC2965], is issued to a web browser requestor to manage the list of requestor IP/STSs that are to be sent wsignout1.0 messages when the user requests to sign out. The cookie is rewritten for every new security token that is received for the web browser requestor session.

<46> Section 3.1.2: A web browser requestor access request, such as an HTTP GET or POST, for a particular URL managed by a WS resource is rejected if the validity interval of the Authentication Context for the user has expired. Once an access request has been accepted, it will be processed even if the validity interval expires before the response is returned to the web browser requestor.

<47> Section 3.1.2: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens and recoded in Authentication Contexts are checked explicitly.

<48> Section 3.1.5.1: Federation partners do not emit query string parameters when sending a protocol message using an HTTP POST. If any query string parameters are received with an HTTP POST, they are ignored.

<49> Section 3.1.5.1: The xml-attribute-request and the xml-pseudonym-request messages described in section 2.2 are not emitted by Windows. Windows Server 2003 R2 returns an HTTP 403 error message. With the exception of Windows Server 2003 R2, all applicable Windows Server releases return an HTTP 500 error message if they receive such messages. Any parameters that are not specified in section 2.2 or in the protocol extension specified in [MS-MWBE] are ignored by Windows.

<50> Section 3.1.5.2: An unsupported or unrecognized parameter received with a protocol message is ignored, and the message is processed as if it were not present.

<51> Section 3.1.5.2: SOAP faults are not used. An HTTP 500 error response is returned to the web browser requestor.

<52> Section 3.1.5.3.2: A WS resource stores the application URL in the wctx parameter. A resource IP/STS stores the WS resource URL in the wctx parameter by prepending it to the incoming value.

<53> Section 3.1.5.3.3: A web browser requestor can send an HTTP GET with whr, domain_hint, username, or login_hint directly to WS resource URLs. A relying party uses the whr parameter for security realm discovery when present. If whr is not present, AD FS server with an AD FS behavior level of AD_FS_BEHAVIOR_LEVEL_2 or higher will additionally use domain_hint, username, or login_hint for security realm discovery. The resource IP/STS is expected to know how to translate the hint (or get it translated) to a URI that uniquely identifies the requestor IP/STS. See [OIDCCore] section 3.1.2.1 for recommendations on login_hint. If no realm can be identified, a resource IP/STS displays an HTML form to collect the information from the user.

If whr, domain_hint, username, and login_hint coexist in one request, the precedence, in descending order, for their use in identifying the requestor IP/STS is as follows:

• whr

• domain_hint

• username

• login_hint

<54> Section 3.1.5.3.3: A resource IP/STS writes a persistent cookie (for more information, see [RFC2965]) to the web browser requestor to preserve the value of the security realm identifier.

<55> Section 3.1.5.4.2: On Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2, if a resource IP/STS receives a request that has both the wreply and wtrealm parameters set, the resource IP/STS returns an HTTP 1.1 status code 500 server error. If a requestor IP/STS receives a request that has both the wreply and wtrealm parameters set, the requestor IP/STS ignores the wreply.

<56> Section 3.1.5.4.2: If the wauth parameter, which is described in section 2.2.3, is present and is not set to one of the values from the table in that section, Windows returns an HTTP 1.1 status code 500 server error.

<57> Section 3.1.5.4.3: An IP/STS can authenticate a user by means of the Windows implementation of Kerberos (for more information, see [RFC4120]) by collecting the user's Windows identifier and password in an HTML form (using HTTPS) and validating the credentials with Active Directory, or by client SSL authentication using an X.509 certificate [X509] issued to the web browser requestor. An IP/STS can also authenticate the user by initiating the Microsoft Web Browser Federated Sign-On Protocol with another STS.

<58> Section 3.1.5.4.4: Attributes are retrieved from either Active Directory or Active Directory Application Mode using authenticated LDAP binds.

<59> Section 3.1.5.4.7: The following Windows behaviors apply for response message processing:

• The wctx parameter specified in section 2.2.2 is always returned by Windows with the response if the parameter is present in the request.

• When emitting wsignin1.0 responses, Windows includes the wsp:AppliesTo element.

• When emitting wsignin1.0 response messages, Windows does not include any other optional elements or attributes in the RSTR.

• The presence of the SAML AttributeStatement in the SAML assertion in a wsignin1.0 response message emitted by Windows depends on configuration of the product. Windows supports emitting both no SAML AttributeStatement and one SAML AttributeStatement. Windows includes a SAML AttributeStatement when more than one claim is included in the token. For further specifications, see sections 3.1.1.4 and 3.1.5.

• When emitting wsignin1.0 response messages, Windows uses the namespace http://schemas.xmlsoap.org/claims.

• On Active Directory Federation Services that shipped with Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2, Windows does not specify the SubjectConfirmation element when emitting wsignin1.0 response messages.

• When emitting wsignin1.0 response messages, Windows includes the X.509 certificate directly in the KeyInfo element by default. Windows does not reference X.509 certificates [X509] using the X509SKI element by default when emitting wsignin1.0 response messages. Windows can be configured to use the X509SKI element when emitting wsignin1.0 response messages.

<60> Section 3.1.6: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens and recoded in Authentication Contexts are checked explicitly.

<61> Section 3.2.5.2.2: An STS, regardless of role, sends wsignoutcleanup1.0 messages to relying parties. An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of relying parties that are to be sent wsignoutcleanup1.0 messages when the user requests to sign out. A requestor IP/STS does not cache any user or web browser requestor session data on a server.

<62> Section 3.2.5.2.3: The wreply parameter is not supported for wsignout1.0 request messages, so the web browser requestor is not redirected after wsignoutcleanup1.0 messages are sent.

<63> Section 3.2.5.3.2: An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of relying parties. A requestor IP/STS sends wsignoutcleanup1.0 messages to all relying parties identified in the session cookie when a user requests to sign-out.

<64> Section 3.2.5.3.3: All of the web browser requestor session state that needs to be deleted is maintained in an HTTP session cookie (for more information, see [RFC2965]). This cookie is deleted as part of the process of sending wsignoutcleanup1.0 messages.

<65> Section 3.2.5.3.4: When a wsignout1.0 message is received, Windows sends a wsignoutcleanup1.0 message to all relying parties identified by the Outbound Sessions List maintained for the web browser requestor. An HTML page that contains a set of IFrames, one for each WS resource, is constructed. In the process of returning this HTML page to the web browser requestor, the HTTP session cookie used to maintain the Outbound Sessions List is deleted. Processing of the iframes in this HTML page by the web browser requestor causes the wsignoutcleanup1.0 messages to be sent in parallel. Windows does not use the wreply parameter when emitting wsignoutcleanup1.0 messages.

<66> Section 3.2.6: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens (see section 2.2.4.2) and recoded in Authentication Contexts are checked explicitly.

<67> Section 3.3.1: A relying party is implemented as separate resource IP/STS and WS resource components. This factorization is used whether or not the components are deployed on the same server or on different servers.

<68> Section 3.3.1: A relying party is factored into separate resource IP/STS and WS resource components even if the components are located on the same server. Interactions between the resource IP/STS and WS resource are not exposed to requestor IP/STSs in other security realms.

<69> Section 3.3.1.1: The roles a federation partner can perform are indicated in configuration data, as described in section 3.3.1.1. This information is obtained using out-of-band metadata exchange. Files can be exchanged using export or import capabilities, or the data can be typed into a management console.

<70> Section 3.3.1.1: Federation partner URLs are maintained in configuration data. This configuration data is always treated as authoritative versus the value of a wreply parameter received in a wsignin1.0 message.

<71> Section 3.3.2: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens, as specified in section 2.2.4.2, and recoded in Authentication Contexts are checked explicitly. A resource IP/STS or a WS resource will reject a security token for which the validity interval has expired. A WS resource maintains a user's Authentication Context in an HTTP session cookie (for more information, see [RFC2965]). The cookie is signed to prevent undetected manipulation. The WS resource will return an HTTP 500 error for any request that is accompanied by a session cookie for which the validity interval has expired.

<72> Section 3.3.3: By default, relying parties support CRL checking by means of a CDP. However, if the CDP is not accessible, CRL checking can be disabled to prevent otherwise acceptable security tokens from being rejected.

<73> Section 3.3.5.1.1: A dialect of the Microsoft Web Browser Federated Sign-On Protocol is used, with the WS resource acting as a relying party and the resource IP/STS acting as a requestor IP/STS. The WS resource sends a wsignin1.0 request message to the resource IP/STS to request a security token for the user.

<74> Section 3.3.5.1.2: The following Windows behaviors apply when marshaling parameters for a request message:

• When a WS resource sends a wsignin1.0 request message, the wtrealm parameter described in Common Syntax for Request Messages (section 2.2.1) cannot be used because the WS resource and the resource IP/STS are located in the same security realm. Because the wtrealm parameter identifies a security realm, the wtrealm parameter cannot be used to distinguish different federation partners in the same security realms. The wreply parameter is used instead, and it is set to the URL of the WS resource.

• Windows also includes the wctx parameter specified in Common Syntax for Response Messages (section 2.2.2) and wsignin1.0 request message (section 2.2.3) to preserve any URL parameters of the original HTTP request to the relying party.

• Windows always includes the wct parameter specified in the wsignin1.0 request message (section 2.2.3) in the request message.

• By default, Windows does not emit the wauth parameter specified in the wsignin1.0 request message (section 2.2.3). Windows can be configured to issue the wauth parameter and will issue a wauth parameter with one of the URIs specified in wsignin1.0 request message (section 2.2.3).

• The whr parameter specified in wsignin1.0 request message (section 2.2.3) is not emitted by a relying party unless the whr parameter is received on the original request to the Windows relying party and the destination IP/STS is in the same security realm. If a Windows resource IP/STS acting as a relying party receives the whr parameter specified in wsignin1.0 request message (section 2.2.3), the wsigin1.0 request message is forwarded to the requestor IP/STS corresponding to the URI value. The whr parameter is not included in the request forwarded to the Windows requestor IP/STS. If no requestor IP/STS corresponds to the URI value of the whr parameter, Windows ignores the parameter.

<75> Section 3.3.5.2.2: The following Windows behaviors apply when validating wsignin1.0 response messages:

• Windows processes wsp:AppliesTo messages according to the message syntax requirements specified in section 2.2.4.1 when receiving wsignin1.0 responses.

• Windows ignores any other optional elements included in the RSTR when processing received wsignin1.0 response messages.

• Windows supports processing both no SAML AttributeStatement and one SAML AttributeStatement when receiving wsignin1.0 responses.

• Windows rejects the security token with an HTTP 1.1 500 error code if a wsignin1.0 response is received with an Attribute element that has an AttributeNamespace value other than http://schemas.xmlsoap.org/claims.

• When processing received wsignin1.0 messages, Windows ignores the SubjectConfirmation element, if present.

• When receiving wsignin1.0 responses, Windows uses the certificate included directly in the X509Certificate element, if present. When receiving wsignin1.0 responses, Windows uses the SKI, if present, to look up the corresponding certificate and continue to process the message. A failed look-up will result in the wsignin1.0 response messages being rejected with an HTTP 1.1 500 server error.

• When receiving wsignin1.0 responses, Windows rejects any messages with the EncryptedData element described in section 2.2.4.1 with an HTTP 1.1 500 server error.

<76> Section 3.3.5.2.4: A user's identity from the Subject element of the security token is mapped to a local Windows security principal identity in Active Directory based on local configuration. In terms of the Authentication Context abstract data model, the local Windows security principal identity replaces the AuthIdentity value derived from the Subject of a security token.

<77> Section 3.3.5.2.6: The Microsoft Web Browser Federated Sign-On Protocol is used with the WS resource acting as a relying party and the resource IP/STS acting as a requestor IP/STS. The resource IP/STS sends a wsignin1.0 response message to the WS resource to issue a security token for the user. There is no change to the protocol message processing, as specified in section Issuing a Security Token by responding to a wsignin1.0 request message (section 3.1.5.4).

<78> Section 3.3.5.3.2: The wreply parameter described in section wsignout1.0 Request Message (section 2.2.5) is not supported when emitting wsignout1.0 Request Messages.

<79> Section 3.3.5.3.3: Relying party components, both resource IP/STSs and WS resources, send wsignout1.0 messages to security token services. An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of security token services that are to be sent wsignout1.0 messages when the user requests to sign-out.

<80> Section 3.3.5.4.2: A security token service, regardless of role, sends wsignoutcleanup1.0 messages to relying parties. An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of relying parties that are to be sent wsignoutcleanup1.0 messages when the user requests to sign-out. A resource IP/STS does not cache any user or web browser requestor session data on a server.

<81> Section 3.3.5.4.3: A security token service, regardless of role, sends wsignoutcleanup1.0 request messages to relying parties. An HTTP session cookie (for more information, see [RFC2965]) is issued to a web browser requestor to manage the list of relying parties that are to be sent wsignoutcleanup1.0 messages when the user requests to sign-out.

<82> Section 3.3.5.4.4: An HTML page that contains a set of iframes (as specified in [HTML] section 16.5), one for each WS resource, is returned to the web browser requestor. Processing of the iframes by the web browser requestor causes the wsignoutcleanup1.0 messages to be sent in parallel.

<83> Section 3.3.5.4.5: When receiving a wsignoutcleanup1.0 request message (section 2.2.6), the web browser requestor is not redirected to the wreply URL after sign-out processing is complete. Windows completes by returning a string indicating that clean up is complete for the security realm, regardless of the presence of wreply.

<84> Section 3.3.6: Timers are not used to determine when validity intervals expire. The NotBefore and NotOnOrAfter values obtained from security tokens, as specified in section 2.2.4.2, and recoded in Authentication Contexts are checked explicitly.

<85> Section 3.4.1: Windows Internet Explorer supports the use of session and persistent HTTP cookies (for more information, see [RFC2965]). The Microsoft implementation of this protocol requires that web browser requestors support at least session cookies. It uses persistent cookies to preserve security realm identifiers if they are supported by the web browser requestor.

<86> Section 3.4.5: The RMS 2.0 client in Windows Vista operating system with Service Pack 1 (SP1), Windows 7 operating system, Windows 8 operating system, Windows 8.1 operating system, and Windows 10 operating system, and the RMS 2.0 client in all applicable Windows Server releases with the exception of Windows Server 2003 R2, adds a whr parameter to the wsignin 1.0 Request Message (section 2.2.3) if the wsignin 1.0 Request Message does not already contain a whr parameter.

<87> Section 5.1.1: The Windows IP/STS only supports the Rivest-Shamir-Adleman (RSA) algorithm ([RFC8017]) for signatures, and supports the SHA-1 algorithm (see [FIPS180]) for calculating digests. The default key length of the Windows RSA keys used for signing security tokens is 2,048 bits.

<88> Section 5.1.2: The certificate validation behavior of Windows is configurable. By default, for certificates used to sign security tokens, Windows ensures that the current time is in the certificate's validity interval, that the certificate has a valid signature, that the certificate is issued by a trusted authority, and that the certificate serial number is not present in the CRL of the issuing authority.

<89> Section 5.1.3: The use of SSL/TLS is required for each Windows IP/STS and WS resource.

<90> Section 5.1.4: The validity period of security tokens issued by the Windows IP/STS is limited to 8 hours by default.

<91> Section 5.1.5: The Windows requestor IP/STS can be configured to issue a different identifier to each resource IP/STS for each user to prevent correlation of user information across multiple relying parties. This behavior is turned off by default.

<92> Section 5.1.6: The Windows resource IP/STS requires that messages from each requestor IP/STS be restricted to only using a specific set of suffix DNS names when UPN or EmailAddress is used as the unique identifier for the user by that requestor IP/STS.

<93> Section 5.1.7: Windows sets cookies as secure.