Open Data Center Alliance Usage: Cloud Based Identity Provisioning Rev. 1.0

Transcription

1 sm Open Data Center Alliance Usage: Cloud Based Identity Provisioning Rev. 1.0

2 Table of Contents Legal Notice... 3 Executive Summary... 4 Purpose... 5 Reference Framework... 5 Applicability... 6 Related Usage Models... 6 Taxonomy... 6 Usage Scenarios... 7 Real-Time Identity Provisioning... 7 Batch Identity Provisioning... 8 Subscriber-Driven Identity Suspension... 9 Event-Driven Identity Suspension...10 Identity Resume...11 Identity Attribute Change...12 Identity Deprovisioning...13 Industry Call to Action...15 References

3 Legal Notice This Open Data Center Alliance SM Usage Model: Cloud Based Identity Provisioning is proprietary to the Open Data Center Alliance, Inc. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Open Data Center Alliance Participants only have the right to review, and make reference or cite, this document. Any such references or citations to this document must give the Open Data Center Alliance, Inc. full attribution and must acknowledge the Open Data Center Alliance, Inc. s copyright in this document. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Open Data Center Alliance Participants is subject to the Open Data Center Alliance s bylaws and its other policies and procedures. OPEN CENTER DATA ALLIANCE SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo SM are service marks owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document and its contents are provided AS IS and are to be used subject to all of the limitation set forth herein. Users of this document should not reference any initial or recommended methodology, metric, requirements, or other criteria that may be contained in this document or in any other document distributed by the Alliance ( Initial Models ) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. Any proposals or recommendations contained in this document including, without limitation, the scope and content of any proposed methodology, metric, requirements, or other criteria does not mean the Alliance will necessarily be required in the future to develop any certification or compliance or testing programs to verify any future implementation or compliance with such proposals or recommendations. This document does not grant any user of this document any rights to use any of the Alliance s trademarks. All other service marks, trademarks and trade names referenced herein are those of their respective owners. Published April,

4 sm Open Data Center Alliance Usage: Cloud Based Identity Provisioning rev. 1.0 Executive Summary Many organizations that are considering purchasing cloud-based services already have fully integrated identity and access management systems. These systems are normally connected throughout the internal systems of an organization and allow automated provisioning of user identities across systems within the enterprise. As the resources in the cloud become more prevalent in the enterprise user and systems administrators will expect this functionality to be maintained. Consistent identity information across all cloud resources will, in turn, support the billing and management of these resources. The scope of this usage model is limited to automatic provisioning only--that is, situations where the cloud subscriber has an identity management system that will be used to provision identities to cloud providers. This identity management system may lie within the enterprise or within the cloud but will remain under the control of the cloud subscriber. This usage model provides the structure and guidelines that will create interoperability guidelines between identity and access management systems in the specific area of identity provisioning. The interaction between subscriber and provider will be based on the Organization for the Advancement of Structured Information Standards (OASIS) Service Provisioning Markup Language (SPML). The overall picture can be seen in the ODCA Identity Management Interoperability Guide 1. The usage model includes a number of independent themes which together form the key requirements of the usage model. It is required that a single, consistent mechanism is available for the provisioning of all users in the cloud. This will take the form of mandatory and optional sections of an SPML interaction. Cloud subscribers must ensure that the identity management systems within the organization are capable of sending all elements of this defined SPML interaction. These systems must also be able to differentiate between different cloud resources and have the capability to create individual profiles for these services. Conversely, cloud providers must ensure their systems are capable of processing all mandatory and any agreed upon (through initial contract) optional sections of the SPML interaction. The cloud provider and identity management software communities are requested to propose sample implementations for review within the ODCA. This document serves a variety of audiences. Solution providers and technology vendors will benefit from its content to better understand customer needs and tailor service and product offerings. Standards organizations will find the information helpful in defining end-user relevant and open standards. Because this usage model deals exclusively with the identity provisioning function shown above, it will be particularly useful to those people who design identity management interfaces in both cloud provider and cloud subscriber organizations. 1 InteropGuide_Rev1.0_final.pdf 4

