Enhanced Client Profile (PAOS-LECP) Solution Proposal for SAML 2.0

Transcription

1 Enhanced Client Profile (PAOS-LECP) Solution Proposal for SAML 2.0 Working Draft 01, 8 January 2004 Document identifier: hirsch-paos-lecp-draft-01 Location: Editor: Frederick Hirsch, Nokia Mobile Phones Contributors: Robert Aarts, Nokia Frederick Hirsch, Nokia John Kemp, Nokia Liberty Alliance ID-FF and ID-WSF Specification Contributors Abstract: This document specifies provides an additional solution proposal for SAML 2.0 Work Item W-5a, Enhanced Client Profiles. This is a LECP that uses SOAP to communicate with a SP, using a reverse HTTP binding. This is identified as PAOS-LECP. Thus one Enhanced Client Profile uses a client that knows how to find its IDP, but does not use SOAP to communicate with the SP. This has been submitted as the LECP solution proposal. This solution proposal is similar, but specifies a client that knows how to find its IDP but uses SOAP to communicate with the SP. Since a reverse HTTP binding is used, the client does not need to be addressable. A third possibility is a client that knows how to find its IDP and uses SOAP for requests to the SP. This solution may also use portions of this solution proposal as noted within. Status: Working draft. Send comments to the mailing list. Committee members should send comments on this specification to the securityservices@lists.oasis-open.org list. Others should subscribe to and send comments to the security-services-comment@lists.oasis-open.org list. To subscribe, send an message to security-services-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message. 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 OASIS Open All Rights Reserved. Page 1 of 18

2 Table of Contents 1 Introduction Processing Model Overview Detailed Processing Model and Formats HTTP Service Request: LEC > SP Authentication Request SOAP Message: SP > LEC > IDP PAOS Request Header Block: SP>LEC LECP Request Header Block : SP > LEC SP > LEC Request Example LEC > IDP Request Example Authentication Response SOAP Message: IDP>LEC>SP LECP Response Header Block : IDP > LEC IDP > LEC Response Example PAOS Response Header Block : LEC > SP LEC > SP Response Example HTTP service response: SP>LEC Summary Security Considerations References XML Schema...15 Copyright OASIS Open All Rights Reserved. Page 2 of 18

