• IssuesList

Issues List

Below are the current issues for the XACML TC

Closed issues have been moved here: ClosedIssues

The status of each item is indicated with the following options:

OPEN No agreement on resolution.
PENDING Resolution has been reached, but is not reflected in the latest draft.
PENDING REVIEW Latest draft has been recently been updated to reflect resolution.
CLOSED Issue resolution is reflected in current draft or issue was dropped.
DEFERRED Issue is inactive but will be considered at a specific future time.

The target of the issue is indicated in the title as follows:

ADMIN Administrative Policy Profile (including administrative policy topics that affect 3.0 Core)
CORE XACML 3.0 Core
ERRATA XACML 2.0 Core errata
PROVISIONING Policy provisioning
SAML SAML 2.0 profile of XACML Version 2
WS-XACML Web Services Profile of XACML (WS-XACML)

12. CORE:More general conclusions

It has been proposed that the XACML language should be generalized to allow more complex decisions than yes/no. This could for instance mean that a rule which specifies encrypted access would override or be overridden by a rule which specifies unencrypted access, according to rules specified in the policy. There has also been discussion about imperative sequences as conclusions. Backwards compatibility with obligations is also an issue in this context.

The outstanding Use Cases are being addressed via modification of the current Obligation mechanism. http://wiki.oasis-open.org/xacml/DiscussionOnObligations

Erik and Bill are working on a proposal as of 10 May 2007.

Status: OPEN

Champion: Bill

36. PDP metadata

Should PDP metadata be made available in some form? Currently the following meta data has been identified: Attribute timing. Top level combining algorithm.