5 Purpose The ODCA Cloud-Based Identity Provisioning Usage Model 2 was written to clarify and unify processes for identity provisioning in the cloud and to create a consistent mechanism for interactions between cloud subscribers and providers in the area of identity provisioning. Reference Framework The following diagram shows a framework of the functional areas of identity management. This framework provides a reference model for the usage models described below. The usage model does not cover any processes related to the authorization and creation of users that occur within the cloud subscribers organization. Identity and Access Management Framework Identity and Access Management Identity Lifecycle Management Identity and Authentication Management Authorization and Permission Lifecycle Management Authorization and Permission Management Identity Governance Identity Creation/ Validation Identity Federation Entitlement Externalization Access Control Services Confirm Validation Identity Provisioning (add/modify/delete) Directory Services / User Repositories Entitlement Provisioning Policy Enforcement Point (PEP) Auditing and Reporting Mover / Leaver Process Authentication Mover / Leaver Process Policy Decision Point (PDP) Monitoring Strong Authentication Role Mining and Discovery Weak Authentication Reporting for Audit / Compliance Checks Sign On Multiple Sign On Reduced Sign On (web, desktop) Single Sign On Credential Management Policy Enforcement Point (PEP) 2 5

6 Applicability This usage model is applicable to Software as a Service (SaaS) and may in some cases also be applicable to Platform as a Service (Paas) and Infrastructure as a Service (IaaS). The usage model should be applied in the case of Bronze, Silver, Gold, and Platinum levels of security, as defined in the ODCA Cloud Provider Assurance Usage Model 3, being required. Correlation of applicability to other use models can be found in the ODCA Identity Management Interoperability Guide 1. Related Usage Models This usage model is referenced from the ODCA Identity Management Interoperability Guide 1. This guide demonstrates the relationships between the different elements of identity management. General requirements for the levels of security required in cloud solutions can be found in the ODCA Provider Assurance Usage Model 3. Taxonomy Actor Name Cloud Subscriber Cloud Subscriber User Cloud Subscriber Administrator Cloud Provider Description A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud. A user of a cloud subscriber organization who consumes the cloud service provided by the cloud provider as an end user. For example, an organization s user who is using a SaaS service the organization subscribes to would be a cloud subscriber s user. An administrator type of user of a cloud subscriber organization that performs (cloud) system related administration tasks for the cloud subscriber organization. An organization providing network services and charging cloud subscribers. A (public) cloud provider provides services over the Internet. 1 InteropGuide_Rev1.0_final.pdf 3 6

7 Usage Scenarios Usage Scenario 1: Real-Time Identity Provisioning Actors: cloud subscriber, cloud subscriber administrator, cloud provider Goal: The cloud subscriberrequires the provisioning of, in real time, an account for a cloud subscriber user that involves accessing resources that are managed by the cloud provider. Assumption 1: The cloud subscriberhas existing policies that allow for provisioning of accounts in all other environments in the organization. The cloud subscriberhas a role based identity management system or equivalent that can differentiate between the types of resources required for a cloud subscriber user and is used to manage all identity provisioning tasks at the cloud provider. Assumption 2: The OASIS SPML is used for all provisioning transactions and the SPML schema has been previously defined. (to be followed up after review by providers). Assumption 3: The interface provided by the cloud provider will be through a single SPML-based application programming interface (API). Assumption 4: There is a predefined, secure, and trusted communication channel (SSL, VPN(IPSec/SSL), SSH, etc) between parties, and mechanisms are in place to ensure the integrity of the communication between cloud subscriber and cloud provider systems. Assumption 5: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario 1: A new user is created in the identity management system and, if the appropriate roles are requested, relevant information is passed to the cloud provider. The cloud provider creates the user identity within the cloud system and confirms this to the cloud subscriber. Steps: 1. Within the enterprise identity management system, the cloud subscriber identifies that cloud subscriber user (or multiple users) requires access to a cloud based resource. 2. The identity management system then completes an SPML AddRequest transaction with the cloud provider using the previously agreed upon schema. This schema will contain all mandatory elements and any agreed upon optional components. 3. The cloud provider completes the necessary steps and the user account is provisioned for the relevant resource. 4. The cloud provider returns an SPML AddResponse indicating the successful implementation of the request. 5. The identity management system of the cloud subscriber registers the successful operation and identifies the resource as active for the cloud subscriber user. Failure Condition 1: A failure message is received from the cloud provider system as a response to the SPML AddRequest indicating that the account has not been created. Failure Handling 1: The identity management system of the cloud subscriber identifies the error and escalates as appropriate. Failure Condition 2: Following the SPML AddRequest no response is received from the cloud provider. In this case, the status of the request is unclear. 7