3 1 Introduction A Liberty Enabled Client or Proxy (LECP) is one that either knows which Identity Provider (IDP) a principal wants to use with a given Service Provider (SP) or knows how to find out. This allows a Service Provider to make an authentication request to such a client without the need to know or discover the appropriate identity provider. The Liberty Federation Framework Bindings and Profiles Specification [ LIBFFBind ] defines a LECP profile that enables a service provider to convey an authentication request in an HTTP response to a Liberty Enabled Client(LEC) 1. The profile also defines how a LEC may return an authentication response in a subsequent HTTP request and how the LEC may communicate with an IDP to obtain the authentication assertion. The LECP Solution Proposal submitted to the SSTC describes this solution in detail, including updated XML schema definitions for the AuthnRequest and AuthnResponse XML elements, extending the definitions of SAML 1.0. The LECP proposal also defines XML Envelopes to convey an authentication request from the SP to the LEC and a response from the LEC to the SP. This envelope includes additional information needed by the LEC, such as the URL to subsequently respond to with a later HTTP request. (This is a solicit-response message exchange paradigm [ WSDL1_1 ].) A response envelope is defined for an IDP to return an authentication assertion to a LEC, since the IDP may also wish to convey additional information to the LEC with this assertion. Communication between the SP and LEC does not use SOAP in the LECP profile, while SOAP is used between the LEC and the IDP. The benefit of LECP is that it enables service providers that are not web-services aware or SOAP capable to make authentication requests and participate in simplified sign-on deployments. This solution proposal defines an additional enhanced client profile that eliminates the use of the custom XML envelopes by using SOAP between the LEC and the SP, while retaining the solicit response message exchange pattern associated with the reverse HTTP binding, and still defining a LEC as a client that knows which identity provider to use for a specific SP. As a result, this profile obtains the extensibility benefits of a standard SOAP envelope, including potential use of SOAP message security as well as other SOAP header extensions. The LEC is a specialized SOAP intermediary, in that it is still special since it knows how to find the appropriate IDP. Unlike generic SOAP nodes, the LEC in this profile is not necessarily directly addressable. This is possible since the reverse HTTP binding causes the authentication request to be conveyed in an HTTP response. This reverse-http binding is not defined in this document, but leverages a generic specification known as PAOS. The PAOS specification defines how to use a reverse HTTP SOAP binding to convey SOAP requests in HTTP responses and return SOAP responses in subsequent HTTP requests, enabling clients that cannot be directly addressed as SOAP endpoints to use SOAP to convey authentication requests and responses [ PAOS ]. This document profiles the use of PAOS for LECP authentication functionality specifying an additional LECP SOAP header and SOAP processing rules. This document describes PAOS for convenience but the PAOS specification is definitive in the case of conflict. It is anticipated that both this profile and the LECP solution proposal already submitted will be useful and necessary for different deployments. A third possibility, not directly addressed in this solution proposal, is for a LEC SOAP client to make a SOAP request to a SP and for the SP to return a request for authentication in the SOAP response. This forward SOAP HTTP binding will not require PAOS, but will still require a LEC indication in the initial SOAP request and a LEC header to convey additional information in the SOAP response requesting authentication. For this reason, portions of this solution proposal should be applicable to this case as well, and are noted where appropriate. The relevant Liberty Federation Framework 1.2 specifications for LECP have already been submitted to the SAML technical committee [ SSTC-Liberty1.2 ]. The Liberty PAOS specification is a publicly accessible draft. Familiarity with these specifications is assumed in this proposal. This solution proposal is intended to be used with either SOAP 1.1 or SOAP The remainder of this document refers to Liberty Enabled Clients (LECs), but this should be understood to also include Liberty Enabled Proxies. Copyright OASIS Open All Rights Reserved. Page 3 of 18

