Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)

Transcription

1 Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) Committee Specification 01, 31 May 2002 Document identifier: cs-sstc-bindings-01 (PDF, Word) Location: Editor: Prateek Mishra, Netegrity ([email protected]) Contributors: Irving Reid, Baltimore Technologies Krishna Sankar, Cisco Systems Simon Godik, Crosslogix Tim Moses, Entrust Inc. Scott Cantor, Ohio State University and Internet2 Robert Philpott, RSA Security Evan Prodromou, formerly with Securant Chris Ferris, Sun Microsystems Jeff Hodges, Sun Microsystems Eve Maler, Sun Microsystems Bob Blakley, Tivoli Marlena Erdos, Tivoli RL Bob Morgan, University of Washington and Internet2 Abstract: This specification defines protocol bindings and profiles for the use of SAML assertions and request-response messages in communications protocols and frameworks. Status: This is a stable Committee Specification that is undergoing a vote of the OASIS membership in pursuit of OASIS Standard status. If you are on the [email protected] list for committee members, send comments there. If you are not on that list, subscribe to the [email protected] list and send comments there. To subscribe, send an message to [email protected] with the word "subscribe" as the body of the message. cs-sstc-bindings May 2002

2 The errata document for this specification is located at Its document identifier is draft-sstc-cs-errata-nn. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Security Services TC web page ( Copyright 2001, 2002 The Organization for the Advancement of Structured Information Standards [OASIS] cs-sstc-bindings May 2002

3 Table of Contents 1 Introduction Protocol Binding and Profile Concepts Notation Specification of Additional Protocol Bindings and Profiles Guidelines for Specifying Protocol Bindings and Profiles Process Framework for Describing and Registering Protocol Bindings and Profiles Protocol Bindings SOAP Binding for SAML Required Information Protocol-Independent Aspects of the SAML SOAP Binding Basic Operation SOAP Headers Authentication Message Integrity Confidentiality Use of SOAP over HTTP HTTP Headers Authentication Message Integrity Message Confidentiality Security Considerations Error Reporting Example SAML Message Exchange Using SOAP over HTTP Profiles Web Browser SSO Profiles of SAML Browser/Artifact Profile of SAML Required Information Preliminaries Step 1: Accessing the Inter-Site Transfer Service Step 2: Redirecting to the Destination Site Step 3: Accessing the Artifact Receiver URL Steps 4 and 5: Acquiring the Corresponding Assertions Step 6: Responding to the User s Request for a Resource Artifact Format Threat Model and Countermeasures Stolen Artifact Attacks on the SAML Protocol Message Exchange Malicious Destination Site Forged SAML Artifact Browser State Exposure Browser/POST Profile of SAML Required Information Preliminaries...19 cs-sstc-bindings May 2002

4 Step 1: Accessing the Inter-Site Transfer Service Step 2: Generating and Supplying the Response Step 3: Posting the Form Containing the Response Step 4: Responding to the User s Request for a Resource Threat Model and Countermeasures Stolen Assertion MITM Attack Forged Assertion Browser State Exposure Confirmation Method Identifiers Holder of Key Sender Vouches SAML Artifact Bearer Use of SSL 3.0 or TLS SAML SOAP Binding Web Browser Profiles of SAML References URL Size Restriction (Non-Normative) Alternative SAML Artifact Format Required Information Format Details...29 Appendix A. Acknowledgments...30 Appendix B. Notices...31 cs-sstc-bindings May 2002

5 Introduction This document specifies protocol bindings and profiles for the use of SAML assertions and requestresponse messages in communications protocols and frameworks. A separate specification [SAMLCore] defines the SAML assertions and request-response messages themselves. 1.1 Protocol Binding and Profile Concepts Mappings from SAML request-response message exchanges into standard messaging or communication protocols are called SAML protocol bindings (or just bindings). An instance of mapping SAML requestresponse message exchanges into a specific protocol <FOO> is termed a <FOO> binding for SAML or a SAML <FOO> binding. For example, an HTTP binding for SAML describes how SAML request and response message exchanges are mapped into HTTP message exchanges. A SAML SOAP binding describes how SAML request and response message exchanges are mapped into SOAP message exchanges. Sets of rules describing how to embed and extract SAML assertions into a framework or protocol are called profiles of SAML. A profile describes how SAML assertions are embedded in or combined with other objects (for example, files of various types, or protocol data units of communication protocols) by an originating party, communicated from the originating site to a destination, and subsequently processed at the destination. A particular set of rules for embedding SAML assertions into and extracting them from a specific class of <FOO> objects is termed a <FOO> profile of SAML. For example, a SOAP profile of SAML describes how SAML assertions can be added to SOAP messages, how SOAP headers are affected by SAML assertions, and how SAML-related error states should be reflected in SOAP messages. The intent of this specification is to specify a selected set of bindings and profiles in sufficient detail to ensure that independently implemented products will interoperate. For other terms and concepts that are specific to SAML, refer to the SAML glossary [SAMLGloss]. 1.2 Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC2119]. Listings of productions or other normative code appear like this. Example code listings appear like this. Note: Non-normative notes and explanations appear like this. Conventional XML namespace prefixes are used throughout this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example: The prefix saml: stands for the SAML assertion namespace [SAMLCore]. The prefix samlp: stands for the SAML request-response protocol namespace [SAMLCore]. The prefix ds: stands for the W3C XML Signature namespace, [XMLSig]. The prefix SOAP-ENV: stands for the SOAP 1.1 namespace, [SOAP1.1]. cs-sstc-bindings May 2002

6 This specification uses the following typographical conventions in text: <SAMLElement>, <ns:foreignelement>, Attribute, OtherCode. In some cases, angle brackets are used to indicate nonterminals, rather than XML elements; the intent will be clear from the context. cs-sstc-bindings May 2002