8 Failure Handling 2: The request should be identified within the identity management system of the cloud subscriber as a potential risk and should be flagged to the cloud subscriber administrator as requiring further investigation. Usage Scenario 2: Batch Identity Provisioning Actors: cloud subscriber, cloud subscriber administrator, cloud provider Goal: The cloud subscriber requires the provisioning of, as a batch process, accounts for the cloud subscriber users to enable access to resources that are managed by the cloud provider. Assumption 1: The cloud subscriber has existing policies that allow for provisioning of accounts in all other environments in the organization. The cloud subscriber has a role-based identity management system or equivalent that can differentiate between the types of resources required for a cloud subscriber user and is used to manage all identity provisioning tasks at the cloud provider. Assumption 2: The OASIS SPML is used for all provisioning transactions and the SPML Schema has been previously defined. Assumption 3: The interface provided by the cloud provider will be through a single SPML-based API. Assumption 4: There is a predefined, secure, and trusted communication channel (SSL, VPN(IPSec/SSL), SSH, etc) between parties, and mechanisms are in place to ensure the integrity of the communication between cloud subscriber and cloud provider systems. Assumption 5: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario 1: A number of new users requiring access to cloud resources are created in the identity management system and are stored in preparation for batch transfer. When appropriate, the batch data containing the relevant information is passed to the cloud provider. The cloud provider creates the user identities within the cloud system and confirms this to the cloud subscriber. Steps: 1. Within the enterprise identity management system, the cloud subscriber identifies that the cloud subscriber user requires access to a cloud based resource. 2. This request is stored within the identity management system in preparation for batch processing. 3. At the commencement of batch processing the identity management system generates multiple SPML AddRequests (that can be combined with other SPML tasks) and then completes the batch transaction with the cloud provider using the previously agreed upon schema. This schema will contain all mandatory elements and any agreed upon optional components. 4. The cloud provider completes the necessary steps by provisioning the requested user accounts for the relevant resources. 5. The cloud provider returns a series of SPML messages that contain the appropriate AddResponse messages indicating the successful implementation of the requests. 6. The identity management system of the cloud subscriber registers the successful operations and identifies the resources as active for the cloud subscriber users. Failure Condition 1: A failure message is received from the cloud provider system as a response to one or more of the SPML AddRequest messages indicating that certain accounts have not been created. 8

9 Failure Handling 1: The identity management system of the cloud subscriber should identify the errors and escalate as appropriate. Failure Condition 2: Following the transmission of the batch file, either no response is received from the cloud provider or the information regarding specific requests is unavailable. In this case, it is unclear as to the status of one or more of the requests. Failure Handling 2: The requests should be identified within the identity management system of the cloud subscriber as a potential risk and should be flagged to the cloud subscriber administrator as requiring further investigation. Usage Scenario 3: Subscriber-Driven Identity Suspension Actors: cloud subscriber, cloud subscriber administrator, cloud provider Goal: The cloud subscriber requires the suspension of access to the account of a cloud subscriber user that has the ability to access resources that are managed by the cloud provider. Assumption 1: The cloud subscriber has existing policies that allow for suspension of accounts. The cloud subscriber has a role-based identity management system or equivalent that can differentiate between the types of resources required for a cloud subscriber user and is used to manage all identity provisioning tasks at the cloud provider. Assumption 2: The OASIS SPML is used for all transactions and the SPML Schema required to complete this action has been previously defined. Assumption 3: The interface provided by the cloud provider will be through a single SPML-based API. Assumption 4: There is a predefined, secure, and trusted communication channel (SSL, VPN(IPSec/SSL), SSH, etc) between parties, and mechanisms are in place to ensure the integrity of the communication between cloud subscriber and cloud provider systems. Assumption 5: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario 1: A user account, within the identity management system of the cloud subscriber, which has access to resources managed by the cloud provider, is suspended and future access to the resources is prevented by the cloud provider. Steps: 1. Within the enterprise identity management system, the cloud subscriber identifies that access by a cloud subscriber user to a cloud based resource must be suspended. 2. The identity management system then completes an SPML SuspendRequest transaction with the cloud provider by using the previously agreed upon schema. This schema will contain all mandatory elements and any agreed upon optional components. 3. The cloud provider completes the necessary steps and the user account is suspended for the relevant resource. 4. The cloud provider returns an SPML SuspendResponse indicating the successful implementation of the request. 5. The identity management system of the cloud subscriber registers the successful operation and identifies the resource as suspended for the cloud subscriber user. 9

