[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposed Charter for OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC
To OASIS Members: A draft TC charter has been submitted to establish the OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee. In accordance with the OASIS TC Process Policy section 2.2: (http://www.oasis-open.org/committees/process-2008-02-05.php#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 11:45pm ET on 23 June 2008. OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending email to: mailto:firstname.lastname@example.org. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail. A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar. We encourage member comment and ask that you note the name of the proposed TC (XSPA) in the subject line of your email message. Regards, Mary --------------------------------------------------- Mary P McRae Manager of TC Administration, OASIS email: email@example.com web: www.oasis-open.org phone: 603.232.9090 =========== PROPOSED CHARTER FOR REVIEW AND COMMENT OASIS CROSS-ENTERPRISE SECURITY AND PRIVACY AUTHORIZATION (XSPA) TECHNICAL COMMITTEE 1a. Name OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC 1b. Statement of Purpose Enterprises, including the healthcare enterprise, need a mechanism to exchange privacy policies, consent directives and authorizations in an interoperable manner. At this time, there is no standard that provides a cross-enterprise security and privacy profile. The OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC will address this gap. The need for an XSPA profile has been identified by the security and privacy working group of the Healthcare Information Technology Standards Panel (HITSP). HITSP is an ANSI-sponsored body charged with identifying standard building blocks that can be leveraged to implement common healthcare use cases. The XSPA profile will require the participation of subject matter experts in several areas, including WS-Federation, SAML, WS-Trust, and possibly others noted below. OASIS has the unique combination of member expertise necessary to complete this work. The purpose of the XSPA profile is to address common needs: allow parties to adopt a set of methods that, taken together, will enable them immediately interoperate with other diverse participants in the same data exchanges; use readily available open standards, so that participation is broadly possible without significant licensing limitations, hardware or software choice constraints or single-source vendor risks; and provide a fully specified stack or set of specifications or options, all known to be interoperable. The foregoing needs are especially acute when the use of a particular set of methods is mandated, either by law or as a practical matter by its adoption by central actors in a mandatory system. Governmental health regulators are increasingly requiring certain parties exchange health and health payment information (such as personal health records, and itemize statements of health care charges and benefit payments) in electronic form, and use sets of data standards identified as broadly suitable and secure. Similar government-sponsored or government-encouraged standardization projects are underway in many other countries. The XSPA profile will provide another "building block" in the creation of large scale interoperability of health information. These profiles will also aid in achieving interoperability for secure data exchange among various health care entities including providers, hospitals, pharmacies and insurance companies. It is envisioned that the work produced by this committee will also help the National Health Information Network (NHIN) in the US for secure data exchange. It specifying the XSPA profile, where stable open standards exist, they should be noted and adopted. Where functions are not available, or some connective choices or additional material is required, it will be created. Doing so is the purpose for this committee's creation. The profile specified by this TC will have broad applicability to health communities beyond the regulated portion of U.S. healthcare data transactions that the HITSP panel is directed to address. Use cases from other instances of cognate data exchanges, particularly in healthcare privacy contexts, may be solicited and used to improve the TC's work. However, the first priority of this committee will be to deliver and demonstrate sets of standards-based methods that fulfill the identified security & privacy functions needed by HITSP's specifications of functions and mandates. The XSPA TC may also cover a more general enterprise server profile which will provide the building blocks for business models and industry applications. Some of the models investigated will include enterprise security and more generally SOA security. Application of how these security and privacy models apply to different industry sectors, including domains such as finance where privacy rights must be supported, will also be investigated if time permits. 1c. Scope The purpose of the TC is to specify sets of stable open standards and profiles, and create other standards or profiles as needed, to fulfill the security and privacy functions identified by the functions and data practices identified by HITSP, or specified in its use cases, as all are mandated or specified from time to time. These functions will at a minimum support the HITSP Access Control Transaction Package specification TP20, including those access control capabilities required to support the HITSP Manage Consent Directive Package specification TP30. This includes the support of reliable and auditable methods to identify, select and confirm the personal identity, official authorization status, and role data for the subjects, senders, receivers and intermediaries of electronic data; data needed to convey and/or enforce permitted operations on resources and associated conditions and obligations; and reasonable measures to secure and maintain the privacy and integrity of that data from end to end. 1. The TC may identify existing, stable open standards, and sets of standards, and alternative standards, extensions and profiles, for fulfilling each of the HITSP-identified functions and use cases. Where HITSP subject-matter-specific profiles have already identified such standards as recommended, those approved standards will be included in the TC's identified sets of standards. Where the TC identifies elements or alternatives not already so identified as recommended, the TC should, if it believes the additional alternatives are necessary or advisable, recommend their inclusion to the appropriate HITSP expert panel. 2. The TC may create and approve specifications, and extensions or profiles of specifications, as needed to fulfill HITSP-identified functions and use cases not satisfied by existing stable open standards. Contributions made to the committee for work issued by the committee itself will be subject to the OASIS IPR Policy. Any such work must include appropriate conformance clause or test information. Such work will be recommended for inclusion, as appropriate, in the standing recommendations of the appropriate HITSP expert panel. 3. The TC may elect, in the above specifications, extensions or profile, to indicate methods for the fulfillment of other publicly-available health-related use cases (or mandates), or functions described in those use cases (or mandates), including from other regions and other regulatory regimes; and may elect to create and approve additional specifications, and extensions or profiles of specifications, as needed, to fulfill those use cases or component functions. 4. The TC may elect to elaborate or extend any of the above use cases or functions, publish the same and create additional standards, profiles or extensions to support those augmented use cases or functional descriptions. In any such augmented work the TC must specify whether it is intended to fulfill an HITSP (or other) mandate. Any such work must include appropriate conformance clause or test information. Such work completed may be recommended for inclusion, as appropriate, in the recommendations or reports of any relevant health regulatory or advisory body. 5. The TC may elect to create supplemental information regarding the above matters such as demonstrations, implementation guides, best practices, FAQs, or other explanatory, implementation or promotional material as it may deem useful. 6. In all of its work, the TC should, to the extent feasible, prefer widely implementable, widely interoperable, modular standards, extensions, profiles and methods that permit use by a variety of participants with diverse hardware, software, data architecture and messaging practices. The TC intends to ask OASIS to contribute all or part of its final work, as relevant, HITSP or related panels for incorporation into its recommendations and mandates. 1d. List of Deliverables 1. A list of the specific HITSP use cases and functions that the TC plans to fulfill, by October 2008. 2. A set of specifications, sets, profiles and extensions, as described in paragraphs #1 and #2 under 'Scope', to fulfill each of the HITSP use cases and functions identified for fulfillment in deliverable paragraph #1, with the first such specification or profile to be approved as a Committee Specification by [December 2008], and the remainder if any to be approved by Committee Specifications by [June 2009]. The TC may elect to create one or more of such deliverables in whatever combinations it deems appropriate. 3. An interoperability demonstration of the XSPA profile, consistent with paragraph #5 under 'Scope,' demonstrating the end-to-end enforcement of healthcare security policy at the HIMSS (Healthcare Information and Management Systems Society) meeting (April 2009). 4. Optionally, such other deliverables (e.g., those listed in paragraphs 1-6 under 'Scope') as the TC may elect, until the later of December 2009 or such later date as the TC may elect to conclude. 1e. IPR Mode: Royalty Free on Limited Terms under the OASIS IPR Policy 1f. Anticipated Audiences: Health-related data transaction participants, especially in exchanges subject to security or privacy regulation; regulators of healthcare, health payment and personal privacy; vendors and integrators supplying products or services to the foregoing; and, secondarily, participants in regulated or closely monitored data exchanges with privacy and security requirements in other topical fields. 1g. Language: English (2) Non-normative information regarding the startup of the TC, which includes: (2)(a) Identification of similar or applicable work that is being done in other OASIS TCs or by other organizations, why there is a need for another effort in this area and how this proposed TC will be different, and what level of liaison will be pursued with these other organizations. The proposed Cross-Enterprise Security and Privacy Authorization (XSPA) TC will be incorporating several standards in a profile allowing the exchange of privacy policies, consent directives and authorizations in an interoperable manner. The need for an XSPA profile has been identified by the security and privacy working group of the ANSI-sponsored Healthcare Information Technology Standards Panel (HITSP). No other organization is addressing this identified gap in standards. The profile will use standards from several OASIS TCs: SAML (SSTC), WS-Trust (WS-SX) and XACML. Liaison will be established by concurrent work items in the cited TCs' area of expertise. (2)(b) The date, time, and location of the first meeting, whether it will be held in person or by telephone, and who will sponsor this first meeting. The first meeting of a TC shall occur no less than 30 days after the announcement of its formation in the case of a meeting held exclusively by telephone or other electronic means, and no less than 45 days after the announcement of its formation in the case of a meeting held face-to-face (whether or not a telephone bridge is also available). The proposed XSPA TC will hold the first official meeting on August 8, 2008 by telephone and will use a free conference call service. (2)(c) The projected on-going meeting schedule for the year following the formation of the TC, or until the projected date of the final deliverable, whichever comes first, and who will be expected to sponsor these meetings. The TC will meet biweekly or as otherwise agreed upon by the members of the technical committee. (2)(d) The names, electronic mail addresses, and membership affiliations of at least Minimum Membership who support this proposal and are committed to the Charter and projected meeting schedule. Mark Little, firstname.lastname@example.org (Redhat) Anil Saldhana, Anil.Saldhana@redhat.com (Redhat) Sampo Kellomki, email@example.com (Symlabs) Anil Tappetla, firstname.lastname@example.org (Cisco) David Staggs, email@example.com (Veterans Health Administration) (2)(e) The name of the Convener who must be an Eligible Person. David Staggs. (2)(f) The name of the Member Section with which the TC intends to affiliate, if any. None. (2)(g) Optionally, a list of contributions of existing technical work that the proposers anticipate will be made to this TC. None. (2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document regarding the planned scope of the TC, for posting on the TC's website. To be provided at a later date. (2)(i) Optionally, a proposed working title and acronym for the specification(s) to be developed by the TC. To be provided at a later date.