4 2 Processing Model Overview The high level LECP processing model consists of the following steps: 1. The LEC requests a resource or action from a SP using an HTTP request. 2. The SP sends an authentication request in the HTTP response. 3. The LEC determines the appropriate IDP to use for authentication of the principal for the specific SP. (If the LEC incorporates the IDP functionality then steps 4 & 5 are not required.) 4. The LEC sends an authentication request to the IDP and obtains an authentication response from it. 5. The LEC returns the authentication assertion to the SP in a new HTTP request. 6. The SP conveys the response for the original service request in the HTTP response. This is depicted in the following figure from the Liberty 1.2 Federation Framework profile document (figure 5 in that document). The faint steps (#2, 8, 9 are not performed in the LECP profile): Client Service Provider Identity Provider 1. HTTP Request: Liberty-Enabled Header OK <AuthnRequestEnvelope>, Liberty-Enabled Header 2. Obtain IDP 4. SOAP POST: <AuthnRequest>, Liberty-Enabled Header() OK, <AuthnResponseEnvelope>, Liberty-Enabled Header() 7. POST, SP assertionconsumerurl: LRES=< AuthnResponse>; Liberty- Enabled Header 8 SOAP POST: <samlp:request>() OK SOAP:<samlp:Response>() 10 Process Assertion 11. HTTP Response; Liberty-Enabled Header Figure 1: LECP Flows This solution proposal recasts LECP functionality as a SOAP profile, treating the Liberty Enabled Client as Copyright OASIS Open All Rights Reserved. Page 4 of 18

5 a SOAP intermediary between a service provider and an identity provider. This LEC intermediary knows which IDP is appropriate for a given principal and service provider and routes the SOAP request appropriately to the correct ultimate SOAP receiver (IDP). Benefits of using a SOAP based approach in conjunction with LECP include simplicity and consistent use of a generic PAOS mechanism. This allows the benefits of SOAP-based processing, enabling additional SOAP-based services to be incrementally added using SOAP header blocks (e.g. SOAP Message Security). PAOS defines a SOAP header block that is targeted for use between a non-addressable SOAP service (or intermediary) and a SOAP client. This profile defines an additional LECP SOAP header that is conveyed between SP and the LEC and also between the IDP and the LEC. Use of these headers signal the use of this profile since the mustunderstand attribute is specified as true for each. At a high level this profile outlines the following messages as part of an authentication message flow: 1. HTTP service request from LEC to SP, with indications of PAOS and LEC capability 2. Authentication request SOAP message from SP to LEC to IDP 3. Authentication response SOAP message from IDP to LEC to SP 4. HTTP service response from SP to LEC The processing flow as outlined in this profile may be summarized as follows: Client Service Provider Identity Provider 1. HTTP GET, PAOS Accept, Paos header with authentication service support indicated OK HTTP Response, PAOS content type, SOAP message; Paos, LECP Request SOAP headers, AuthnRequest SOAP body 3. HTTP POST, SOAP Request with AuthnRequest body OK, SOAP Response with LECP SOAP header and AuthnResponse body 5. HTTP POST, PAOS content type, SOAP Response with PAOS SOAP header and AuthnResponse body OK HTTP Response, with Content Type and content for original request Figure 2: PAOS-LECP Flows Copyright OASIS Open All Rights Reserved. Page 5 of 18

6 3 Detailed Processing Model and Formats 3.1 HTTP Service Request: LEC > SP The HTTP request from the LEC to the SP is an HTTP GET request with additional HTTP headers indicating the ability to adhere to the profile specified in this document. Specifically, the HTTP request meets the requirements outlined in the PAOS specification and this document as follows: 1. The HTTP Accept Header field SHOULD indicate ability to accept application/vnd.paos+xml 2. The HTTP PAOS Header field SHOULD be present and specify the PAOS version with urn:liberty:paos: at a minimum. 3. The authentication service must be specified in the HTTP PAOS Header field as a service value, with the value urn: liberty:idp:authentication. This value should correspond to the service attribute in the PAOS Request SOAP header block. To give an example, a user-agent may request a page from the SP as follows: GET /index HTTP/1.1 Host: horoscope.example.com Accept: text/html; application/vnd.paos+xml PAOS: ver= urn:liberty:paos: ; urn:liberty:idp:authentication Note: The Liberty ID-FF 1.2 LECP profile uses a similar mechanism, but advertises a LECP capability in the HTTP request by including a Liberty-Enabled HTTP header with a version value. Note: Figure 3: HTTP request with PAOS Accept and PAOS headers When using a SOAP request in a forward SOAP HTTP binding the client will need to indicate LECP capability. This may be done using a LEC Request header block instead of a HTTP header. 3.2 Authentication Request SOAP Message: SP > LEC > IDP When the SP requires authentication before providing a service it may respond to the service request with an authentication request in the HTTP response. This authentication request will be carried in a SOAP request envelope that is sent from the SP to the IDP with the LEC as a SOAP intermediary. In this case the LEC will determine which IDP is appropriate and route the SOAP request to the appropriate intermediary. The SOAP message will include the SAML 2.0 AuthnRequest authentication request in the SOAP body, targeted at the SOAP ultimate receiver, in this case the IDP. Note: The AuthnRequest ProtocolProfile element needs to reference this profile. The SOAP message will contain two SOAP header blocks, both targeted at next, the LEC. These are: 1. PAOS Request header block 2. LEC Request header block The PAOS Request header block is used to manage the SOAP message exchange pattern, for example including the URL that the LEC should use to send the SOAP response. This is necessary since the LEC will use a new HTTP request to send the response. Copyright OASIS Open All Rights Reserved. Page 6 of 18

7 The LEC Request header block defines information related to the authentication request that the LEC may need to process the request, such as a list of IDPs accepted for authentication by the SP, whether the LEC should involve the principal and a SP name that may be displayed to the principal. The LEC MUST remove both the PAOS and LEC header blocks before passing the SOAP request on to the IDP. Use of this profile must be indicated to the IDP by the LEC through the use of HTTP headers as with the service request noted in the previous section. Other SOAP headers may be used as appropriate, such as a SOAP Message Security header block to allow encryption of the authentication request. Note that the AuthnRequest element may be itself signed PAOS Request Header Block: SP>LEC The PAOS header block signals the use of PAOS processing and includes the following attributes: Attribute Meaning Usage responseconsumerurl service Conveys the LECP AssertionConsumerURL value. This specifies where the LEC is to send the SP response. This indicates that the LECP authentication service is used as outlined in this document. A LECP header is required when this service is specified or a Fault should be generated. The value is defined in this profile as: urn:liberty:idp:authentication Required in the request from SP to LEC. This value is used as the URL to post either a SOAP Fault or the authentication response. Required. [messageid] Allow optional response correlation. This is NOT required when using this profile since this functionality is provided by authentication application layer, via the RequestID attribute in the AuthnRequest and the InResponseTo attribute in the AuthnResponse. mustunderstand A Fault must be returned if the PAOS header block is not understood. actor/role Targeted SOAP node next Required, value 1 The PAOS SOAP request header block has no element content LECP Request Header Block : SP > LEC The SOAP LECP Request header block is used to convey information needed by the LEC to process the authentication request. It is mandatory and its presence signals the use of this profile. It has the following attributes: Attribute mustunderstand 1 actor/role Usage next The element content of the LECP header block conveys information needed by a LEC intermediary to Copyright OASIS Open All Rights Reserved. Page 7 of 18

8 process a SP authentication request and is defined to contain a sequence of the following elements when sent from SP to LEC: Element Use Definition XML Schema ProviderId Required Identification of SP <element ref="lib:providerid /> ProviderName Optional Human readable name of SP <element name="providername" type="string" minoccurs="0"/> IDPList Optional List of IDPs that the SP recognizes and from which the LEC may choose to service the request IsPassive Optional If true then the LEC should not interact with the principal <element ref="lib:idplist" minoccurs="0"/> <element name="ispassive" type="boolean" minoccurs="0"/> Note: This LEC Request SOAP header block may also be used in the SOAP response from an SP to a LEC when requesting authentication and using a forward HTTP binding SP > LEC Request Example The following is an example of the SOAP authentication request from the SP to the LEC (derived from example in section of [ LIBFFProt ]: <?xml version='1.0' encoding='utf-8'?> <soap:envelope xmlns:paos='urn:liberty:paos: ' xmlns:lecp='urn:liberty:lecp: ' xmlns:lib=' xmlns:soap=' <soap:header> <paos:request responseconsumerurl=' messageid='6c3a4f8b9c2d' role='next' mustunderstand='1' service='urn:liberty:idp:authentication'/> <lecp:request mustunderstand='1' role='next'> <ProviderID> <ProviderName>Service Provider X</ProviderName> <IDPList> <IDPEntries> <IDPEntry> <ProviderID> <ProviderName>Identity Provider X</ProviderName> <Loc> </IDPEntry> </IDPEntries> <GetComplete> fe91-441e-afb8-f88748ae3b8b </GetComplete> </IDPList> <IsPassive>0</IsPassive> </lecp:request> </soap:header> <soap:body> <lib:authnrequest>... </lib:authnrequest> </soap:body> </soap:envelope> Figure 4: SP>LEC Authentication Request Example Copyright OASIS Open All Rights Reserved. Page 8 of 18

9 Note: The Liberty ID-FF 1.2 LECP profile conveys this same information using a custom XML AuthnRequestEnvelope. This envelope also carries the AuthnRequest since the SOAP envelope structure was not used in the Liberty ID-FF 1.2 LECP profile for the request from SP to LEC LEC > IDP Request Example As noted above, the PAOS and LECP headers are removed from the SOAP message by the LEC before the authentication request is forwarded to the IDP. An example authentication request from the LEC to the IDP is as follows: <?xml version='1.0' encoding='utf-8'?> <soap:envelope xmlns:soap=' xmlns:lib=' <soap:header>...</soap:header> <soap:body> <lib:authnrequest>... </lib:authnrequest> </soap:body> </soap:envelope> 3.3 Authentication Response SOAP Message: IDP>LEC>SP The IDP may return an authentication response (or fault) when presented with an authentication request. This response is conveyed in a SOAP message with an AuthnResponse in the SOAP body, targeted at the SP as the ultimate SOAP receiver. A SOAP LECP Response header is targeted at the LEC intermediary using next and must be removed by the intermediary. This header is used to convey additional information to the LEC about the authentication response, such as the URL destination that the IDP expects, based on IDP metadata. This allows the LEC to make a security check before returning the authentication response, for example. The LEC MUST remove the SOAP LECResponse header block and MAY add a SOAP PAOSResponse header block before forwarding the SOAP response to the SP. The PAOSResponse SOAP header block in the response is generally used to correlate this response to an earlier request from the SP. In this profile the correlation reftomessageid attribute is not reqiured since the AuthnResponse element InResponseTo attribute may be used for this purpose, but if the PAOSRequest SOAP Header block had a messageid then the PAOSResponse block SHOULD be used LECP Response Header Block : IDP > LEC The LECP response SOAP header block is required to be used on the response from IDP to LEC. The schema definition for this header block includes the mustunderstand, role and assertionconsumerurl attributes and defines no element values: Attribute mustunderstand 1 actor/role Figure 5: LEC>IDP Request Example next Usage Copyright OASIS Open All Rights Reserved. Page 9 of 18

10 assertionconsumerurl This is set by the IDP based on SP metadata obtained and verified by the IDP either out of band or by a metadata lookup mechanism specified in ID-FF. The LEC should confirm that this value corresponds the value the LEC obtained from the responseconsumerurl in the PAOS Request. Since the responseconsumerurl SHOULD be relative and the assertionconsumerurl is a full URL some processing will be required. This mechanism is used for security purposes to confirm the correct response destination. If the values do not match then the LEC MUST generate a SOAP Fault response to the SP and not return the authentication response. The LECP SOAP header has no element content. Note: The Liberty ID-FF 1.2 LECP profile defines an AuthnResponseEnvelope element to convey the authentication response from the IDP to the LEC. This AuthnResponseEnvelope includes the AuthnResponse and AssertionConsumerServiceURL elements. Note that the AuthnResponseEnvelope is carried in the body of a SOAP envelope in the ID-FF 1.2 LECP profile. After removing the LECP Response SOAP header and adding a PAOS Response SOAP header, the LEC does an HTTP POST of the response SOAP message to the SP IDP > LEC Response Example <?xml version='1.0' encoding='utf-8'?> <soap:envelope xmlns:lecp='urn:liberty:lecp: ' xmlns:lib=' xmlns:soap=' <soap:header> <lecp:response mustunderstand='1' role='next' assertionconsumerurl=' ' /> </soap:header> <soap:body> <lib:authnresponse>... </lib:authnresponse> </soap:body> </soap:envelope> Figure 6: IDP > LEC Example PAOS Response Header Block : LEC > SP The PAOS SOAP Response header has the following attributes: Attribute reftomessageid mustunderstand 1 actor/role Usage Allow correlation with the PAOS request. This optional attribute is not required by this profile since the equivalent functionality is provided with the AuthnRequest and AuthnResponse correlation. next The PAOS response SOAP header has no element content. Copyright OASIS Open All Rights Reserved. Page 10 of 18

11 3.3.4 LEC > SP Response Example <?xml version='1.0' encoding='utf-8'?> <soap:envelope xmlns:paos='urn:liberty:paos: ' xmlns:lib=' xmlns:soap=' <soap:header> <paos:response reftomessageid='6c3a4f8b9c2d' role='next' mustunderstand='1'/> </soap:header> <soap:body> <lib:authnresponse>... </lib:authnresponse> </soap:body> </soap:envelope> Figure 7: LEC > SP Response Example 3.4 HTTP service response: SP>LEC Once the SP has received an authentication response in an HTTP request it may respond with the service data in the HTTP response. Copyright OASIS Open All Rights Reserved. Page 11 of 18

12 4 Summary The basic message flow is similar to the ID-FF 1.2 LECP profile, with an authentication request conveyed from a SP to a LEC in response to a service request. This leads to the LEC obtaining an authentication assertion from the appropriate IDP and returning this assertion to the SP in a new HTTP request (a solicit response message exchange pattern). Unlike ID-FF 1.2 LECP, the authentication request from the SP and the authentication response to the SP are conveyed using SOAP, eliminating the need for a custom envelope in this profile. It also allows the benefits of SOAP processing, including SOAP header extensibility and use of SOAP Message Security. This profile defines PAOS and LECP SOAP headers for the request and response and defines processing rules to be used in the profile. It builds on previous PAOS work. The LEC header block may also be used in a scenario using a forward SOAP HTTP binding, since the client will still be a LEC that knows how to contact the appropriate IDP and additional information related to such a LEC will need to be conveyed from SP to LEC. Definitions in this solution proposal should be appropriate to that case as well. Copyright OASIS Open All Rights Reserved. Page 12 of 18

13 5 Security Considerations The AuthnRequest and AuthnResponse elements should be signed. The LECP and PAOS header should be integrity protected, such as with SOAP Message Security or through the use of SSL/TLS over every link. The SP should be authenticated to the LEC, for example with server-side TLS authentication. The LEC should be authenticated to the IDP, such as by maintaining an authenticated session. Copyright OASIS Open All Rights Reserved. Page 13 of 18

14 6 References [ LIBFFBind ] Liberty ID-FF Bindings and Profiles Specification, Version: 1.2, [ LIBFFProt ] Liberty ID-FF Protocols and Schema Specification, Version: 1.2, [ PAOS ] Aarts, R., Liberty Reverse HTTP Binding for SOAP Specification, Version: 1.0, [ SSTC-Liberty1.1 ] Liberty v1.1 specification set submittal letter, 11 Apr 2003, [ SSTC-Liberty1.2 ] Liberty ID-FF 1.2 Contribution to SSTC, 13 Nov 2003, [ WSDL1_1 ] Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001, Copyright OASIS Open All Rights Reserved. Page 14 of 18

15 7 XML Schema <?xml version='1.0' encoding='utf-8'?> <schema xmlns:lib=' xmlns:lecp='urn:liberty:lecp: ' xmlns=' xmlns:soap=' elementformdefault='qualified' targetnamespace='urn:liberty:lecp: ' attributeformdefault='unqualified'> <import schemalocation=' namespace=' <import schemalocation='lib-arch-protocols-schemas.xsd' namespace=' <element type='lecprequesttype' name='request'/> <complextype name='lecprequesttype'> <sequence> <element ref='lib:providerid'/> <element minoccurs='0' type='string' name='providername'/> <element minoccurs='0' ref='lib:idplist'/> <element minoccurs='0' type='boolean' name='ispassive'/> </sequence> <attribute use='required' ref='soap:mustunderstand'/> <attribute use='required' ref='soap:role'/> </complextype> <element type='lecpresponsetype' name='response'/> <complextype name='lecpresponsetype'> <attribute use='required' ref='soap:mustunderstand'/> <attribute use='required' ref='soap:role'/> </complextype> </schema> Note: Figure 8: XML Schema We may wish to use a URL instead of URN for the target namespace. Note also that the LECP URN namespace is a placeholder for the correct namespace. Copyright OASIS Open All Rights Reserved. Page 15 of 18

16 A. Acknowledgments Copyright OASIS Open All Rights Reserved. Page 16 of 18

17 B. Revision History Rev Date By Whom What Jan 04 Frederick Hirsch Initial SSTC Draft solution proposal. Copyright OASIS Open All Rights Reserved. Page 17 of 18

18 C. 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 OASIS Open 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 does 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. Copyright OASIS Open All Rights Reserved. Page 18 of 18