10 Failure Condition 1: A failure message is received from the cloud provider system as a response to the SPML SuspendRequest indicating that the account has not been suspended. Failure Handling 1: The request should be identified within the identity management system of the cloud subscriber as a potential risk and should be flagged to the cloud subscriber administrator as requiring further investigation. Failure Condition 2: Following the SPML SuspendRequest no response is received from the cloud provider. In this case, the status of the request is unclear. Failure Handling 2: The request should be identified within the identity management system of the cloud subscriber as a potential risk and should be flagged to the cloud subscriber administrator as requiring further investigation. Usage Scenario 4: Event-Driven Identity Suspension Actors: cloud subscriber, cloud subscriber administrator, cloud provider Goal: Due to particular events, relating to a cloud subscriber user, the cloud subscriber requires that access to the account of a cloud subscriber user is automatically suspended and the ability to access resources that are managed by the cloud provider is removed. Assumption 1: The cloud provider systems allow for the generation of automated events which will lead to the suspension of accounts. The cloud subscriber has a role-based identity management system or equivalent that can differentiate between the types of resources required for a cloud subscriber user and is used to manage all identity provisioning tasks at the cloud provider. Assumption 2: The OASIS SPML is used for all transactions and the SPML Schema required to complete this action has been previously defined. (to be followed up after review by providers). Assumption 3: The interface provided by the cloud provider will be through a single SPML-based API. Assumption 4: There is a predefined, secure, and trusted communication channel (SSL, VPN (IPSec/SSL), SSH, etc) between parties and mechanisms are in place to ensure the integrity of the communication between cloud subscriber and cloud provider systems. Assumption 5: The policy breaches (whether time or event triggered) are previously defined. Assumption 6: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario 1: The cloud provider system identifies that a user account within the identity management system of the cloud subscriber, which has access to resources managed by the cloud provider, breaches agreed upon policies. The user account is then suspended and future access to the resources is prevented by the cloud provider. Steps: 1. Within the cloud provider system a policy breach is identified. 2. The cloud provider system then generates an SPML SuspendRequest transaction. 3. The cloud provider completes the necessary steps and the user account is suspended for the relevant resource. 10

11 4. The cloud provider generates an SPML ModifyRequest to the cloud subscriber indicating the implementation of the change and identifying the reason for the suspension. 5. The identity management system of the cloud subscriber registers the operation and identifies the resource as suspended for the cloud subscriber user. 6. The cloud subscriber sends an SPML ModifyResponse to the cloud provider to acknowledge the change. Failure Condition 1: The correct SPML ModifyResponse is not received by the cloud provider. Failure Handling 1: The cloud provider system should escalate this and should contact the cloud subscriber through another channel advising that the cloud subscriber user account has been suspended. Usage Scenario 5: Identity Resume Actors: cloud subscriber, cloud subscriber administrator, cloud provider Goal: The cloud subscriber requires that access to the account of a cloud subscriber user that was previously suspended using the above process is resumed. Assumption 1: The cloud subscriber has existing policies that allow for resumption of accounts. The cloud subscriber has a role-based identity management system or equivalent that can differentiate between the types of resources required for a cloud subscriber user and is used to manage all identity provisioning tasks at the cloud provider. Assumption 2: The OASIS SPML is used for all transactions and the SPML Schema required to complete this action has been previously defined. (to be followed up after review by providers). Assumption 3: The interface provided by the cloud provider will be through a single SPML-based API. Assumption 4: There is a predefined, secure, and trusted communication channel (SSL, VPN(IPSec/SSL), SSH, etc) between parties and mechanisms are in place to ensure the integrity of the communication between cloud subscriber and cloud provider systems. Assumption 5: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario 1: A user account, within the identity management system of the cloud subscriber, that was previously suspended, is returned to normal operation with access to resources managed by the cloud provider returned to the state it existed before the suspension. Steps: 1. Within the enterprise identity management system, the cloud subscriber identifies that a previously suspended cloud subscriber user account must be re-enabled. 2. The identity management system then completes an SPML ResumeRequest transaction with the cloud provider using the previously agreed upon schema. This schema will contain all mandatory elements and any agreed upon optional components. 3. The cloud provider completes the necessary steps and the user account is re-enabled for the relevant resource. 4. The cloud provider returns an SPML ResumeResponse indicating the successful implementation of the request. 11