7 Specification of Additional Protocol Bindings and Profiles This specification defines a selected set of protocol bindings and profiles, but others will need to be developed. It is not possible for the OASIS SAML Technical Committee to standardize all of these additional bindings and profiles for two reasons: it has limited resources and it does not own the standardization process for all of the technologies used. The following sections offer guidelines for specifying bindings and profiles and a process framework for describing and registering them. 2.1 Guidelines for Specifying Protocol Bindings and Profiles This section provides a checklist of issues that MUST be addressed by each protocol binding and profile. 1. Describe the set of interactions between parties involved in the binding or profile. Any restriction on applications used by each party and the protocols involved in each interaction must be explicitly called out 2. Identify the parties involved in each interaction, including: how many parties are involved, and whether intermediaries may be involved. 3. Specify the method of authentication of parties involved in each interaction, including whether authentication is required and acceptable authentication types. 4. Identify the level of support for message integrity. What mechanisms are used to ensure message integrity? 5. Identify the level of support for confidentiality, including whether a third party may view the contents of SAML messages and assertions, whether the binding or profile requires confidentiality and the mechanisms recommended for achieving confidentiality. 6. Identify the error states, including the error states at each participant, especially those that receive and process SAML assertions or messages. 7. Identify security considerations, including analysis of threats and description of countermeasures. 8. Identify SAML confirmation method identifiers defined and/or utilized by the binding or profile. 2.2 Process Framework for Describing and Registering Protocol Bindings and Profiles For any new protocol binding or profile to be interoperable, it needs to be openly specified. The OASIS SAML Technical Committee will maintain a registry and repository of submitted bindings and profiles titled Additional Bindings and Profiles at the SAML website ( in order to keep the SAML community informed. The Committee will also provide instructions for submission of bindings and profiles by OASIS members. When a profile or protocol binding is registered, the following information MUST be supplied: 1. Identification: Specify a URI that uniquely identifies this protocol binding or profile. 2. Contact information: Specify the postal or electronic contact information for the author of the protocol binding or profile. 3. Description: Provide a text description of the protocol binding or profile. The description SHOULD follow the guidelines in Section Updates: Provide references to previously registered protocol bindings or profiles that the current entry improves or obsoletes. cs-sstc-bindings May 2002

8 Protocol Bindings The following sections define SAML protocol bindings sanctioned by the OASIS SAML Committee. Only one binding, the SAML SOAP binding, is defined. 3.1 SOAP Binding for SAML SOAP (Simple Object Access Protocol) 1.1 [SOAP1.1] is a specification for RPC-like interactions and message communications using XML and HTTP. It has three main parts. One is a message format that uses an envelope and body metaphor to wrap XML data for transmission between parties. The second is a restricted definition of XML data for making strict RPC-like calls through SOAP, without using a predefined XML schema. Finally, it provides a binding for SOAP messages to HTTP and extended HTTP. The SAML SOAP binding defines how to use SOAP to send and receive SAML requests and responses. Like SAML, SOAP can be used over multiple underlying transports. This binding has protocolindependent aspects, but also calls out the use of SOAP over HTTP as REQUIRED (mandatory to implement) Required Information Identification: urn:oasis:names:tc:saml:1.0:bindings:soap-binding Contact information: [email protected] Description: Given below. Updates: None Protocol-Independent Aspects of the SAML SOAP Binding The following sections define aspects of the SAML SOAP binding that are independent of the underlying protocol, such as HTTP, on which the SOAP messages are transported Basic Operation SOAP messages consist of three elements: an envelope, header data, and a message body. SAML request-response protocol elements MUST be enclosed within the SOAP message body. SOAP 1.1 also defines an optional data encoding system. This system is not used within the SAML SOAP binding. This means that SAML messages can be transported using SOAP without re-encoding from the "standard" SAML schema to one based on the SOAP encoding. The system model used for SAML conversations over SOAP is a simple request-response model. 1. A system entity acting as a SAML requester transmits a SAML <Request> element within the body of a SOAP message to a system entity acting as a SAML responder. The SAML requester MUST NOT include more than one SAML request per SOAP message or include any additional XML elements in the SOAP body. 2. The SAML responder MUST return either a <Response> element within the body of another SOAP message or a SOAP fault code. The SAML responder MUST NOT include more than one SAML response per SOAP message or include any additional XML elements in the SOAP body. If a SAML responder cannot, for some reason, process a SAML request, it MUST return a SOAP fault code. SOAP fault codes MUST NOT be sent for errors within the SAML problem domain, for example, inability to find an extension schema or as a signal that the subject is not authorized to access a resource in an authorization query. (SOAP 1.1 faults and fault codes are discussed in [SOAP1.1] 4.1.) cs-sstc-bindings May 2002

9 On receiving a SAML response in a SOAP message, the SAML requester MUST NOT send a fault code or other error messages to the SAML responder. Because the format for the message interchange is a simple request-response pattern, adding additional items such as error conditions would needlessly complicate the protocol. [SOAP1.1] references an early draft of the XML Schema specification including an obsolete namespace. SAML requesters SHOULD generate SOAP documents referencing only the final XML schema namespace. SAML responders MUST be able to process both the XML schema namespace used in [SOAP1.1] as well as the final XML schema namespace SOAP Headers A SAML requester in a SAML conversation over SOAP MAY add arbitrary headers to the SOAP message. This binding does not define any additional SOAP headers. Note: The reason other headers need to be allowed is that some SOAP software and libraries might add headers to a SOAP message that are out of the control of the SAMLaware process. Also, some headers might be needed for underlying protocols that require routing of messages. A SAML responder MUST NOT require any headers for the SOAP message. Note: The rationale is that requiring extra headers will cause fragmentation of the SAML standard and will hurt interoperability Authentication Authentication of both the SAML requester and responder is OPTIONAL and depends on the environment of use. Authentication protocols available from the underlying substrate protocol MAY be utilized to provide authentication. Section describes authentication in the SOAP over HTTP environment Message Integrity Message integrity of both SAML request and response is OPTIONAL and depends on the environment of use. The security layer in the underlying substrate protocol MAY be used to ensure message integrity. Section describes support for message integrity in the SOAP over HTTP environment Confidentiality Confidentiality of both SAML request and response is OPTIONAL and depends on the environment of use. The security layer in the underlying substrate protocol MAY be used to ensure message confidentiality. Section describes support for confidentiality in the SOAP over HTTP environment Use of SOAP over HTTP A SAML processor that claims conformance to the SAML SOAP binding MUST implement SAML over SOAP over HTTP. This section describes certain specifics of using SOAP over HTTP, including HTTP headers, error reporting, authentication, message integrity and confidentiality. The HTTP binding for SOAP is described in [SOAP1.1] 6.0. It requires the use of a SOAPAction header as part of a SOAP HTTP request. A SAML responder MUST NOT depend on the value of this header. A SAML requester MAY set the value of SOAPAction header as follows: HTTP Headers HTTP proxies MUST NOT cache responses carrying SAML assertions. cs-sstc-bindings May 2002

10 Both of the following conditions apply when using HTTP 1.1: If the value of the Cache-Control header field is not set to no-store, then the SAML responder MUST NOT include the Cache-Control header field in the response. If the Expires response header field is not disabled by a Cache-Control header field with a value of no-store, then the Expires field SHOULD NOT be included. There are no other restrictions on HTTP headers Authentication The SAML requester and responder MUST implement the following authentication methods: 1. No client or server authentication. 2. HTTP basic client authentication [RFC2617] with and without SSL 3.0 or TLS HTTP over SSL 3.0 or TLS 1.0 (see Section 6) server authentication with a server-side certificate. 4. HTTP over SSL 3.0 or TLS 1.0 client authentication with a client-side certificate. If a SAML responder uses SSL 3.0 or TLS 1.0, it MUST use a server-side certificate Message Integrity When message integrity needs to be guaranteed, SAML responders MUST use HTTP over SSL 3.0 or TLS1.0 (see Section 6) with a server-side certificate Message Confidentiality When message confidentiality is required, SAML responders MUST use HTTP over SSL 3.0 or TLS 1.0 (see Section 6) with a server-side certificate Security Considerations Before deployment, each combination of authentication, message integrity and confidentiality mechanisms SHOULD be analyzed for vulnerability in the context of the deployment environment. See the SAML security considerations document [SAMLSec] for a detailed discussion. RFC 2617 [RFC2617] describes possible attacks in the HTTP environment when basic or messagedigest authentication schemes are used Error Reporting A SAML responder that refuses to perform a message exchange with the SAML requester SHOULD return a "403 Forbidden" response. In this case, the content of the HTTP body is not significant. As described in [SOAP1.1] 6.2, in the case of a SOAP error while processing a SOAP request, the SOAP HTTP server MUST return a "500 Internal Server Error" response and include a SOAP message in the response with a SOAP fault element. This type of error SHOULD be returned for SOAPrelated errors detected before control is passed to the SAML processor, or when the SOAP processor reports an internal error (for example, the SOAP XML namespace is incorrect, the SAML schema cannot be located, the SAML processor throws an exception, and so on). In the case of a SAML processing error, the SOAP HTTP server MUST respond with "200 OK" and include a SAML-specified error description as the only child of the <SOAP-ENV:Body> element. For more information about SAML error codes, see the SAML assertion and protocol specification [SAMLCore] Example SAML Message Exchange Using SOAP over HTTP Following is an example of a request that asks for an assertion containing an authentication statement from a SAML authentication authority. cs-sstc-bindings May 2002

11 POST /SamlService HTTP/1.1 Host: Content-Type: text/xml Content-Length: nnn SOAPAction: <SOAP-ENV:Envelope xmlns:soap-env= > <SOAP-ENV:Body> <samlp:request xmlns:samlp:= xmlns:saml= xmlns:ds= > <ds:signature> </ds:signature> <samlp:authenticationquery> </samlp:authenticationquery> </samlp:request> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Following is an example of the corresponding response, which supplies an assertion containing authentication statement as requested. HTTP/ OK Content-Type: text/xml Content-Length: nnnn <SOAP-ENV:Envelope xmlns:soap-env= > <SOAP-ENV:Body> <samlp:response xmlns:samlp= xmlns:saml= xmlns:ds= > <Status> <StatusCodevalue= samlp:success /> </Status> <ds:signature> </ds:signature> <saml:assertion> <saml:authenticationstatement> </saml:authenticationstatement> </saml:assertion> </samlp:response> </SOAP-Env:Body> </SOAP-ENV:Envelope> cs-sstc-bindings May 2002

12 Profiles The following sections define profiles of SAML that are sanctioned by the OASIS SAML Committee. Two web browser-based profiles that are designed to support single sign-on (SSO), supporting Scenario 1-1 of the SAML requirements document [SAMLReqs]: The browser/artifact profile of SAML The browser/post profile of SAML For each type of profile, a section describing the threat model and relevant countermeasures is also included. 4.1 Web Browser SSO Profiles of SAML In the scenario supported by the web browser SSO profiles, a web user authenticates herself to a source site. The web user then uses a secured resource at a destination site, without directly authenticating to the destination site. The following assumptions are made about this scenario for the purposes of these profiles: The user is using a standard commercial browser and has authenticated to a source site by some means outside the scope of SAML. The source site has some form of security engine in place that can track locally authenticated users [WEBSSO]. Typically, this takes the form of a session that might be represented by an encrypted cookie or an encoded URL or by the use of some other technology [SESSION]. This is a substantial requirement but one that is met by a large class of security engines. At some point, the user attempts to access a target resource available from the destination site, and subsequently, through one or more steps (for example, redirection), arrives at an inter-site transfer service (which may be associated with one or more URIs) at the source site. Starting from this point, the web browser SSO profiles describe a canonical sequence of HTTP exchanges that transfer the user browser to an assertion consumer service at the destination site. Information about the SAML assertions provided by the source site and associated with the user, and the desired target, is conveyed from the source to the destination site by the protocol exchange. The assertion consumer service at the destination site can examine both the assertions and the target information and determine whether to allow access to the target resource, thereby achieving web SSO for authenticated users originating from a source site. Often, the destination site also utilizes a security engine that will create and maintain a session, possibly utilizing information contained in the source site assertions, for the user at the destination site. The following figure illustrates this basic template for achieving SSO. cs-sstc-bindings May 2002

13 Browser 1. User authenticates to source site Source Site Destination Site 2. User accesses inter-site transfer services with target information 3. User accesses assertion consumer service with information about SAML assertions and target User obtains access to desired resource, OR is given an error message Two HTTP-based techniques are used in the web browser SSO profiles for conveying information from one site to another via a standard commercial browser. SAML artifact: A SAML artifact of small bounded size is carried as part of a URL query string such that, when the artifact is conveyed to the source site, the artifact unambiguously references an assertion. The artifact is conveyed via redirection to the destination site, which then acquires the referenced assertion by some further steps. Typically, this involves the use of a registered SAML protocol binding. This technique is used in the browser/artifact profile of SAML. Form POST: SAML assertions are uploaded to the browser within an HTML form and conveyed to the destination site as part of an HTTP POST payload when the user submits the form. This technique is used in the browser/post profile of SAML. Cookies are not employed in any profile, as cookies impose the limitation that both the source and destination site belong to the same "cookie domain." In the discussion of the web browser SSO profiles, the term SSO assertion will be used to refer to an assertion that has (1) a <saml:conditions> element with NotBefore and NotOnOrAfter attributes present, and (2) contains one or more authentication statements Browser/Artifact Profile of SAML Required Information Identification: urn:oasis:names:tc:saml:1.0:profiles:artifact-01 Contact information: [email protected] SAML Confirmation Method Identifiers: The "SAML artifact" confirmation method identifier is used by this profile. The following identifier has been assigned to this confirmation method: urn:oasis:names:tc:saml:1.0:cm:artifact-01 Description: Given below. Updates: None. cs-sstc-bindings May 2002

14 Preliminaries The browser/artifact profile of SAML relies on a reference to the needed assertion traveling in a SAML artifact, which the destination site must dereference from the source site in order to determine whether the user is authenticated. Note: The need for a small SAML artifact is motivated by restrictions on URL size imposed by commercial web browsers. While RFC 2616 [RFC2616] does not specify any restrictions on URL length, in practice commercial web browsers and application servers impose size constraints on URLs, for a maximum size of approximately 2000 characters (see Section 8). Further, as developers will need to estimate and set aside URL real estate for the artifact, it is important that the artifact have a bounded size, that is, with predefined maximum size. These measures ensure that the artifact can be reliably carried as part of the URL query string and thereby transferred successfully from source to destination site. The browser/artifact profile consists of a single interaction among three parties (a user equipped with a browser, a source site, and a destination site), with a nested sub-interaction between two parties (the source site and the destination site). The interaction sequence is shown in the following figure, with the following sections elucidating each step. Browser Source Site Destination Site Step 1 Step 2 Step 3 Step 4 Step Step 6 Terminology from RFC 1738 [RFC1738] is used to describe components of a URL. An HTTP URL has the following form: The following sections specify certain portions of the <searchpart> component of the URL. Ellipses will be used to indicate additional but unspecified portions of the <searchpart> component. HTTP requests and responses MUST be drawn from either HTTP 1.1 [RFC2616] or HTTP 1.0 [RFC1945]. Distinctions between the two are drawn only when necessary Step 1: Accessing the Inter-Site Transfer Service In step 1, the user s browser accesses the inter-site transfer service, with information about the desired target at the destination site attached to the URL. cs-sstc-bindings May 2002

15 No normative form is given for step 1. It is RECOMMENDED that the HTTP request take the following form: GET transfer host name and path>?target=<target> <HTTP- Version> <other HTTP 1.0 or 1.1 components> Where: <inter-site transfer host name and path> This provides the host name, port number, and path components of an inter-site transfer URL at the source site. Target=<Target> This name-value pair occurs in the <searchpart> and is used to convey information about the desired target resource at the destination site. Confidentiality and message integrity MUST be maintained in step Step 2: Redirecting to the Destination Site In step 2, the source site s inter-site transfer service responds and redirects the user s browser to the assertion consumer service at the destination site. The HTTP response MUST take the following form: <HTTP-Version> 302 <Reason Phrase> <other headers> Location : receiver host name and path>?<saml searchpart> <other HTTP 1.0 or 1.1 components> Where: <artifact receiver host name and path> This provides the host name, port number, and path components of an artifact receiver URL associated with the assertion consumer service at the destination site. <SAML searchpart>= TARGET=<Target> SAMLart=<SAML artifact> A single target description MUST be included in the <SAML searchpart> component. At least one SAML artifact MUST be included in the SAML <SAML searchpart> component; multiple SAML artifacts MAY be included. If more than one artifact is carried within <SAML searchpart>, all the artifacts MUST have the same SourceID. According to HTTP 1.1 [RFC2616] and HTTP 1.0 [RFC1945], the use of status code 302 is recommended to indicate that the requested resource resides temporarily under a different URI. The response may also include additional headers and an optional message body as described in those RFCs. Confidentiality and message integrity MUST be maintained in step 2. It is RECOMMENDED that the intersite transfer URL be protected by SSL 3.0 or TLS 1.0 (see Section 6). Otherwise, the one or more artifacts returned in step 2 will be available in plain text to an attacker who might then be able to impersonate the assertion subject Step 3: Accessing the Artifact Receiver URL In step 3, the user s browser accesses the artifact receiver URL, with a SAML artifact representing the user s authentication information attached to the URL. The HTTP request MUST take the form: GET receiver host name and path>?<saml searchpart> <HTTP- Version> <other HTTP 1.0 or 1.1 request components> cs-sstc-bindings May 2002

16 Where: <artifact receiver host name and path> This provides the host name, port number, and path components of an artifact receiver URL associated with the assertion consumer service at the destination site. <SAML searchpart>= TARGET=<Target> SAMLart=<SAML artifact> A single target description MUST be included in the <SAML searchpart> component. At least one SAML artifact MUST be included in the <SAML searchpart> component; multiple SAML artifacts MAY be included. If more than one artifact is carried within <SAML searchpart>, all the artifacts MUST have the same SourceID. Confidentiality and message integrity MUST be maintained in step 3. It is RECOMMENDED that the artifact receiver URL be protected by SSL 3.0 or TLS 1.0 (see Section 6). Otherwise, the artifacts transmitted in step 3 will be available in plain text to any attacker who might then be able to impersonate the assertion subject Steps 4 and 5: Acquiring the Corresponding Assertions In steps 4 and 5, the destination site, in effect, dereferences the one or more SAML artifacts in its posession in order to acquire the SAML authentication assertion that corresponds to each artifact. These steps MUST utilize a SAML protocol binding for a SAML request-response message exchange between the destination and source sites. The destination site functions as a SAML requester and the source site functions as a SAML responder. The destination site MUST send a <samlp:request> message to the source site, requesting assertions by supplying assertion artifacts in the <samlp:assertionartifact> element. If the source site is able to find or construct the requested assertions, it responds with a <samlp:response> message with the requested assertions. Otherwise, it returns an appropriate error code, as defined within the selected SAML binding. In the case where the source site returns assertions within <samlp:response>, it MUST return exactly one assertion for each SAML artifact found in the corresponding <samlp:request> element. The case where fewer or greater number of assertions is returned within the <samlp:response> element MUST be treated as an error state by the destination site. The source site MUST implement a one-time request property for each SAML artifact. Many simple implementations meet this constraint by an action such as deleting the relevant assertion from persistent storage at the source site after one lookup. If a SAML artifact is presented to the source site again, the source site MUST return the same message as it would if it were queried with an unknown artifact. The selected SAML protocol binding MUST provide confidentiality, message integrity and bilateral authentication. The source site MUST implement the SAML SOAP binding with support for confidentiality, message integrity, and bilateral authentication. The source site MUST return a response with no assertions if it receives a <samlp:request> message from an authenticated destination site X containing an artifact issued by the source site to some other destination site Y, where X <>Y. One way to implement this feature is to have source sites maintain a list of artifact and destination site pairs. At least one of the SAML assertions returned to the destination site MUST be an SSO assertion. Authentication statements MAY be distributed across more than one returned assertion. The <saml:confirmationmethod> element of each assertion MUST be set to urn:oasis:names:tc:saml:1.0:cm:artifact-01. Based on the information obtained in the assertions retrieved by the destination site, the destination site MAY engage in additional SAML message exchanges with the source site. cs-sstc-bindings May 2002

17 Step 6: Responding to the User s Request for a Resource In step 6, the user s browser is sent an HTTP response that either allows or denies access to the desired resource. No normative form is mandated for the HTTP response. The destination site SHOULD provide some form of helpful error message in the case where access to resources at that site is disallowed Artifact Format The artifact format includes a mandatory two-byte artifact type code, as follows: SAML_artifact := B64(TypeCode RemainingArtifact) TypeCode := Byte1Byte2 Note: Depending on the level of security desired and associated profile protocol steps, many viable architectures could be developed for the SAML artifact [CoreAssnEx] [ShibMarlena]. The type code structure accommodates variability in the architecture. The notation B64(TypeCode RemainingArtifact) stands for the application of the base64 [RFC2045] transformation to the catenation of the TypeCode and RemainingArtifact. This profile defines an artifact type of type code 0x0001, which is REQUIRED (mandatory to implement) for any implementation of the browser/artifact profile. This artifact type is defined as follows: TypeCode := 0x0001 RemainingArtifact := SourceID AssertionHandle SourceID := 20-byte_sequence AssertionHandle := 20-byte_sequence SourceID is a 20-byte sequence used by the destination site to determine source site identity and location. It is assumed that the destination site will maintain a table of SourceID values as well as the URL (or address) for the corresponding SAML responder. This information is communicated between the source and destination sites out-of-band. On receiving the SAML artifact, the destination site determines if the SourceID belongs to a known source site and obtains the site location before sending a SAML request (as described in Section ). Any two source sites with a common destination site MUST use distinct SourceID values. Construction of AssertionHandle values is governed by the principle that they SHOULD have no predictable relationship to the contents of the referenced assertion at the source site and it MUST be infeasible to construct or guess the value of a valid, outstanding assertion handle. The following practices are RECOMMENDED for the creation of SAML artifacts at source sites: Each source site selects a single identification URL. The domain name used within this URL is registered with an appropriate authority and administered by the source site. The source site constructs the SourceID component of the artifact by taking the SHA-1 hash of the identification URL. The AssertionHandle value is constructed from a cryptographically strong random or pseudorandom number sequence [RFC1750] generated by the source site. The sequence consists of values of at least eight bytes in size. These values should be padded to a total length of 20 bytes Threat Model and Countermeasures This section utilizes materials from [ShibMarlena] and [Rescorla-Sec] Stolen Artifact Threat: If an eavesdropper can copy the real user s SAML artifact, then the eavesdropper could construct a URL with the real user s SAML artifact and be able to impersonate the user at the destination site. cs-sstc-bindings May 2002

18 Countermeasure: As indicated in steps 2, 3, 4, and 5, confidentiality MUST be provided whenever an artifact is communicated between a site and the user s browser. This provides protection against an eavesdropper gaining access to a real user s SAML artifact. If an eavesdropper defeats the measures used to ensure confidentiality, additional countermeasures are available: The source and destination sites SHOULD make some reasonable effort to ensure that clock settings at both sites differ by at most a few minutes. Many forms of time synchronization service are available, both over the Internet and from proprietary sources. SAML assertions communicated in step 5 MUST include an SSO assertion. The source site SHOULD track the time difference between when a SAML artifact is generated and placed on a URL line and when a <samlp:request> message carrying the artifact is received from the destination. A maximum time limit of a few minutes is recommended. Should an assertion be requested by a destination site query beyond this time limit, a SAML error SHOULD be returned by the source site. It is possible for the source site to create SSO assertions either when the corresponding SAML artifact is created or when a <samlp:request> message carrying the artifact is received from the destination. The validity period of the assertion SHOULD be set appropriately in each case: longer for the former, shorter for the latter. Values for NotBefore and NotOnOrAfter attributes of SSO assertions SHOULD have the shortest possible validity period consistent with successful communication of the assertion from source to destination site. This is typically on the order of a few minutes. This ensures that a stolen artifact can only be used successfully within a small time window. The destination site MUST check the validity period of all assertions obtained from the source site and reject expired assertions. A destination site MAY choose to implement a stricter test of validity for SSO assertions, such as requiring the assertion s IssueInstant or AuthenticationInstant attribute value to be within a few minutes of the time at which the assertion is received at the destination site. If a received authentication statement includes a <saml:subjectlocality> element with the IP address of the user, the destination site MAY check the browser IP address against the IP address contained in the authentication statement Attacks on the SAML Protocol Message Exchange Threat: The message exchange in steps 4 and 5 could be attacked in a variety of ways, including artifact or assertion theft, replay, message insertion or modification, and MITM (man-in-the-middle attack). Countermeasure: The requirement for the use of a SAML protocol binding with the properties of bilateral authentication, message integrity, and confidentiality defends against these attacks Malicious Destination Site Threat: Since the destination site obtains artifacts from the user, a malicious site could impersonate the user at some new destination site. The new destination site would obtain assertions from the source site and believe the malicious site to be the user. Countermeasure: The new destination site will need to authenticate itself to the source site so as to obtain the SAML assertions corresponding to the SAML artifacts. There are two cases to consider: 1. If the new destination site has no relationship with the source site, it will be unable to authenticate and this step will fail. 2. If the new destination site has an existing relationship with the source site, the source site will determine that assertions are being requested by a site other than that to which the artifacts were originally sent. In such a case, the source site MUST not provide the assertions to the new destination site. cs-sstc-bindings May 2002

19 Forged SAML Artifact Threat: A malicious user could forge a SAML artifact. Countermeasure: Section provides specific recommendations regarding the construction of a SAML artifact such that it is infeasible to guess or construct the value of a current, valid, and outstanding assertion handle. A malicious user could attempt to repeatedly guess a valid SAML artifact value (one that corresponds to an existing assertion at a source site), but given the size of the value space, this action would likely require a very large number of failed attempts. A source site SHOULD implement measures to ensure that repeated attempts at querying against non-existent artifacts result in an alarm Browser State Exposure Threat: The SAML artifact profile involves downloading of SAML artifacts to the web browser from a source site. This information is available as part of the web browser state and is usually stored in persistent storage on the user system in a completely unsecured fashion. The threat here is that the artifact may be reused at some later point in time. Countermeasure: The one-use property of SAML artifacts ensures that they cannot be reused from a browser. Due to the recommended short lifetimes of artifacts and mandatory SSO assertions, it is difficult to steal an artifact and reuse it from some other browser at a later time Browser/POST Profile of SAML Required Information Identification: urn:oasis:names:tc:saml:1.0:profiles:browser-post Contact information: [email protected] SAML Confirmation Method Identifiers: The "Bearer" confirmation method identifier is used by this profile. The following identifier has been assigned to this confirmation method: urn:oasis:names:tc:saml:1.0:cm:bearer Description: Given below. Updates: None Preliminaries The browser/post profile of SAML allows authentication information to be supplied to a destination site without the use of an artifact. The following figure diagrams the interactions between parties in the browser/post profile. The browser/post profile consists of a series of two interactions, the first between a user equipped with a browser and a source site, and the second directly between the user and the destination site. The interaction sequence is shown in the following figure, with the following sections elucidating each step. cs-sstc-bindings May 2002

20 Browser Source Site Destination Site Step 1 Step 2 Step Step Step 1: Accessing the Inter-Site Transfer Service In step 1, the user s browser accesses the inter-site transfer service, with information about the desired target at the destination site attached to the URL. No normative form is given for step 1. It is RECOMMENDED that the HTTP request take the following form: GET transfer host name and path>?target=<target> <HTTP- Version> <other HTTP 1.0 or 1.1 components> Where: <inter-site transfer host name and path> This provides the host name, port number, and path components of an inter-site transfer URL at the source site. Target=<Target> This name-value pair occurs in the <searchpart> and is used to convey information about the desired target resource at the destination site Step 2: Generating and Supplying the Response In step 2, the source site generates HTML form data containing a SAML Response which contains an SSO assertion. The HTTP response MUST take the form: <HTTP-Version 200 <Reason Phrase> <other HTTP 1.0 or 1.1 components> Where: <other HTTP 1.0 or 1.1 components> This MUST include an HTML FORM [Chapter 17, [HTML401]] with the following FORM body: <Body> <FORM Method= Post Action= <assertion consumer host name and path> > <INPUT TYPE= hidden NAME= SAMLResponse Value= B64(<response>) > <INPUT TYPE= hidden NAME= TARGET Value= <Target> > </Body> cs-sstc-bindings May 2002

21 <assertion consumer host name and path> This provides the host name, port number, and path components of an assertion consumer URL at the destination site. Exactly one SAML response MUST be included within the FORM body with the control name SAMLResponse; multiple SAML assertions MAY be included in the Response. At least one of the assertions MUST be an SSO assertion. A single target description MUST be included with the control name TARGET. The notation B64(<response>) stands for the result of applying the base64 transformation to the response. The SAML response MUST be digitally signed following the guidelines given in [SAMLCore]. Included assertions MAY be digitally signed. Confidentiality and message integrity MUST be maintained for step 2. It is RECOMMENDED that the inter-site transfer URL be protected by SSL 3.0 or TLS 1.0 (see Section 6). Otherwise, the assertions returned will be available in plain text to any attacker who might then be able to impersonate the assertion subject Step 3: Posting the Form Containing the Response In step 3, the browser submits the form containing the SAML response using the following HTTP request. Note: Posting the form can be triggered by various means. For example, a submit button could be included in Step 2 by including the following line: <INPUT TYPE= Submit NAME= button Value= Submit > This requires the user to explicitly submit the form for the POST request to be sent. Alternatively, JavaScript can be used to avoid an additional submit step from the user as follows [Anders]: <HTML> <BODY Onload= document.forms[0].submit() > <FORM METHOD= POST ACTION= <assertion consumer host name and path> > <INPUT TYPE= HIDDEN NAME= SAMLResponse VALUE= response in base64 coding > <INPUT TYPE= hidden NAME= TARGET Value= <Target> > </FORM> </BODY> </HTML> The HTTP request MUST include the following components: POST consumer host name and path> <other HTTP 1.0 or 1.1 request components> Where: <other HTTP 1.0 or 1.1 request components> This consists of the form data set derived by the browser processing of the form data received in step 2 according to of [HTML4.01]. Exactly one SAML Response MUST be included within the form data set with control name SAMLResponse; multiple SAML assertions MAY be included in the Response. A single target description MUST be included with the control name set to TARGET. The SAML response MUST include the Recipient attribute [SAMLCore] with its value set to <assertion consumer host name and path>. At least one of the SAML assertions included within the response MUST be an SSO assertion. cs-sstc-bindings May 2002

22 The destination site MUST ensure a single use policy for SSO assertions communicated by means of this profile. Note: The implication here is that the destination site will need to save state. A simple implementation might maintain a table of pairs, where each pair consists of the assertion ID and the time at which the entry is to be deleted (where this time is based on the SSO assertion lifetime.). The destination site needs to ensure that there are no duplicate entries. Since SSO assertions containing authentication statements are recommended to have short lifetimes in the web browser context, such a table would be of bounded size. Confidentiality and message integrity MUST be maintained for the HTTP request in step 3. It is RECOMMENDED that the assertion consumer URL be protected by SSL 3.0 or TLS 1.0 (see Section 6). Otherwise, the assertions transmitted in step 3 will be available in plain text to any attacker who might then impersonate the assertion subject. The <saml:confirmationmethod> element of each assertion MUST be set to urn:oasis:names:tc:saml:1.0:cm:bearer Step 4: Responding to the User s Request for a Resource In step 4, the user s browser is sent an HTTP response that either allows or denies access to the desired resource. No normative form is mandated for the HTTP response. The destination site SHOULD provide some form of helpful error message in the case where access to resources at that site is disallowed Threat Model and Countermeasures This section utilizes materials from [ShibMarlena] and [Rescorla-Sec] Stolen Assertion Threat: If an eavesdropper can copy the real user s SAML response and included assertions, then the eavesdropper could construct an appropriate POST body and be able to impersonate the user at the destination site. Countermeasure: As indicated in steps 2 and 3, confidentiality MUST be provided whenever a response is communicated between a site and the user s browser. This provides protection against an eavesdropper obtaining a real user s SAML response and assertions. If an eavesdropper defeats the measures used to ensure confidentiality, additional countermeasures are available: The source and destination sites SHOULD make some reasonable effort to ensure that clock settings at both sites differ by at most a few minutes. Many forms of time synchronization service are available, both over the Internet and from proprietary sources. SAML assertions communicated in step 3 MUST include an SSO assertion. Values for NotBefore and NotOnOrAfter attributes of SSO assertions SHOULD have the shortest possible validity period consistent with successful communication of the assertion from source to destination site. This is typically on the order of a few minutes. This ensures that a stolen assertion can only be used successfully within a small time window. The destination site MUST check the validity period of all assertions obtained from the source site and reject expired assertions. A destination site MAY choose to implement a stricter test of validity for SSO assertions, such as requiring the assertion s IssueInstant or AuthenticationInstant attribute value to be within a few minutes of the time at which the assertion is received at the destination site. If a received authentication statement includes a <saml:subjectlocality> element with the IP address of the user, the destination site MAY check the browser IP address against the IP address contained in the authentication statement. cs-sstc-bindings May 2002

23 MITM Attack Threat: Since the destination site obtains bearer SAML assertions from the user by means of an HTML form, a malicious site could impersonate the user at some new destination site. The new destination site would believe the malicious site to be the subject of the assertion. Countermeasure: The destination site MUST check the Recipient attribute of the SAML Response to ensure that its value matches the <assertion consumer host name and path>. As the response is digitally signed, the Recipient value cannot be altered by the malicious site Forged Assertion Threat: A malicious user, or the browser user, could forge or alter a SAML assertion. Countermeasure: The browser/post profile requires the SAML Response carrying SAML assertions to be signed, thus providing both message integrity and authentication. The destination site MUST verify the signature and authenticate the issuer Browser State Exposure Threat: The browser/post profile involves uploading of assertions from the web browser to a source site. This information is available as part of the web browser state and is usually stored in persistent storage on the user system in a completely unsecured fashion. The threat here is that the assertion may be reused at some later point in time. Countermeasure: Assertions communicated using this profile must always include an SSO assertion. SSO assertions are expected to have short lifetimes and destination sites are expected to ensure that SSO assertions are not re-submitted. cs-sstc-bindings May 2002

24 Confirmation Method Identifiers The SAML assertion and protocol specification [SAMLCore] defines <ConfirmationMethod> as part of the <SubjectConfirmation> element. The <SubjectConfirmation> element SHOULD be used by the Relying Party to confirm that the request or message came from the System Entity that corresponds to the Subject in the statement. The <ConfirmationMethod> indicates the specific method which the Relying Party should use to make this judgment. This may or may not have any relationship to an authentication that was performed previously. Unlike AuthenticationMethod, <ConfirmationMethod> will often be accompanied with some piece of information, such as a certificate or key, in the <SubjectConfirmationData> and/or <ds:keyinfo> elements, which will allow the relying party to perform the necessary check. It is anticipated that profiles and bindings will define and use several different values for <ConfirmationMethod>, each corresponding to a different SAML usage scenario. Some examples are as follows: A website employs the browser/artifact profile of SAML to sign in a user. The <ConfirmationMethod> in the resulting assertion is set to urn:oasis:names:tc:saml:1.0:cm:artifact-01. There is no login, but an application request sent to a relying party includes SAML assertions and is digitally signed. The associated public key from the <ds:keyinfo> element is used for confirmation. 5.1 Holder of Key URI: urn:oasis:names:tc:saml:1.0:cm:holder-of-key A <ds:keyinfo> element MUST be present within the <SubjectConfirmation> element. As described in [XMLSig], the <ds:keyinfo> element holds a key or information that enables an application to obtain a key. The subject of the assertion is the party that can demonstrate that it is the holder of the key. 5.2 Sender Vouches URI: urn:oasis:names:tc:saml:1.0:cm:sender-vouches Indicates that no other information is available about the context of use of the assertion. The relying party SHOULD utilize other means to determine if it should process the assertion further. 5.3 SAML Artifact URI: urn:oasis:names:tc:saml:1.0:cm:artifact-01 The subject of the assertion is the party that presented a SAML artifact, which the relying party used to obtain the assertion from the party that created the artifact. See also Section Bearer URI: urn:oasis:names:tc:saml:1.0:cm:bearer\ The subject of the assertion is the bearer of the assertion. See also Section cs-sstc-bindings May 2002

25 Use of SSL 3.0 or TLS 1.0 In any SAML use of SSL 3.0 or TLS 1.0 [RFC2246], servers MUST authenticate to clients using a X.509.v3 certificate. The client MUST establish server identity based on contents of the certificate (typically through examination of the certificate subject DN field). 6.1 SAML SOAP Binding TLS-capable implementations MUST implement the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite and MAY implement the TLS_RSA_AES_128_CBC_SHA cipher suite [AES]. 6.2 Web Browser Profiles of SAML SSL-capable implementations of the browser/artifact profile or browser/post profile of SAML MUST implement the SSL_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. TLS-capable implementations MUST implement the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. cs-sstc-bindings May 2002

26 References [AES] FIPS-197, Advanced Encryption Standard (AES), available from [Anders] A suggestion on how to implement SAML browser bindings without using Artifacts, [AuthXML] AuthXML: A Specification for Authentication Information in XML, [HTML401] HTML 4.01 Specification, W3C Recommendation 24 December 1999, [MSURL] Microsoft technical support article, [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March [RFC2617] HTTP Authentication: Basic and Digest Access Authentication, IETF RFC [S2ML] S2ML: Security Services Markup Language, Version 0.8a, January 8, [SAMLCore] Phillip Hallam-Baker et al., Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML), OASIS, May [SAMLGloss] Jeff Hodges et al., Glossary for the OASIS Security Assertion Markup Language (SAML), OASIS, May [SAMLSec] Chris McLaren et al., Security Considerations for the OASIS Security Assertion Markup Language (SAML), OASIS, May [SAMLReqs] Darren Platt et al., SAML Requirements and Use Cases, OASIS, December [Shib] Shiboleth Overview and Requirements [ShibMarlena] Marlena Erdos, Shibboleth Architecture DRAFT v1.1, [RFC2045] Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [RFC2616] Hypertext Transfer Protocol -- HTTP/1.1, [RFC1738] Uniform Resource Locators (URL), [RFC1750] Randomness Recommendations for Security. [RFC1945] Hypertext Transfer Protocol -- HTTP/1.0, [RFC2246] The TLS Protocol Version 1.0, [RFC2774] An HTTP Extension Framework, [SOAP1.1] D. Box et al., Simple Object Access Protocol (SOAP) 1.1, World Wide Web Consortium Note, May [CoreAssnEx] Core Assertions Architecture, Examples and Explanations, [XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, World Wide Web Consortium. cs-sstc-bindings May 2002

27 [WEBSSO] RL Bob Morgan, Interactions between Shibboleth and local-site web sign-on services, [SESSION] RL Bob Morgan, Support of target web server sessions in Shibboleth, 00.txt [SSLv3] The SSL Protocol Version 3.0, [Rescorla-Sec] E. Rescorla et al., Guidelines for Writing RFC Text on Security Considerations, cs-sstc-bindings May 2002

28 URL Size Restriction (Non-Normative) This section describes the URL size restrictions that have been documented for widely used commercial products. A Microsoft technical support article [MSURL] provides the following information: The information in this article applies to: Microsoft Internet Explorer (Programming) versions 4.0, 4.01, 4.01 SP1, 4.01 SP2, 5, 5.01, 5.5 SUMMARY Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters, with a maximum path length of 2,048 characters. This limit applies to both POST and GET request URLs. If you are using the GET method, you are limited to a maximum of 2,048 characters (minus the number of characters in the actual path, of course). POST, however, is not limited by the size of the URL for submitting name/value pairs, because they are transferred in the header and not the URL. RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, does not specify any requirement for URL length. REFERENCES Further breakdown of the components can be found in the Wininet header file. Hypertext Transfer Protocol -- HTTP/1.1 General Syntax, section Additional query words: POST GET URL length Keywords : kbie kbie400 kbie401 kbgrpdsinet kbie500 kbdsupport kbie501 kbie550 kbiefaq Issue type : kbinfo Technology : An article about Netscape Enterprise Server provides the following information: Issue: Product: Enterprise Server Created: 11/10/1997 Version: 2.01 Last Updated: 08/10/1998 OS: AIX, Irix, Solaris Does this article answer your question? Please let us know! Question: How can I determine the maximum URL length that the Enterprise server will accept? Is this configurable and, if so, how? Answer: Any single line in the headers has a limit of 4096 chars; it is not configurable. cs-sstc-bindings May 2002

29 Alternative SAML Artifact Format 9.1 Required Information Identification: urn:oasis:names:tc:saml:1.0:draft-sstc-bindings-model-13:profiles:artifact-02 Contact information: [email protected] Description: Given below. Updates: None. 9.2 Format Details An alternative artifact format is described here: TypeCode := 0x0002 RemainingArtifact := AssertionHandle SourceLocation AssertionHandle := 20-byte_sequence SourceLocation := URI The SourceLocation URI is the address of the SAML responder associated with the source site. The assertionhandle is as described in Section 0, and governed by the same requirements. The destination site MUST process the artifact in a manner identical to that described in Section 4.1.1, with the exception that the location of the SAML responder at the source site MAY be obtained directly from the artifact, rather than by look-up, based on sourceid. Note: the destination site MUST confirm that assertions were issued by an acceptable issuer, not relying merely on the fact that they were returned in response to a samlp:request. cs-sstc-bindings May 2002

30 Appendix A. Acknowledgments The editors would like to acknowledge the contributions of the OASIS SAML Technical Committee, whose voting members at the time of publication were: Allen Rogers, Authentica Irving Reid, Baltimore Technologies Krishna Sankar, Cisco Systems Ronald Jacobson, Computer Associates Hal Lockhart, Entegrity Carlisle Adams, Entrust Inc. Robert Griffin, Entrust Inc. Robert Zuccherato, Entrust Inc. Don Flinn, Hitachi Joe Pato, Hewlett-Packard (co-chair) Jason Rouault, Hewlett-Packard Marc Chanliau, Netegrity Chris McLaren, Netegrity Prateek Mishra, Netegrity Charles Knouse, Oblix Steve Anderson, OpenNetwork Rob Philpott, RSA Security Jahan Moreh, Sigaba Bhavna Bhatnagar, Sun Microsystems Jeff Hodges, Sun Microsystems (co-chair) Eve Maler, Sun Microsystems (former chair) Aravindan Ranganathan, Sun Microsystems Emily Xu, Sun Microsystems Bob Morgan, University of Washington and Internet2 Phillip Hallam-Baker, VeriSign cs-sstc-bindings May 2002

31 Appendix B. Notices OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director. OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director. Copyright The Organization for the Advancement of Structured Information Standards [OASIS] 2001, All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. JavaScript is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. cs-sstc-bindings May 2002