cross-enterprise security and privacy authorization (xspa ... · web viewthese assertions are...
TRANSCRIPT
Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of SAML v2.0 for Healthcare Version 2.0
Working Draft 04
17 July 2013
Technical Committee:OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC
Chair:Mohammad Jafari ([email protected]), Veterans Health Administration
Editors:Duane DeCouteau ([email protected]), Veterans Health AdministrationMohammad Jafari ([email protected]), Veterans Health Administration
Additional artifacts:This prose specification is one component of a Work Product that also includes: XML schemas: (list file names or directory name) Other parts (list titles and/or file names)
Related work:This specification replaces or supersedes: Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion
Markup Language (SAML) v2.0 for Healthcare Version 1.0. 1 November 2009. OASIS Standard. http://docs.oasis-open.org/security/xspa/v1.0/saml-xspa-1.0-os.html.
This specification is related to the OASIS Security Assertion Markup Language (SAML) V2.0, comprised of the following documents: Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0. 15
March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf.
Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. 15 March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.
Conformance Requirements for the OASIS Security Assertion Mark Markup Language (SAML) V2.0. 15 March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf.
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. 15 March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0. 15 March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf.
Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. 15 March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.
Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. 15 March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.
Security Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0. 15 March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf.
SAML Version 2.0 Errata 05. 01 May 2012. OASIS Approved Errata. http://docs.oasis-open.org/security/saml/v2.0/errata05/os/saml-v2.0-errata05-os.html.
Declared XML namespaces:urn:oasis:names:tc:xacml:2.0urn:oasis:names:tc:xspa:1.0urn:oasis:names:tc:saml:2.0
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 1 of 31
Abstract:This profile describes a framework in which SAML is encompassed by cross-enterprise security and privacy authorization (XSPA) to satisfy requirements pertaining to information-centric security within the healthcare community.
Status:This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.
Initial URI pattern:http://docs.oasis-open.org/xspa/saml-xspa/v2.0/csd01/saml-xspa-v2.0-csd01.doc(Managed by OASIS TC Administration; please don’t modify.)
Copyright © OASIS Open 2013. All Rights Reserved.All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, 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 OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 2 of 31
Table of Contents1 Introduction ......................................................................................................................................... 5
1.1 Terminology ....................................................................................................................................... 51.2 Normative References ....................................................................................................................... 51.3 Non-Normative References ...............................................................................................................6
2 The XSPA Use-Case .......................................................................................................................... 72.1 Service User Access Control Service ................................................................................................82.2 Service Provider Access Control Service ..........................................................................................82.3 Security Policy ................................................................................................................................... 82.4 Privacy Policy .................................................................................................................................... 82.5 Attributes ........................................................................................................................................... 8
3 XSPA profile of SAML ......................................................................................................................... 93.1 Attribute Naming Syntax, Restrictions and Acceptable Values ..........................................................9
3.1.1 Name ......................................................................................................................................... 93.1.2 National Provider Identifier (NPI) – (optional) .............................................................................93.1.3 Organization ............................................................................................................................... 93.1.4 Organization-ID .......................................................................................................................... 93.1.5 Organizational-Hierarchy ..........................................................................................................103.1.6 Structural Role .........................................................................................................................103.1.7 Functional Role (optional) ........................................................................................................103.1.8 Permission (optional) ...............................................................................................................103.1.9 Action ....................................................................................................................................... 103.1.10 Execute (optional) ..................................................................................................................113.1.11 Resource ................................................................................................................................ 113.1.12 Purpose of Use (POU) ...........................................................................................................113.1.13 Patient Authorization ..............................................................................................................123.1.14 Supported Obligations ............................................................................................................123.1.15 Supported Refrain Policies .....................................................................................................123.1.16 Resource ................................................................................................................................ 13
3.2 Metadata Definitions ........................................................................................................................ 133.3 Naming Syntax, Restrictions and Acceptable Values ......................................................................133.4 Namespace Requirements ..............................................................................................................133.5 Attribute Rules of Equality ...............................................................................................................13
4 Other Considerations ........................................................................................................................144.1 Error States ..................................................................................................................................... 144.2 Security Considerations ...................................................................................................................14
4.2.1 Transmission Integrity ..............................................................................................................144.2.2 Transmission Confidentiality ....................................................................................................14
4.3 Confirmation Identifiers ....................................................................................................................145 Conformance ..................................................................................................................................... 15
5.1 Introduction ...................................................................................................................................... 155.2 Conformance Tables .......................................................................................................................16
Appendix A. Acknowledgments ............................................................................................................18Appendix B. Revision History ...............................................................................................................19
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 3 of 31
1 Introduction ......................................................................................................................................... 51.1 Terminology ....................................................................................................................................... 51.2 Normative References ....................................................................................................................... 51.3 Non-Normative References ...............................................................................................................6
2 XSPA profile of SAML Implementation ................................................................................................72.1 Interactions between Parties .............................................................................................................7
2.1.1 Access Control Service (Service User) ......................................................................................72.1.1 Access Control Service (Service Provider) .................................................................................72.1.2 Attributes .................................................................................................................................... 72.1.3 Security Policy ............................................................................................................................ 82.1.4 Privacy Policy ............................................................................................................................. 8
2.2 Protocols ........................................................................................................................................... 82.3 Transmission Integrity ....................................................................................................................... 82.4 Transmission Confidentiality ..............................................................................................................82.5 Error States ....................................................................................................................................... 82.6 Security Considerations ..................................................................................................................... 82.7 Confirmation Identifiers ...................................................................................................................... 92.8 Metadata Definitions .......................................................................................................................... 92.9 Naming Syntax, Restrictions and Acceptable Values ........................................................................92.10 Namespace Requirements ..............................................................................................................92.11 Attribute Rules of Equality ...............................................................................................................92.12 Attribute Naming Syntax, Restrictions and Acceptable Values ........................................................9
2.12.1 Name ....................................................................................................................................... 92.12.2 National Provider Identifier (NPI) – (optional) ...........................................................................92.12.3 Organization ........................................................................................................................... 102.12.4 Organization-ID ...................................................................................................................... 102.12.5 Organizational-Hierarchy ........................................................................................................102.12.6 Structural Role ....................................................................................................................... 102.12.7 Functional Role (optional) ......................................................................................................102.12.8 Permission (optional) .............................................................................................................102.12.9 Action ..................................................................................................................................... 112.12.10 Execute (optional) ................................................................................................................112.12.11 Object ................................................................................................................................... 112.12.12 Purpose of Use (POU) .........................................................................................................112.12.13 Patient Authorization ............................................................................................................122.12.14 Supported Obligations ..........................................................................................................122.12.15 Supported Refrain Policies ...................................................................................................122.12.16 Resource .............................................................................................................................. 13
3 Conformance ..................................................................................................................................... 143.1 Introduction ...................................................................................................................................... 143.2 Conformance Tables .......................................................................................................................15
Appendix A. Acknowledgments ............................................................................................................17Appendix B. Revision History ...............................................................................................................18
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 4 of 31
[1] IntroductionThis document describes a framework that provides access control interoperability useful in the healthcare environment. Interoperability is achieved using SAML assertions that carry common semantics and vocabularies in exchanges specified below.
1.1 TerminologyThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
The following definitions establish additional terminology and usage in this profile:
Access Control Service (ACS) – The Access Control Service is the An enterprise security service that performs access control functions as defined in [XACML-V3.0].that supports and implements user-side and service-side access control capabilities. The service would be utilized by the Service and/or Service User.
Object – An object is an entity that contains or receives information. The objects can represent information containers (e.g., files or directories in an operating system, and/or columns, rows, tables, and views within a database management system) or objects can represent exhaustible system resources, such as printers, disk space, and central processing unit (CPU) cycles. ANSI RBAC (American National Standards Institute Role Based Access Control)
Operation - An operation is an executable image of a program, which upon invocation executes some function for the user. Within a file system, operations might include read, write, and execute. Within a database management system, operations might include insert, delete, append, and update. An operation is also known as an action or privilege. ANSI RBAC
Permission -
An approval to perform an operation on one or more protected resourcesAn approval to perform an operation on one or more RBAC protected objects. [ANSI-INCITS 359-2004ANSI RBAC].
Structural Role -
Structural roles (also known as Organizational Roles) correspond to the organizational positions and represent a A job function within the context of an an organization. Assigning a user to a structural role [HL7-ROLE-ENG]; for example Attending Physician whose permissions are defined by operations on workflow objects [ASTM E2595]. ASTM (American Society for Testing and Materials) E2595-2007
Functional RoleFunctional roles reflect the essential business functions that need to be performed. Functional roles are defined by a set of standard healthcare tasks such as Neurologist [HL7-ROLE-ENG].
Service Provider (SP) - The service provider represents tA he system which providesing a protected resources such as an electronic health record system at a hospital. and relies on the provided security service.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 5 of 31
Entity - An entity may also be known as a principal and/or subject, which represents an application, a machine, or any other type of entity that may act as a requester in a transaction.
Service User Consumer (SC)- A system which makes requests to a Service Provider to access a protected resourceThe service user represents any individual entity [such as on an Electronic Health Record (EHR)/personal health record (PHR) system] that needs to make a service request of a Service Provider.
1.2 Normative References[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”,
BCP 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.[SAMLPROF] “Profiles for the OASIS Security Assertion Markup Language, v2.0,” March
2005, OASIS Standard, http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
[ANSI-INCITS 359-2004] Role-Based Access Control. 2004. [ASTM E1986-98 (2005)] Standard Guide for Information Access Privileges to Health
Information. 2005.[ASTM E2595 (2007)] Standard Guide for Privilege Management Infrastructure. 2007. [SAML] “Security Assertion Markup Language (SAML) v2.0”, OASIS Standard, 15
March 2005, http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
[HL7-CONSENT] HL7 Consent Related Vocabulary Confidentiality Codes Recommendation, http://lists.oasis-open.org/archives/xacml-demo-tech/200712/doc00003.doc
[HL7-PERM] HL7 Security Technical Committee, HL7 Version 3 Standard: Role-based Access Control Healthcare Permission Catalog, (Available through http://www.hl7.org/library/standards.cfm), Release 1, Designation: ANSI/HL7 V3 RBAC, R1-2008, Approval Date 2/20/2008February 2008.
[HL7-CONSENT] HL7 Consent Related Vocabulary Confidentiality Codes Recommendation, http://lists.oasis-open.org/archives/xacml-demo-tech/200712/doc00003.doc, from project submission: http://lists.oasis-open.org/archives/xacml-demo-tech/200712/msg00015.html[HL7-ROLE-ENG] HL7 Role-Based Access Control (RBAC) Role Engineering Process Version 1.3, HL7 Security Technical Committee, September 2007.
[XACML-V3.0] eXtensible Access Control Markup Language (XACML) Version 3.0. 22 January 2013. OASIS Standard. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
[1.3] Non-Normative References[XSPA-SAML-INTRO] OASIS Committee Working Draft, “Introductory overview of XSPA Profile
of SAML for Healthcare,” OASIS Committee Working Draft, December 2008, http://www.oasis-open.org/committees/document.php?document_id=30407
[XSPA-EXAMPLES] OASIS Committee Working Draft, “Implementers Guide of XSPA for Healthcare – The Nationwide Health Information Network (NwHIN),,” OASIS Committee Working Draft, March 2012, https://www.oasis-open.org/committees/download.php/45525/xspa-nwhin-adapter-guide.doc
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 6 of 31
2
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 7 of 31
[3]
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 8 of 31
[4]
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 9 of 31
[5] XSPA profile of SAML Implementation
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 10 of 31
[6] The XSPA profile of SAML describes the minimum vocabulary necessary to provide access control over resources and functionality within and between healthcare information technology (IT) systems. Additional introductory information and examples can be found in Cross-Enterprise Security and Privacy Authorization (XSPA) Implementers Guide of XSPA for Healthcare - The Nationwide Health Information Network (NwHIN) [XSPA-EXAMPLES].
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 11 of 31
[7] Interactions between PartiesThe XSPA Use-CaseFigure 1 displays depicts an overview of interactions between parties in the exchange of healthcare information. . The main scenario is as follows
T he end-user residing at the Service Consumer (SC) organization sends a request to access a protected resource which is in custody of the Service Provider (SP).
This request is captured by the Service Consumer’s service interface and authorization is performed by the consumer’s Access Control System to make sure it is permitted.
If the request is deemed authorized, the Service Consumer system, sends a request to its ACS to receive Identity and Authorization Attribute Assertions.
The SC sends a request to the SP for acquiring a copy of the health record in question. It provides Identity Assertions and Authorization Attributes alongside its request to prove to the SP its identity and that it is authorized to receive the requested resource. These MAY be passed in a single assertion from the SU to the SP.
The Service Provider’s Service Interface captures the request and sends it to the service provider’s Access Control Service.
If the request is deemed authorized, the Service Provider system sends a packaged copy of the requested record to the Consumer System. The copy of the data is not necessarily identical to the original records; it may bear annotations with handling instructions and some portions of it may be redacted or masked per policy requirements.
The Consumer System receives the protected resource and makes it available to the end user while enforcing the handling instructions and policies.
The above use-case may have some variations. The request for exchange may be initiated by the end user, or alternatively, the Consumer
System may proactively send the request to acquire the record before the user’s explicit request. For example, when an appointment is scheduled for a patient at a facility, the Consumer System may request the patient’s record, before the physician (the end user) requests it at the appointment time. Depending on the circumstances, the Consumer System may or may not know the identity of the end user at the exchange time. For example, if the physician will be assigned on the appointment day, the Consumer System does not which doctor will be assigned to this particular patient’s care at the exchange time.
Sometimes, a different user may initiate the request for exchange on behalf of the actual end user. For example, an Admin Assistant may initiate a request for the exchange of the record of a patient who will be visited by a physician.
The focus of this profile is the cross-enterprise exchange of the protected resource, which is the exchange between the Service Provider and the Service Consumer. Elements described in the figure are explained in the subsections below. The Service Request, Identity Assertion, and Authorization Attributes in Figure 1 are prepared by the Service User Access Control Service and MAY be passed in a single assertion from the Service User to the Service Provider. The Service Provider Access Control Service evaluates the request against policy and indicates to the Service Provider if the request may be fulfilled.Entities described in the figure are explained in the subsections below.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 12 of 31
Access Control Service
Figure 1: Interaction between Parties
2.1[7.1]
[7.2] Service User Access Control Service (Service User)The XSPA profile of SAML supports sending all requests through an The Access Control Service (ACS) at the Service User acts as an Identity Provider (IdP. ) and upon request by the The Access Control Service receives the Service User request and responds with a produces SAML assertions including the identity and authorization attributes, such as the requesting user’s ID, containing user authorizations and attributes. To perform its function, the ACS collects all the attributes (e.g. organizationorganization -iIdD, , structural structural role, , ffunctional role, and , ppurpose of use.
- These assertions are included alongside the request by the SU which also includes the identifier of the requested resource, requested resource, and actions) necessary to create the Service User requested assertion.
In addition to creating the request, the requesting ACS is responsible for enforcing local security and privacy policy.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 13 of 31
[7.3] Service Provider Access Control Service (Service Provider)The Service Provider ACS is responsible for the parsing of assertions, evaluating the assertions against the security and privacy policy, and making and enforcing a decision. The Service Provider enforces the decision made by its ACS. on behalf of the Service Provider.
2.2[7.4] Security PolicyThe security policy includes the authorization rules regarding applicable to authorizations required to access a protected resource and which may be based on various additional security conditionsattributes such as the requester’s role, purpose of use, (time and location of access, time of day, cardinality, separation of duty, purpose, etc.) that constrain enforcement.
2.3[7.5] Privacy PolicyThe privacy policy includes the set of consent directives and other privacy conditions rules about packaging (e.g. security labels and handling instructions) and segmenting of resources (e.g. object masking, and redaction) object filtering, user, role, purpose, etc.), as well as the preferences of the patient which are encoded as his or her consent directive. that constrain enforcement.
2.4[7.6] AttributesAttributes are information related about the access request (e.g. the to user ID, location, role, location, purpose of use, etc.) , and requested resource requirements and actions necessary to make an access control decisionwhich are consequential in making access control decisions.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 14 of 31
3 XSPA profile of SAML The XSPA profile of SAML describes the minimum vocabulary necessary to provide access control over resources and functionality within and between healthcare systems. This profile utilizes the SAML 2.0 core specification to define the elements exchanged in a cross-enterprise service request that supports security and privacy policies. Requests MAY be exchanged using a SAML assertion containing elements such as: saml2:Issuer, saml2:NameID, and saml2:AttributeStatement.
3.1 Data TypesTable 1 the standard data types used for the attributes in this profile. We use the abbreviated form to refer to the data types in the rest of this document.
Table 1: Standard Data Types (Normative)
Type ID Abbreviated Form
http://www.w3.org/2001/XMLSchema#string String
http://www.w3.org/2001/XMLSchema#anyURI anyURI
http://www.w3.org/2001/XMLSchema#boolean Boolean
http://www.w3.org/2001/XMLSchema#date Date
http://www.w3.org/2001/XMLSchema#time Time
Table 2 shows the normative data type defined by this profile for representing values belonging to a code system.
Table 2: New Data Types (Normative)
Type ID Abbreviated Form
urn:oasis:names:tc:xspa:2.0:data-type:hl7-org:v3:cv Hl7CV
This data type, which corresponds to the Coded Value (CV) data type in HL7, is a tuple composed of the following elements:
Code: The plain code symbol defined by the code system. Code System: the unique identifier the code system that defines the code. Code System Version: If applicable, a version descriptor defined specifically for the given
code system. Display Name (optional): an optional human-readable display name for the code. This
does not have any consequence in any access control processing. Code System Name (optional): an optional human-readable display name for the code
system.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 15 of 31
The following schema shows how this type must be encoded in XML form:<xs:element name=" urn:hl7-org:v3:cv" type="xspa:hl7-cv-type"/><xs:complexType name="xspa:hl7-cv-type"> <xs:attribute name="code" type="xs:string" use="required"/> <xs:attribute name="codeSystem" type="xs:string" use="required"/> <xs:attribute name="codeSystemVersion" type="xs:string" use="optional"/> <xs:attribute name="codeSystemName" type="xs:string" use="optional"/> <xs:attribute name="displayName" type="xs:string" use="optional"/></xs:complexType>
3.1.1 Security PolicyThe security policy includes the rules regarding authorizations required to access a protected resource and additional security conditions (location, time of day, cardinality, separation of duty, purpose, etc.) that constrain enforcement.
[7.6.1] Privacy PolicyThe privacy policy includes the set of consent directives and other privacy conditions (object masking, object filtering, user, role, purpose, etc.) that constrain enforcement.
3.2 Attribute Naming Syntax, Restrictions and Acceptable ValuesAttribute names MUST adhere to the rules defined by [SAMLCore]. For purposes of human readability, there may also be a requirement for some applications to carry an optional string name together with the Object Identifier (OID) or Uniform Resource Name (URN). The optional XML attribute FriendlyName (defined in [SAMLCore]) MAY be used for this purpose, but is not translatable into an XACML attribute equivalent.This profile will utilize the namespace of:
urn:oasis:names:tc:xspa:1.0
Example of use:<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:xspa:1.0:organization"> <saml:AttributeValue xsi:type="http://www.w3.org/2001/XMLSchema#string"> County Hospital </saml:AttributeValue></saml:Attribute>
Table 3: Attributes
Norm
ative
Identifier Type Description and Valid Values
Yes urn:oasis:names:tc:xacml:1.0:subject:subject-id String The name of the user as required by Health Insurance Portability and Accountability Act (HIPAA) Privacy Disclosure Accounting. This is typed as a plaint-text string.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 16 of 31
Norm
ative
Identifier Type Description and Valid Values
Yes urn:oasis:names:tc:xspa:1.0:subject:organization String The name of the organization to which the requesting user belongs as required by Health Insurance Portability and Accountability Act (HIPAA) Privacy Disclosure Accounting. This is typed as a plaint-text string.
Yes urn:oasis:names:tc:xspa:1.0:subject:organization-id anyURL The unique organization identifier of the service consumer.
Yes urn:oasis:names:tc:xspa:2.0:subject:organizational-hierarchy
Multi-valued
Unique identifier of the consuming sub-organization or region. Additional levels of sub-organizations shall be represented as multiple values in order of the most significant organization to the least. Every level shall be represented as an attribute of type anyURL.
Yes urn:oasis:names:tc:xspa:2.0:subject:child-organization anyURI Unique identifier of the Service Consumer organization and/or region
Yes urn:oasis:names:tc:xspa:1.0:subject:facility String Unique identifier for requesting facility. The facility is part of the child-organization.
Yes urn:oasis:names:tc:xacml:2.0:subject:role String The requesting user’s structural role. The OID for structural roles referenced in [ASTM E1986-98] is 1.2.840.10065.1986.7
Yes urn:oasis:names:tc:xacml:2.0:action:purpose HL7CV The purpose of use. The values must come from a standard purpose of use vocabulary such as HL7 security and privacy vocabulary [???].
No urn:oasis:names:tc:xspa:1.0:subject:functional-role String Functional roles provide a placeholder to group permissions required for fine grain access control. There MUST be mutual agreement of their use and definition between participating organizations.
No urn:oasis:names:tc:xspa:1.0:subject:npi String National Provider ID provided by U.S. Government for all active providers as required by Health Insurance Portability and Accountability Act (HIPAA) Privacy Disclosure Accounting. This is typed as a plaint-text string.
No urn:oasis:names:tc:xspa:2.0:subject::permissions String The requesting user’s permissions which represent the user’s capabilities. The values must come from a standard purpose of use vocabulary such as HL7 Permission Catalog.
The OID for the HL7 Permission Catalog [HL7-PERM] is 2.16.840.1.113883.13.27.
HL7 RBAC Permission Catalog [HL7-PERM] represents a conformant minimum interoperability set for resource/action pairings.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 17 of 31
Norm
ative
Identifier Type Description and Valid Values
Yes urn:oasis:names:tc:xacml:1.0:resource:resource-id String Unique identifier of the resource defined by and controlled by the servicing organizationprovider. In healthcare this is the patient unique identifier.
The mechanism used to identify the patient in a standardized way, e.g. resource:resource-id, is outside the scope of the profile.
Yes urn:oasis:names:tc:xspa:2.0:resource:type String For minimum interoperability set of objects and supporting actions refer to [HL7-PERM] and their OID representations.
Yes urn:gov:hhs:fha:nhinc:service-type String Synonymous with resource:typeresource:type.
Table 4 shows the list of deprecated attributes. These attributes SHALL still be supported but the vendors should be warned that the future versions of this profile may no longer support these attributes.
Table 4: Deprecated Attributes
Norm
ative
Identifier Type Description and Valid Values
Yes urn:oasis:names:tc:xspa:1.0:subject:purposeofuse String Deprecated by: urn:oasis:names:tc:xacml:2.0:action:purpose
Yes urn:oasis:names:tc:xspa:1.0:subject:subject-id String Deprecated by:urn:oasis:names:tc:xacml:1.0:subject:subject-id
3.2.1 ActionThe HL7 (Health Level Seven) RBAC Permission catalog is an ANSI INCITS 359-2004 RBAC compliant vocabulary that provides a minimal permission subset for interoperability. This profile specifies the use of the following HL7 RBAC Permission Catalog Actions: Append Create Delete Read Update Execute
3.2.2 Execute (optional)Execute refers to complex functions and stored procedures that provide for extended actions within the healthcare environment. Examples include "print", "suspend", and "sign". Execute can include custom attributes related to functionality agreed upon by the parties in an exchange.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 18 of 31
3.2.3 Purpose of Use (POU)Purpose of use provides context to requests for information resources. Each purpose of use will be unique to a specific assertion, and will establish the context for other security and privacy attributes. For a given claim, all assertions must be bound to the same purpose of use. Purpose of use allows the service to consult its policies to determine if the user’s authorizations meet or exceed those needed for access control. Purpose of Use will be typed as string with an identifying element of <urn:oasis:names:tc:xspa:1.0:subject:purposeofuse>
An authoritative listing of values can be found at following URL for GeneralPurposeOfUse values represented by OID2.16.840.1.113883.1.11.20449;
http://wiki.hl7.org/index.php?title=HL7_Security_Document_Library
Figure 3 illustrates the general relationship between subject (user) and granted permissions to specific objects as a relationship to their POU. Roles in this relationship are placeholders for permissions. Permission defines the object-action relationship.
Figure 2: Determining Subject Permissions
3.2.4 Patient AuthorizationThe URI shall be in the form of an opaque identifier that references the authoritative patient authorization. The mechanism for retrieving the authorization must be coordinated between the requesting organization and the servicing organization. The content of the authorization, and the protocol to retrieve the authorization is beyond the scope of this profile.e.x. urn:uuid{550e8400-e29b-41d4-a716-446655440000}
3.2.5 Supported ObligationsSpecifies user Obligation related to use of Sensitive Health Information that the requesting organization agrees(promise) and is capable of enforcing.Authoritative values for this attribute may be found at HL7 represented by OID 2.16.840.1.113883.1.11.20445. saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 19 of 31
http://wiki.hl7.org/index.php?title=HL7_Security_Document_Library
3.2.6 Supported Refrain PoliciesSpecifies Prohibitions on the use of Sensitive Health Information that the requesting organization agrees to (promises) and is capable of enforcing.
Authoritative values for this attribute may be found at HL7 represented by OID 2.16.840.1.113883.1.11.20446.
http://wiki.hl7.org/index.php?title=HL7_Security_Document_Library
3.3 Metadata DefinitionsThis profile will utilize the SAML <Attribute> element for all assertions.
3.4 Naming Syntax, Restrictions and Acceptable ValuesThis profile conforms to SAML 2.0 specification.
3.5 Namespace RequirementsThe NameFormat Extensible Markup Language (XML) attribute in <Attribute> elements MUST be:
urn:oasis:names:tc:SAML:2.0:attrname-format:uri
3.6 Attribute Rules of EqualityAll asserted attributes will be typed as strings. Two <Attribute> elements refer to the same SAML attribute if and only if their Name XML attribute values are equal in a binary comparison.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 20 of 31
4 Other Considerations[7.7] ProtocolsThis profile utilizes the SAML 2.0 core specification to define the elements exchanged in a cross-enterprise service request that supports security and privacy policies. Requests MAY be exchanged using a SAML assertion containing elements such as saml2:Issuer, saml2:NameID, and saml2:AttributeStatement.
[7.8] Transmission Integrity
[7.9] The XSPA profile of SAML recommends the use of reliable transmission protocols. Where transmission integrity is required, this profile makes no specific recommendations regarding mechanism or assurance level.
[7.10] Transmission Confidentiality
[7.11] The XSPA profile of SAML recommends the use of secure transmission protocols. Where transmission confidentiality is required, this profile makes no specific recommendations regarding mechanisms.
4.1[7.12] Error StatesThis profile adheres to error states describe in SAML 2.0.
4.2[7.13] Security ConsiderationsThe following security considerations are established for the XSPA profile of SAML:
Participating information domains have agreed to use XSPA profile and that a trust relationship exists,
Entities are members of defined information domains under the authorization control of a defined set of policies,
Entities have been identified and provisioned (credentials issued, privileges granted, etc.) in accordance with policy,
Privacy policies have been identified and provisioned (consents, user preferences, etc.) in accordance with policy,
Pre-existing security and privacy policies have been provisioned to Access Control Services, The capabilities and location of requested information/document repository services are
known, Secure channels are established as required by policy, Audit services are operational and initialized, and Entities have asserted membership in an information domain by successful and unique
authentication.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 21 of 31
4.2.1 Transmission IntegrityThe XSPA profile of SAML recommends the use of reliable transmission protocols. Where transmission integrity is required, this profile makes no specific recommendations regarding mechanism or assurance level.
4.2.2[7.13.1] Transmission ConfidentialityThe XSPA profile of SAML recommends the use of secure transmission protocols. Where transmission confidentiality is required, this profile makes no specific recommendations regarding mechanisms.
4.3[7.14]
[7.15] Confirmation IdentifiersThe manner used by the relying party to confirm that the requester message came from a system entity that is associated with the subject of the assertion will depend upon the context and sensitivity of the data. For confirmations requiring a specific level of assurance, this profile specifies the use of National Institute of Standards and Technology (NIST) Special Publication 800-63 Electronic Authentication Guideline. In addition, this profile specifies the Liberty Identity Access Framework (LIAF) criteria for evaluating and approving credential service providers.
[7.16] Metadata DefinitionsThis profile will utilize the SAML <Attribute> element for all assertions.
[7.17] Naming Syntax, Restrictions and Acceptable ValuesThis profile conforms to SAML 2.0 specification.
[7.18] Namespace RequirementsThe NameFormat Extensible Markup Language (XML) attribute in <Attribute> elements MUST be urn:oasis:names:tc:SAML:2.0:attrname-format:uri.
[7.19] Attribute Rules of EqualityAll asserted attributes will be typed as strings. Two <Attribute> elements refer to the same SAML attribute if and only if their Name XML attribute values are equal in a binary comparison.
[7.20] Attribute Naming Syntax, Restrictions and Acceptable Values
The Name XML attribute MUST adhere to the rules specified for that format, as defined by [SAMLCore]. For purposes of human readability, there may also be a requirement for some applications to carry an optional string name together with the Object Identifier (OID) Uniform Resource Name (URN). The optional XML attribute FriendlyName (defined in [SAMLCore]) MAY be used for this purpose, but is not translatable into an XACML attribute equivalent.This profile will utilize the namespace of urn:oasis:names:tc:xspa:1.0Example of use:
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:xspa:1.0:organization"> <saml:AttributeValue xsi:type="http://www.w3.org/2001/XMLSchema#string"> County Hospital </saml:AttributeValue>
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 22 of 31
</saml:Attribute>
[7.20.1] NameName is the name of the user as required by Health Insurance Portability and Accountability Act (HIPAA) Privacy Disclosure Accounting. The name will be typed as a string and in plain text with an identifying tag of <urn:oasis:names:tc:xspa:1.0:subject:subject-id>.
[7.20.2] National Provider Identifier (NPI) – (optional)NPI is a US Government issued unique provider identifier required for all Health Insurance Portability and Accountability Act (HIPAA) Privacy Disclosure Accounting transactions. NPI will be typed as a string in plain text with an identifying element of <urn:oasis:names:tc:xspa:1.0:subject:npi>.
[7.20.3] OrganizationOrganization is the organization that the user belongs to as required by HIPAA Privacy Disclosure Accounting. Organization will be typed as a string in plain text with an identifying element of <urn:oasis:names:tc:xspa:1.0:subject:organization>.
[7.20.4] Organization-IDOrganization-ID is the unique identifier of the consuming organization and/or facility. <urn:oasis:names:tc:xspa:1.0:subject:organization-id>.
[7.20.5] Organizational-HierarchyUnique identifier of the consuming sub-organization or region. If there are additional levels of sub-organizations, they shall be represented as multiple values in order of the most significant organization to the least. <urn:oasis:names:tc:xspa:2.0:subject:organizational-hierarchy>
<saml:AttributeStatement id="urn:oasis:names:tc:xpsa:2.0:subject:organizational-hierarchy"…> <saml:Attribute …> <saml:AttributeValue>urn:kp:region:colorado</saml:AttributeValue> <saml:AttributeValue>urn:kp:region:elpaso</saml:AttributeValue> <saml:AttributeValue>Penrose Hospital</saml:AttributeValue> </saml:Attribute></saml:AttributeStatement>
Another example would be how NwHIN describes Organization and Facility. Organization is defined by HomeCommunity, and represented by OID, Kaiser maybe represented by 1.1.1.1, and one of its facilities, example of facility #2, would be represented as the assigning authority, it oid would be 1.1.1.1.2.
[7.20.6] Structural RoleStructural Role is the value of the principal’s structural role. Structural roles that are used in this profile are defined in Table 2 “Healthcare Personnel that Warrant Differing Levels of Access Control” of ASTM 1986-98 (2005) Standard Guide for Information Access Privileges to Health Information. ASTM E1986
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 23 of 31
Structural roles are described in greater depth in ASTM E2595-07, Standard Guide for Privilege Management Infrastructure.Structural roles provide authorizations on objects at a global level without regard to internal details. Examples include authorization to participate in a session, authorization to connect to a database, authorization to participate in an order workflow, or connection to a protected uniform resource locator (URL). The structural role is the role name referenced by the patient’s consent directive.
[7.20.7] Functional Role (optional)Functional role can include custom attributes related to application functionality agreed upon by the parties in an exchange.
[7.20.8] Permission (optional)Permission is not required by this profile. Permission is determined by the action on the target. See “Action” below. The permission is the ANSI INCITS (International Committee for Information Technology Standards) RBAC compliant action-object pair representing the authorization required for access by the protected resource.
[7.20.9] ActionThe HL7 (Health Level Seven) RBAC Permission catalog is an ANSI INCITS 359-2004 RBAC compliant vocabulary that provides a minimal permission subset for interoperability. This profile specifies the use of the following HL7 RBAC Permission Catalog Actions: Append Create Delete Read Update Execute
[7.20.10] Execute (optional)Execute refers to complex functions and stored procedures that provide for extended actions within the healthcare environment. Examples include "print", "suspend", and "sign". Execute can include custom attributes related to functionality agreed upon by the parties in an exchange.
[7.20.11] ObjectObjects are any system resource subject to access control. This profile specifies the use of HL7 RBAC Permission Catalog as the object vocabulary in an action-object permission pair. HL7 RBAC Permission Catalog provides the minimum set of interoperable objects suitable for the support of security and privacy access control decisions in this profile.
[7.20.12] Purpose of Use (POU)Purpose of use provides context to requests for information resources. Each purpose of use will be unique to a specific assertion, and will establish the context for other security and privacy attributes. For a given claim, all assertions must be bound to the same purpose of use. Purpose of use allows the service to consult its policies to determine if the user’s authorizations meet or exceed those needed for access control. Purpose of Use will be typed as string with an identifying element of <urn:oasis:names:tc:xspa:1.0:subject:purposeofuse>
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 24 of 31
An authoritative listing of values can be found at following URL for GeneralPurposeOfUse values represented by OID2.16.840.1.113883.1.11.20449;
http://wiki.hl7.org/index.php?title=HL7_Security_Document_Library
Figure 3 illustrates the general relationship between subject (user) and granted permissions to specific objects as a relationship to their POU. Roles in this relationship are placeholders for permissions. Permission defines the object-action relationship.
Figure 3: Determining Subject Permissions
[7.20.13] Patient AuthorizationThe URI shall be in the form of an opaque identifier that references the authoritative patient authorization. The mechanism for retrieving the authorization must be coordinated between the requesting organization and the servicing organization. The content of the authorization, and the protocol to retrieve the authorization is beyond the scope of this profile.e.x. urn:uuid{550e8400-e29b-41d4-a716-446655440000}
[7.20.14] Supported ObligationsSpecifies user Obligation related to use of Sensitive Health Information that the requesting organization agrees(promise) and is capable of enforcing.
Authoritative values for this attribute may be found at HL7 represented by OID 2.16.840.1.113883.1.11.20445. http://wiki.hl7.org/index.php?title=HL7_Security_Document_Library
[7.20.15] Supported Refrain PoliciesSpecifies Prohibitions on the use of Sensitive Health Information that the requesting organization agrees to (promises) and is capable of enforcing.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 25 of 31
Authoritative values for this attribute may be found at HL7 represented by OID 2.16.840.1.113883.1.11.20446.
http://wiki.hl7.org/index.php?title=HL7_Security_Document_Library
[7.20.16] ResourceThe object(s) for which access is requested must be identical to the object(s) for which the authorization assertions of this profile apply. A requested resource is not required to be a simple object but may instead be a process or workflow. This profile specifies the use of HL7 RBAC Permission Catalog as the resource vocabulary.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 26 of 31
[8] Conformance4.4[8.1] IntroductionThe XSPA profile of SAML addresses the following aspects of conformance:This profile describes a minimum vocabulary set that must be supported in order to claim conformance.An Implementation must conform at minimum to the SAML v2.0 specification. The following tables describes the Attribute naming syntax, restrictions, and acceptable values,
Table 1: Attribute Naming, Typing, and Acceptable Value Set
Identifier Type Valid Values
urn:oasis:names:tc:xacml:1.0:subject:subject-id String Is the name of the user as required by Health Insurance Portability and Accountability Act (HIPAA) Privacy Disclosure Accounting. The name will be typed as a string and in plain text.
urn:oasis:names:tc:xpsa:1.0:subject:organization anyURI Organization the requestor belongs to as required by Health Insurance Portability and Accountability Act (HIPAA)Privacy Disclosure Accounting.
urn:oasis:names:tc:xspa:1.0:subject:organization-id anyURI Unique identifier of the consuming organization and/or facility
urn:oasis:names:tc:xpsa:2.0:subject:organizational-hierarchy
anyURI Unique identifier of the consuming sub-organization or region. If there are additional levels of sub-organizations, they shall be represented as multiple values in order of the most significant organization to the least.
urn:oasis:names:tc:xspa:2.0:subject:permissions String HL7-PERM may be used here, but is not limited to just HL7 value sets.
urn:oasis:names:tc:xacml:2.0:subject:role String Structural Role refer to [ASTM E1986-98 (2005)] and its OID representation.
urn:oasis:names:tc:xspa:1.0:subject:purposeofuse anyURI For authoritative value refer to HL7 Privacy and Security Vocabulary.
urn:gov:hhs:fha:nhinc:service-type String NwHIN identifier that represents ws-address, PatientDiscovery, DocumentQuery, etc.
urn:oasis:names:tc:xacml:1.0:resource:resource-id String Unique identifier of the resource defined by and controlled by the servicing organization. In healthcare this is the patient unique identifier.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 27 of 31
Identifier Type Valid Values
urn:oasis:names:tc:xspa:2.0:resource: type String For minimum interoperability set of objects and supporting actions refer to [HL7-PERM] and their OID representations. Again we are not limited here by HL7-PERM so should not be calling out in attribute name. Type could be PatientDiscovery, DocumentQuery, etc., and is implementation unique.
urn:oasis:names:tc:xspa:1.0:environment:locality String Unique identifier of the servicing organization.
urn:oasis:names:tc:xspa:2.0:subject:npi String National Provider ID provided by U.S. Government for all active providers.
urn:oasis:names:tc:xspa:2.0:subject:patient:authorization
anyURI Link to patient authorization to request information from servicing organization.
urn:oasis:names:tc:xspa:2.0:subject:supported-obligation-policies
anyURI Listing of obligations that the requesting organization can capable and agrees (promise) to support. For authoritative value refer to HL7 Privacy and Security Vocabulary.
urn:oasis:names:tc:xspa:2.0:subject:supported-refrain-policies
anyURI Listing of refrain policies that the requesting organization is capable of and agrees(promise) to support. For authoritative value refer to HL7 Privacy and Security Vocabulary.
*Note: The OID for the HL7 Permission Catalog [HL7-PERM] is 2.16.840.1.113883.13.27. The OID for structural roles referenced in [ASTM E1986-98 (2005)] is 1.2.840.10065.1986.7
The mechanism used to identify the patent in a standardized way, e.g. resource:resource-id, is outside the scope of the profile. HL7 RBAC Permission Catalog [HL7-PERM] represents a conformant minimum interoperability set for object/action pairings.
4.5[8.2] Conformance TablesThe following section identifies portions of the profile that MUST be adhered to in order to claim conformance.Note: “M” is mandatory “O” is optional.AttributesThe implementation MUST use the attributes associated with the following identifiers in the way this profile has defined.
Table 1: Conformance Attributes
Identifiers
urn:oasis:names:tc:xacml:1.0:subject:subject-id M
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 28 of 31
Identifiers
Urn:oasis:names:tc:xspa:1.0:subject:organization M
urn:oasis:names:tc:xspa:2.0:subject:organizational-hierarchy O
urn:oasis:names:tc:xspa:1.0:subject:organization-id O
urn:oasis:names:tc:xspa:1.0:subject::permissions O
urn:oasis:names:tc:xacml:2.0:subject:role ASTM E1986-98 (2005) Structured Role Value
M
Urn:oasis:names:tc:xspa:1.0:subject:functional-role O
urn:oasis:names:tc:xspa:1.0:subject:purposeofuse M
urn:oasis:names:tc:xacml:1.0:resource:resource-id M
urn:oasis:names:tc:xacml:1.0:action:action-id O
urn:oasis:names:tc:xspa:1.0:resource::type M
urn:oasis:names:tc:xspa:1.0:environment:locality M
urn:oasis:names:tc:xspa:2.0:subject:npi O
urn:oasis:names:tc:xspa:2.0:subject:patient:authorization O
urn:oasis:names:tc:xspa:2.0:subject:supported:obligation-policies O
urn:oasis:names:tc:xspa:2.0:subject:supported:refrain-policies O
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 29 of 31
Appendix A. AcknowledgmentsThe following individuals have participated in the creation of this specification and are gratefully acknowledged:Participants:!!br0ken!!
[Participant Name, Affiliation | Individual Member][Participant Name, Affiliation | Individual Member]
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 30 of 31
Appendix B. Revision History
Revision Date Editor Changes Madesaml-xspa-2.0-wd01 11 Mar 2012 Duane DeCouteau Working Draft revisions 01
saml-xspa-2.0-wd02 6 April 2012 Duane DeCouteau Comments and Changes updated from April 6th TC
Meetings.saml-xspa-2.0-wd03 27 April 2012 Duane DeCouteau Comments and Changes updated from April 27th TC
Meetings
saml-xspa-2.0-wd04 23 May 2012 Duane DeCouteau
Update to organizational-heirarchy purpose of use vocabulary, supported-obligation-policies, supported-refrain-policies
saml-xspa-2.0-wd04 19 July 2013 Mohammad Jafari Updating the template.
Minor editorial corrections.
saml-xspa-v2.0-wd01wd04 Working Draft 01 17 27 July February 20132014Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 31 of 31