12 5. The identity management system of the cloud subscriber registers the successful operation and identifies the resource as resumed for the cloud subscriber user. Failure Condition 1: A failure message is received from the cloud provider system as a response to the SPML ResumeRequest indicating that the account has not been suspended. Failure Handling 1: The identity management system of the cloud subscriber should identify the error and escalate as appropriate. Failure Condition 2: Following the SPML ResumeRequest no response is received from the cloud provider. In this case, the status of the request is unclear. Failure Handling 2: The request should be identified within the identity management system of the cloud subscriber as a potential risk and should be flagged to the cloud subscriber administrator as requiring further investigation. Usage Scenario 6: Identity Attribute Change Actors: cloud subscriber, cloud subscriber administrator, cloud provider Goal: The cloud subscriber requires that certain attributes of the account of a cloud subscriber user be changed. Assumption 1: The cloud subscriber has existing policies that allow for modification of account attributes. The cloud subscriber has a rolebased identity management system or equivalent that can differentiate between the types of resources required for a cloud subscriber user and is used to manage all identity provisioning tasks at the cloud provider. Assumption 2: The OASIS SPML is used for all transactions and the SPML Schema required to complete this action has been previously defined. Assumption 3: The interface provided by the cloud provider will be through a single SPML-based API. Assumption 4: There is a predefined, secure, and trusted communication channel (SSL, VPN(IPSec/SSL), SSH, etc) between parties and mechanisms are in place to ensure the integrity of the communication between cloud subscriber and cloud provider systems. Assumption 5: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario 1: A user account, within the identity management system of the cloud subscriber, is modified to contain up-to-date information. Steps: 1. Within the enterprise identity management system, the cloud subscriber identifies that the account information of a cloud subscriber user account must be changed. 2. The identity management system then completes an SPML ModifyRequest transaction with the cloud provider using the previously agreed upon schema. This schema will contain all mandatory elements and any agreed upon optional components. 3. The cloud provider completes the necessary changes for the relevant resource. 12

13 4. The cloud provider returns an SPML ModifyResponse indicating the successful implementation of the request. 5. The identity management system of the cloud subscriber registers the successful operation and identifies the resource as modified for the cloud subscriber user. Failure Condition 1: A failure message is received from the cloud provider system as a response to the SPML ModifyRequest indicating that the account has not been updated. Failure Handling 1: The identity management system of the cloud subscriber should identify the error and escalate as appropriate. Failure Condition 2: Following the SPML ModifyRequest no response is received from the cloud provider. In this case, the status of the request is unclear. Failure Handling 2: The identity management system of the cloud subscriber should identify the error and escalate as appropriate. Usage Scenario 7: Identity Deprovisioning Actors: cloud subscriber, cloud subscriber administrator, cloud provider Goal: The cloud subscriber requires deprovisioning an account of a cloud subscriber user that has access to resources that are managed by the cloud provider. Assumption 1: The cloud subscriber has existing policies that allow for deprovisioning of accounts in all other environments in the organization. The cloud subscriber has a role-based identity management system or equivalent that can differentiate between the types of resources required for a cloud subscriber user and is used to manage all identity provisioning tasks at the cloud provider. Assumption 2: The OASIS SPML is used for all transactions and the SPML Schema has been previously defined. (to be followed up after review by providers). Assumption 3: Before a cloud subscriber user identity can be deleted all data owned by the cloud subscriber user either has been deleted or moved. Assumption 4: The interface provided by the cloud provider will be through a single SPML-based API. Assumption 5: There is a predefined, secure, and trusted communication channel (SSL, VPN(IPSec/SSL), SSH, etc) between parties and mechanisms are in place to ensure the integrity of the communication between cloud subscriber and cloud provider systems. Assumption 6: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario 1: The access requirement to resources managed by a cloud provider of an existing user in the identity management system is removed and the relevant account information is deleted by the cloud provider. 13