Action: Bill to provide a proposal (pending the outcome of #12).

A "placeholder" list has been created http://wiki.oasis-open.org/xacml/MetaData#preview to capture potential meta data of interest.

Status: OPEN

Champion: Bill

62. PROVISIONING:Policy provisioning interface

We have agreed (Issue#39) that the SAML Profile XACMLPolicyQuery will not attempt to provide a robust policy provisioning interface. The alternative proposal is that a separate policy provision interface be provided, possibly using SPML. Do we want such an interface?

Proposal outline at http://lists.oasis-open.org/archives/xacml/200702/msg00061.html. Discussion from March 2007 F2F in Minutes at end of first day at http://lists.oasis-open.org/archives/xacml/200703/msg00069.html

XACML Policy Distribution

Assumptions

There is a Policy Administration Point (PAP) which holds all the policies for some domain. There are a number of Policy Decision Points (PDP) which retain in some local (typically non-volatile) storage all the policies it considers to make decisions. Different PDPs may use different subsets of the policies held by the PAP. A PAP will typically serve a number of PDPs. Conceivably a PDP may get its policies from several PAPs, however I am not aware of a motive for this usecase.

This protocol is concerned only with the interaction between one PDP and one PAP. It is assumed that the PAP knows what policies a given PDP should get by some unspecified means. In a real deployment, this could be done in a number of ways. For example:

1. The UI which allows admins to creates policies also provides a mechanism which allows the admin to specify what PDPs should get what polices. This could be done individually or by grouping PDPs in some way.

2. The admin could be allowed to define some templates to apply to targets in policies in order to determine which PDPs get them. For example, each PDP might handle decisions with resource names that contained certain dns names. Say PDP1 gets policies pertaining to *.factory.example.com and PDP2 gets policies pertaining to *.marketing.example.com.

3. Policy identifiers could be chosen to indicate something about which PDP gets a given policy.

It is assumed that each PDP has a unique identifier which the PAP knows in advance.

The protocol should make it easy to recover from failures of either participant or the communications link. Also in most cases work done prior to a failure should not have to be repeated. The protocol should make it possible for the PDP to determine that it has a complete and consistent set of policies.

All XACML Policies and Policy Sets contain an identifier. Different policies can contain the same identifier, but they will have different versions. The combination of Policy Identifier and version is assumed to be unique. For the purposes of this discussion the Id & vrsion pair are called a Policy Id.

Two different protocols are defined, a push protocol (controlled by the PAP) and a pull protocol (controlled by the PDP). Both protocols have different advantages and disadvantages. It is expected that each will be used in different environments.

• New feature: 10/10/2007

I forgot I had intended to provide support for an effective date/time for a set of policies. The idea is that a set of policies can be marked as taking effect at a future date time such as at midnight. The policies can be distributed in advance and the PDP will continue to us the current set of policies until the effective date/time arrives. A set of polices with no effective date/time would default to go into effect immediately.

For the Push Protocol, this simply requires adding an effective date/time element to the batch.

For the Pull protocol, an effective date/time can be added to the policy list response from the PAP. However, the use of this feature depends of the PDP initiating the protocol in time to get the set of policies before the effective date/time.

I have made the changes below to add this feature.

• Push Protocol

1 Req. (Optional) PDP -> PAP request policy update.

This message will be useful in cases such as a PDP first starting up.

2. PAP -> PDP request current policy list

This can be sent in response to an update request or as an unsolicited message. A PAP might initiate the request because an Administrator has updated the policies.

2. PDP -> PAP response with list of Policy Ids currently held by the PDP. Optionally the PDP can specify a maximum message size for policy updates.

PAP compares the policies held with the list of policies the PDP should hold.

3. PAP -> PDP Policy update batch.

The batch may begin with an optional effective date/time for the set of policies in the batch.

The batch contains two kinds of items:

A. Delete policy – specifies the Policy Id of a Policy to delete B. Add policy – contains Policy or Policy Set to add

(Batch mechanism TBD. Could use SPML batch function or WS-RM sequence.)

Each message in batch should be acknowledged. PDP should implement atomic update. No action should be taken until complete batch is received. Once batch is complete, the effective date/time should be checked. If it is missing or in the past, the update should be done immediately. Otherwise the update should be delayed until the effective date/time is reached.

In either case, when the update is performed, policy evaluation should cease. All deletes and adds should be applied. Then evaluation should resume.

Pull Protocol

1. PDP -> PAP Request current policy list 1. PAP -> PDP response – optional effective date/time and list of current policy ids for that PDP

PDP compares list with policies currently held. Policies to be deleted are noted.

2. PDP -> PAP Policy request – list of Policy Ids of policies to be returned 2. PAP -> PDP Policy response – Returns Policies and Policy Sets.

PAP is allowed to send subset of Policies requested. If a requested policy does not exist, an error must be returned identify the Policy in question. In this case, the PDP should go back to sending a request for the current policy list.

PDP continues sending policy requests until all needed policies have been received. Then the effective date/time should be checked. If it is missing or in the past, the update should be done immediately. Otherwise the update should be delayed until the effective date/time is reached.

In either case, when the update is performed, the PDP stops evaluation, atomically adds new policies and deletes obsolete ones, then resumes policy evaluation.

Status: OPEN

CHAMPION: Hal

66. Missing attributes may be underspecified

I did a somewhat detailed analysis of "Example two" in the core spec from the point of view of understanding how fine grained authorization (fga) (applying resource attrs to az decision) was implemented and came across a number of items that I think need to be addressed especially in potential interoperability situations. I will put all in one issue initially, we can decide if it needs to be broken out later.

1. line 1090-91 describing ResourceContent. In both the core spec and the sample messages, the ResourceContent contains the following:

• <ResourceContent>

  • <md:record xmlns:md="urn:med:example:schemas:record"

    • xsi:schemaLocation="urn:med:example:schemas:record

      http:www.med.example.com/schemas/record.xsd">

    • <md:patient>

      • <md:patientDoB>1992-03-21</md:patientDoB> <md:patient-number>555555</md:patient-number>

      </md:patient>

    </md:record>

  </ResourceContent> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="xs:string">

  • <AttributeValue>

    • //med.example.com/records/bart-simpson.xml#

      xmlns(md=http:www.med.example.com/schemas/record.xsd) xpointer(/md:record/md:patient/md:patientDoB)

    </AttributeValue>

  </Attribute>

While I recognize that the example itself is not intended to be perfect, it provides a convenient context for raising the following questions/issues, especially wrt fga.

1. If this is a first request from a PEP, why is the PEP supplying patient-number on line 1056? This looks like a required attr to evaluate Rule 1 (line 1141), if the requestor is the patient, but this example the requestor is the physician.
   • The physician-id is supplied in the request (line 1044), but the only rule it appears in is rule 3 (line 1522). This rule only allows "write" access (line 1507), so I expect this request would probably fail as it is currently set up. i.e. we would need to add a "read" action to rule 3 or add a physician-id test to rule 1.
   b. Assuming the above request fails, let's consider what might be done. There was a "read" request issued (line 1072), so that would mean that rule 1 (line 1182), rule 2 (line 1347), or rule 4 (line 1668) could be applied.

Rule 1 requires a Subject attribute patient-number (line 1134) to match the patient-number in the requested resource record (line 1141). Presumably a <MissingAttributeDetail> could be returned, somehow identifying these 2 attributes to the PEP.

Rule 2 requires a patientDoB resource attr (line 1297), a parent-guardian-id subject attr (line 1363), and a parentGuardianId resource attr (line 1371). Similarly a <MissingAttributeDetail> could be returned requesting these.

• Assuming this to be the case, one question I have is how does the

  <MissingAttributesDetail> tell the PEP whether the attributes that are missing should be resubmitted as part of the Subject or as part of the Resource? This info is provided in the Request from the xml structure, however, the <MissingAttributeDetail> does not have equivalent structure to make such distinctions.

The above is intended just to give an example of questions that occur for this particular example, but it is my opinion that it is symptomatic of a general problem of how PEPs are supposed to know how to construct the proper RequestContext necessary, in general, for complex scenarios that require substantive fga attrs.

In these more complex fga scenarios it is likely that <MissingAttributeDetail> will be typically needed to collect all the required attributes. Therefore, I believe some more robust mechanisms, possibly using MissingAttributeDetail as a good starting point will be needed to adequately define operation in this area.

In this context as well, it is likely that xpaths are probably not the way to go since they are only applicable to certain types of resources (xml-based) and those resource structures are likely to change in time, and these changes should not percolate into the enterprise Policy arena. Therefore, mechanisms such as vocabularies should be recommended usage here with the PEP being responsible for mapping the vocabulary item to the particular resource physical access path such as the xpath.

Status: OPEN

CHAMPION: Rich

75. Defining an interface for closely coupled PEP/PDP

Status: OPEN

At the TC meeting on 11th Sept 2008 it was decided that this issue is best addressed by a separate profile, and that this issue is not on the critical path to 3.0.

CHAMPIONS: Rich and Prateek

82. PRIVACY: error in FunctionId

The name of the function referred in the condition of the matching purpose rule is wrong. Instead of being "urn:oasis:names:tc:xacml:2.0:function:regexp-string-match" it's "urn:oasis:names:tc:xacml:2.0:function:string-regexp-match".

Reported on xacml-comment by Alejandro Cartas

WD 3 of privacy 3.0 contains a fix for this. No errata for 2.0 exists yet.

Status: OPEN

Champion: ?