XACML Obligations Profile-Update Proposal October, 2012
Department of Veterans Affairs
Veterans Health Administration
Office of Informatics and Analytics
eXtensible Access Control Markup Language (XACML)
Obligations Profile for Healthcare
Proposal
Version 0.4
October, 2012
iii
XACML Obligations Profile-Update Proposal October, 2012
Revision History
Date / Version / Reason for Changes / Author9/28/2012 / 0.1 / First Draft (based on the preliminary documents and Mike Davis’s comments) / Mohammad Jafari (ESC)
10/3/2012 / 0.2 / Second Draft (Duane’s comments) / “
10/9/2012 / 0.3 / Third Draft, Added the Project Plan / “
10/31/2012 / 0.4 / Minor edits. / “
CONTENTS
PARAGRAPH PAGE
1. Introduction 1
2. Related OASIS Documents 2
3. Application Context 3
4. Recommended Updates 4
5. Project Plan 5
5.1. Milestones 5
5.2. Estimated Plan 5
Appendix: Examples of Proposed Updates 7
1. Standard Obligation Identifiers 8
1.1. Binding Policies 8
2. Obligation Attributes 10
2.1. Obligation Type 10
2.2. Obligation’s Assignee 11
2.3. Constraints 12
2.4. Execution Order w.r.t the Action 12
2.5. Execution Order w.r.t the Other Obligation 13
2.6. Obligation-Specific Attributes 14
3. Combining Algorithms 15
3.1. Combining Mode 15
3.2. Relations among Obligations 16
3.2.1. Conflict Resolution 16
3.2.2. Inclusion 17
3.3. Policy-Specific Obligation Families 17
3.4. Policy-Specific Set of Valid Obligation 18
4. References 19
FIGURES
Figure 1. An example of generalized access control with multiple parties and multiple PEPs involved. The arrows show the direction of access requests. 3
Figure 2. XSPA TC Review Process 5
Figure 3 - Plan Milestones 6
TABLES
No table of figures entries found.
iii
XACML Obligation Update Proposal October, 2012
1. Introduction
The purpose of this document is to propose a project for developing an XSPA Obligation Profile for XACML.
The related OASIS documents are listed in Section 2, the application context is briefly explained in Section 3, and Section 4 explains the list of updates that will be proposed. Section 5 provides an overview of the milestone and an estimated project plan.
The appendices provide examples of the proposed updates and point out the current gaps in expressing and handling obligations and how they can be fixed. The initial draft for the profile will be based on these sections. More background on this can be found in the introductory document, On Obligations and XACML, an Edmond Scientific Internal Report [ESC-OBL].
Note that the purpose of the current document is to mention the issues that need to be addressed and provide examples for motivational purposes. The complete document will be provided in the course of project in the form of a working draft.
2. Related OASIS Documents
The related OASIS documents to this report are:
[XACML-2] / OASIS, eXtensible Access Control Markup Language (XACML) Version 2.0, OASIS Standard (Feb 2005)http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
[XACML-3] / eXtensible Access Control Markup Language (XACML) Version 3.0, Committee Specification 01, (August 2010)
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
[XACML-XSPA] / Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of XACML v2.0 for Healthcare Version 1.0 (November 2009)
http://docs.oasis-open.org/xacml/xspa/v1.0/xacml-xspa-1.0-os.html
[XACML-OBL] / XACML v3.0 Obligation Families Version 1.0, Working Draft 3 (December 2007)
https://www.oasis-open.org/committees/download.php/27230/xacml-3.0-obligation-v1-wd-03.zip
3. Application Context
The overall application context in this proposal is the medical record exchange. Figure 1 depicts an example of this scenario with multiple parties involved. The medical records residing at the Provider System are accessed by a Third-Party Storage system where they are made available to access by a Consumer System, and in turn, by an end user such as a physician belonging to the Consumer System’s domain. Each of the systems involved in this record exchange has its own PDP and PEP and needs to process and enforce access control policies.
Figure 1. An example of generalized access control with multiple parties and multiple PEPs involved. The arrows show the direction of access requests.
4. Recommended Updates
This proposal motivates developing a profile for XACML healthcare obligations. This includes:
· A vocabulary of standard Obligation Identifiers which extends what has been previously defined in XSPA v1.0 [XACML-XSPA].
· A set of standard Obligation Attributes including the Attribute Identifiers and legitimate Attribute Values that define the properties of obligations.
· A set of standard Rule- and Policy-Combining Algorithms that define the behavior of the PDP when multiple obligations correspond to a request. This includes mechanisms to define semantic relations among obligations that can be used to meaningfully combine obligations.
5. Project Plan
5.1. Milestones
The milestones for the project are as follows. These are based on the “OASIS Policies and Guidelines”[1]:
· Working Draft which follows the acceptance of this proposal and after preparing the first draft.
· Committee Draft requires approval of the Technical Committee, possibly after a number of iterations.
· Committee Specification requires the following steps:
o A 30-day public review plus a number of possible additional 15-day cycles depending on the number of revisions.
o Special Majority Vote.
· OASIS Standard requires the following steps:
o Submission of three written Statements of Use declaring that a party which may or may not be an OASIS member has successfully used or implemented the specifications. At least one of these statements must be by an OASIS member.
o Acceptance of the Statements of Use by the committee.
o Special Majority Vote to Submit the Committee Specifications as a Candidate Standard.
o A 60-day public review process.
o Membership-wide ballot.
5.2. Estimated Plan
Since after acceptance of the Committee Specifications the progress of the project will highly depend on the OASIS processes, we only provide an estimated timeline up to the point of acceptance of the document as the Committee Specification.
The estimated time from starting the project until approval of the Committee Specification is 12 weeks (3 months) which will begin after approval of this proposal. The break-down and more detailed time-estimates are shown in Figure 2. There is an uncertainty factor of 25% for the time estimate so the actual time for might be up to 15 weeks.
W.1 / W.2 / W.3 / W.4 / W.5 / W.6 / W.7 / W.8 / W.9 / W.10 / W.11 / W.12Initial Working Draft
Internal Review
Government PM review
Final Submission of the Committee Draft
Review and Comments by TC
Final Submission Approval of the Committee Draft
Figure 2. Time-line of the project.
Appendix: Examples of Proposed Updates
1. Standard Obligation Identifiers
A set of standard obligation identifiers will be produced to cover the common use-cases in the context of exchanging medical records. The following XACML excerpt depicts the definition of an obligation; a vocabulary for the highlighted part will be delivered as a result of this project.
<Obligation ObligationId="obligation-id" FulfillOn="…">…
</Obligation >
The following are some of the data-segmentation-related obligations with their informal semantics, based on HL7’s work-in-progress [HL7-HCS-VOCAB]. The prefix
urn:oasis:names:tc:xspa:1.0:obligation:
is assumed to precede both attribute identifiers and values:
Obligation Identifierhl7:anonymize / Requires removing any information that may result in identification of the information subject.
hl7:audit-trail / Requires keeping a log of the access events.
hl7:delete-after-use / Requires deleting the data after conclusion of the care process.
hl7:human-approval / Requires obtaining a human approval before granting access.
hl7:redact / Requires removing certain parts of the resource requested before allowing access.
hl7:encrypt-at-rest / Requires encrypting data while in storage.
hl7:encrypt-in-transit / Requires encrypting data while in transit.
hl7:mask / Requires encrypting data with a shared key that is only provided to the end user.
hl7:no-redisclosure / Prohibits re-disclosing to third parties.
1.1. Binding Policies
Problem:
There are cases where data needs to be accompanied with an obligation to enforce a certain policy. The policy can be explicitly mentioned as an XACML Policy or PolicySet element, or it can come in the form of a URL pointing to the location where the latest version of the policy can be retrieved.
Example:
HL7’s developing vocabulary includes a number of obligations of this type [HL7-HCS-VOCAB], including:
· Comply with patient consent directive
· Comply with jurisdictional privacy policy
· Comply with organizational privacy policy
Solution:
The following are some examples for the attributes to be used for this case. The prefix
urn:oasis:names:tc:xspa:1.0:obligation:
is assumed to precede the attribute identifier:
Attr. Identifier / Attr. Valueenforce-policy / XACML Policy or PolicySet element. / An obligation to enforce an explicitly mentioned policy.
enforce- policy-at / URL of the policy to be enforced. / An obligation to enforce a policy pointed to as a URL.
The fetching and processing of a linked policy provides a mechanism for ensure the latest version of the policy is followed. The following attributes are some examples to control over this process. The prefix
urn:oasis:names:tc:xspa:1.0:obligation:
is assumed to precede the attribute identifiers:
Attr. Identifier / Attr. Valueenforce-policy-at:caching / enforce-policy-link-caching :no-cache / Does not allow caching the policy and requires fetching the latest version from the URL every time the policy is to be processed.
Duration / Allows the PDP to use a cached version of the mentioned policy if it is not older than the duration mentioned.
enforce-policy:expires-on / Date and time / Directs the PDP to seek an updated version of the policy after a certain date and time.
2. Obligation Attributes
This section discusses the attributes required in expressing obligation policies. The following XACML code shows an example of attribute-assignment for obligation. The highlighted parts including the attribute identifier, its data type and its possible values will be defined by the output of this project:
<Obligation ObligationId="obligation-id" FulfillOn="…"><AttributeAssignment AttributeId="attribute-id" DataType="data-type">
Attribute-value
</AttributeAssignment>
</Obligation >
An alternative approach for some of the important attributes such as the obligation type is to add them directly to the XACML schema, alongside the FulfillOn attribute as shown in the example below. This will make the policy more concise although it might be less desirable to modify the XACML schema:
<Obligation ObligationId="obligation-id" FulfillOn="…" Type="…">…
</Obligation >
2.1. Obligation Type
Problem:
The semantics of an obligation may be positive, i.e. requiring some action to be performed by the obligation’s assignee, or negative, i.e. requiring the assignee to refrain from certain actions. A negative obligation is referred to as a refrain [HL7-HCS-VOCAB, Irwin-2006].
Example:
Considering the list of sample obligations in Section 4, an example of a positive obligation is hl7:encrypt-at-rest, whereas hl7:no-redisclosure is an example of a refrain.
Solution:
The following are some examples for the attributes to be used for this case. The prefix
urn:oasis:names:tc:xspa:1.0:obligation:
is assumed to precede both attribute identifiers and values:
Attr. Identifier / Attr. Valuetype / obligation-type:obligation / A positive obligation requiring an action.
obligation-type:refrain / A negative obligation prohibiting an action.
2.2. Obligation’s Assignee
Problem:
The assignee of an obligation is the entity that is required to comply with the obligation. In the scenario depicted in Figure 1, there are various entities that can be the assignee of an obligation; local PEPs, remote PEPs and the end user are some examples.
Example:
Considering the list of sample obligations in Section 4, an example of a local PEP obligation is hl7:redact to remove certain fields before enabling access.
An example for an all-PEP obligation is hl7:audit-trail to require all PEPs to keep a log of data use.
An example for negative subject obligation is to prohibit the end user from printing any part of the information in hard copy.
Examples of positive subject obligation are various workflow obligations that a user is bound to while accessing data in the course of a workflow. For example, when a user in an administrative role requests to read a patient’s prescribed medication for the purpose of healthcare payment, an obligation may be issued for the user to follow up with other activities required in the payment process such as issuing a payment bill and sending it to the patient or the insurance company. These obligations are implied by the purpose of use and ensure that the user remains committed to the purpose claimed.
Solution:
The following are some examples for the attributes to be used for this case. The prefix
urn:oasis:names:tc:xspa:1.0:obligation:
is assumed to precede both attribute identifiers and values:
Attr. Identifier / Attr. Valueassignee-type / obligation- assignee:local-pep / The obligation is assigned to the local PEP.
obligation- assignee:remote-pep / The obligation is assigned to a remote PEP; the identifier should be included using a assignee-id attribute.
obligation- assignee:subject / The obligation is assigned to a subject; the identifier should be included using a assignee-id attribute.
obligation- assignee:all-pep / All of the PEPs handling the data should execute the obligation. This requires the PEP to re-distribute the obligation.
obligation- assignee:any-subject / Any end user accessing the data should execute the obligation.
A assignee’s identifier can be specified if the obligation is charged to a specific PEP or subject. The following shows how this can be provided. The prefix
urn:oasis:names:tc:xspa:1.0:obligation:
is assumed to precede the attribute identifier. The attribute value can be either a static value, or a dynamic value produced by AttributeSelector or any of the different AttributeDesignators:
Attr. Identifier / Attr. Valueassignee-id / The identifier of the assignee of the obligation.
2.3. Constraints
Problem:
Constraints specify some restrictions on the way the obligation must be executed. Aside from committing to the obligation, the assignee must additionally commit to the obligation constraints.
Example:
The most typical of a constraint is time and location constraints. For example, an obligation for a subject to submit a report may have a deadline.
Solution:
The following are some examples for the attributes to be used for this case. The prefix
urn:oasis:names:tc:xspa:1.0:obligation:
is assumed to precede the attribute identifier. The attribute value can be either a static value, or a dynamic value produced by AttributeSelector or any of the different AttributeDesignators:
Attr. Identifier / Attr. Valueabsolute-deadline / Time and date / An absolute deadline by which the obligation should be performed, e.g. September 12, 2012, 12:30.
relative-deadline / Duration / A relative deadline is defined by a time period after the the action is performed, e.g. within 1 week after access.
time-interval / A repetitive time interval / A periodic time interval constraint, e.g. between 8am and 4pm.
location / A location code / A location constraint on where the obligation must be executed, e.g. within the premises of the clinic.
A vocabulary for environment attributes (if exists) can be re-used in this case to avoid redefining the vocabulary.