14 Steps: 1. Within the enterprise identity management system, the cloud subscriber identifies that a cloud subscriber user is required to be deleted from a cloud-based resource. 2. The identity management system then completes an SPML DeleteRequest transaction with the cloud provider by using the previously agreed upon schema. This schema will contain all mandatory elements and any agreed upon optional components. 3. If cloud subscriber user is not the owner of resources held within the cloud provider environment (that is, no data would become orphaned by completing the process) then; a. The cloud provider completes the necessary steps and the user account is de-provisioned for the relevant resource. b. The cloud provider returns an SPML DeleteResponse indicating the successful implementation of the request. c. The identity management system of the cloud subscriber registers the successful operation and shows the identity as deleted for the cloud subscriber user. 4. If the cloud subscriber user is the owner of resources held within the cloud provider environment (that means that deleting the user would result in data existing in the cloud without a defined owner also existing) then; Failure Condition 1: a. The cloud provider returns an SPML DeleteResponse indicating a not possible response and giving the reason as cannot orphan data. b. The identity management system of the cloud subscriber registers the operation as not successful. (In this case, the cloud subscriber should first delete or reassign the relevant data.) A failure message is received from the cloud provider system as a response to the SPML DeleteRequest (other than that shown above) indicating that the account has not been deleted. Failure Handling 1: The request should be identified within the identity management system of the cloud subscriber as a potential risk and should be flagged to the cloud subscriber administrator as requiring further investigation. Failure Condition 2: Following the SPML DeleteRequest no response is received from the cloud provider. In this case, the status of the request is unclear. Failure Handling 2: The request should be identified within the identity management system of the cloud subscriber as a potential risk and should be flagged to the cloud subscriber administrator as requiring further investigation. 14

15 Industry Call to Action The following further actions are required: The ODCA requires providers of identity management systems for the enterprise and cloud providers to produce reference models and proofof-concept implementations that show compliance to this requirement. References OASIS Service Provisioning Markup Language (SPML) Version 2 4 OASIS Security Assertion Markup Language (SAML) Version 2 5 Any use or other implementation of the above cited OASIS markup language specifications / protocols ( OASIS Language ) are subject to any and all intellectual property rights and other rights held by, and any other limitations or restrictions which may be asserted by, OASIS and/or its members as the owner or owners of said OASIS Language ( Proprietary Rights ). ODCA takes no position regarding the validity or scope of any such Proprietary Rights that might be claimed or asserted by OASIS and/ or its members which may pertain to the use or other implementation of said OASIS Language or the extent to which any license of any such Proprietary Rights might or might not be available; nor does it represent that it has made any independent effort to identify any such Proprietary Rights. Each user and implementer of the OASIS Language is solely responsible for obtaining any and all licenses which may be needed in order to use or otherwise implement said OASIS Language. Requests for information regarding the Proprietary Rights and any applicable licenses should only be directed to OASIS and should not be made to the ODCA. Copies of any Proprietary Rights disclosures that may have been made, or potential licenses to be made available, or the result of an attempt made to obtain a license or other permission for the use or implementation of such Proprietary Rights by any implementer or user of the OASIS Language should only be directed to OASIS. This reference to, or citation of, the OASIS Language is provided on an AS IS basis and THE OPEN DATA CENTER ALLIANCE AND ITS PARTICIPANTS AND MEMBERS HEREBY DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY WARRANTY THAT THE USE OR OTHER IMPLEMENTATON OF THE OASIS LANGUAGE (AS DEFINED ABOVE) WILL NOT INFRINGE ANY PROPRIETARY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE