[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Re: How to get attributes from other categories
Hi Rich, On 11/08/2013 5:19 PM, rich levinson wrote:
Hi Steven,
Again, I will reply to your detailed questions later, however, I'd like
to keep the focus on addressing what I consider to be the real issue
here which is that I would prefer not to introduce loops and variables
to the core language, at least not in the form you have proposed.
Your point about the analogy to the bag functions is well taken,
and I agree the bag functions have implicit iterators and loops,
but from my perspective, that is the way XACML, early on, chose
to address this problem (long before I was associated w the TC).
In my prev email I considered trying to do something w bag fcns
to addr the issue, but it was not immediately obvious to me
what the strategy should be.
Your analogy was very helpful in this regard, where you demonstrated
the equivalence of the <ForAny> construct to the implicit operation
of the bag functions that effectively under the covers need to
create a loop of some sort and iterate thru a variable that uses
one value from the bag for each time thru the loop.
So, what I am thinking is maybe the reverse logic can show us
some possiblities: i.e. take the ForAny construct that you
have proposed and consider what it might look like as a
bag function.
What I have empirically come up with is the following:
<Apply FunctionId="all-of-any-category">
<Function FunctionId="boolean-and">
<AttributeDesignator // bag of categoryId's
Category="access-subject"
AttributeId="organization"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="string-bag"> // bag of attrId's
<AttributeValue DataType="string">organization-us</AttributeValue>
<AttributeValue DataType="string">organization-np</AttributeValue>
</Apply>
<AttributeValue DataType="boolean">true</AttributeValue>
</Apply>
The above is basically a new bag function that takes 4 arguments:
* a FunctionId to be applied to two operands
* a bag of categoryIds
* a bag of attributeIds
* a bag of values, in this case just one value: true
The "new" aspect to this function would be: using the pair of
arguments (bag of categoryIds, bag of attributeIds) in the
following manner:
for each categoryId
return a bag of AttributeDesignators where there is
one designator for each AttributeId such that the
designator addresses the Attribute in the specific
category
therefore we'd end up w a nested loop w the outer
loop being category and the inner loop being the
attr-id's within the category.
By my count this is your fourth proposal. Are the other ones still on the table ?
Because the addressing has changed in 3.0, where we now have a general Category variable (the xml Category attribute in the designators and selectors) from the situation in 2.0, where the Category was essentially fixed by the name of the selector or designator element (i.e. the prefixes, Subject, Action,...) that has kind of left us with some loose ends such as the bag functions that don't really have any way to handle the notion of collection of collections, which is essentially what the pair: Category,AttributeId gives us. i.e. a policy element must now know 2 things to locate an attribute in the request, the collection it is in and the attributeId within the collection, whereas, before, because of the constructs, all that was needed was the AttributeId. So, imo, it might be worth generalizing some sort of construct that can be used w the bag functions such as what I have suggested above, but maybe presented in a more simplified manner if one is available. Bottom line: the motivation for this proposal is again, to try to avoid introducing looping and iteration constructs to the policy language. Imo, the users of the language are not a bunch of programmers wishing they could just write the policy in Java, but more configuration and deployment people who would like to add a line or remove a line from a text configuration file in order to change policy. Right now it is fairly straight forward to put together a scripting equivalent to xacml which has this line at a time flavor to it and gets rid of the extraneous xml constructs, w a compression ratio of something like 5:1 i.e. 5 xacml lines can generally be compressed to about 1 script line.
Like ForAny($org, some-bag, some-expression-using-$org) ? The more verbose form would be: there exists $org in some-bag such that some-expression-using-$org
W the proposal above, a new bag construct could be introduced, which would handle a common function of a double iterator w outer loop category, and inner loop attrId, which wouldn't change the core spec at all, but simply add a new bag function or possibly a few new bag functions. Adding functions is considered fair game for xacml, preferably w some profile defined so that people know how to use the fcns. Let me know if this approach sounds at all promising.
It would take much more than one new bag function to provide reasonable
coverage. Your all-of-any-category function covers just one simple
pattern amongst a wide variety of useful patterns. Here are a couple of
examples that came up in the "Attributes of Relations" thread. Think
about the bag functions you would need to define to support these kinds
of expressions, and then think about all the reasonable possibilities
between these extreme cases and all-of-any-category.
<ForAny VariableId="$a">
<!-- $a is bound to each relationship-ref URI in turn -->
<AttributeDesignator
Category="access-subject"
AttributeId="relationship-ref"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="and">
<!-- Return true if and only if the subject-to-organization-relationship of
the relationship object referenced by $a contains the value "employee". -->
<Apply FunctionId="anyURI-is-in">
<AttributeValue DataType="anyURI">employee</AttributeValue>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$a"/>
<AttributeValue DataType="anyURI">subject-to-organization-relationship</AttributeValue>
<AttributeValue DataType="anyURI">anyURI</AttributeValue>
<AttributeValue DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
<!-- Return true if and only if the organization referenced by the relationship
object referenced by $a is the IP owner. -->
<Apply FunctionId="anyURI-at-least-one-member-of">
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$a"/>
<AttributeValue DataType="anyURI">organization-ref</AttributeValue>
<AttributeValue DataType="anyURI">anyURI</AttributeValue>
<AttributeValue DataType="boolean">false</AttributeValue>
</Apply>
<AttributeDesignator
Category="resource"
AttributeId="ip-owner"
DataType="anyURI"
MustBePresent="false"/>
</Apply>
<!-- Return true if this subject-to-organization-relationship,
i.e., $a, has the latest start-date. -->
<ForAll VariableId="$b">
<!-- $b is bound to each relationship-ref URI in turn -->
<AttributeDesignator
Category="access-subject"
AttributeId="relationship-ref"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="any-of-all>
<Function FunctionId="date-greater-than-or-equal"/>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$a"/>
<AttributeValue DataType="anyURI">start-date</AttributeValue>
<AttributeValue DataType="anyURI">date</AttributeValue>
<AttributeValue DataType="boolean">false</AttributeValue>
</Apply>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$b"/>
<AttributeValue DataType="anyURI">start-date</AttributeValue>
<AttributeValue DataType="anyURI">date</AttributeValue>
<AttributeValue DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
</ForAll>
</Apply>
</ForAny>
<ForAny VariableId="$contract">
<AttributeDesignator
Category="access-subject"
AttributeId="contract"
DataType="anyURI"
MustBePresent="false"/>
<Apply FunctionId="and">
<Apply FunctionId="string-is-in">
<Apply FunctionId="string-one-and-only">
<AttributeDesignator
Category="access-subject"
AttributeId="location"
DataType="string"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$contract"/>
<AttributeValue DataType="anyURI">allowed-location</AttributeValue>
<AttributeValue DataType="anyURI">string</AttributeValue>
<AttributeValue DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
<Apply FunctionId="anyURI-is-in">
<Apply FunctionId="anyURI-one-and-only">
<AttributeDesignator
Category="resource"
AttributeId="resource-id"
DataType="anyURI"
MustBePresent="false"/>
</Apply>
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$contract"/>
<AttributeValue DataType="anyURI">resource-id</AttributeValue>
<AttributeValue DataType="anyURI">anyURI</AttributeValue>
<AttributeValue DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
<Apply FunctionId="integer-less-than">
<Apply FunctionId="string-bag-size">
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$contract"/>
<AttributeValue DataType="anyURI">log_entry</AttributeValue>
<AttributeValue DataType="anyURI">string</AttributeValue>
<AttributeValue DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
<Apply FunctionId="integer-one-and-only">
<Apply FunctionId="attribute-designator">
<VariableReference VariableId="$contract"/>
<AttributeValue DataType="anyURI">use_limit</AttributeValue>
<AttributeValue DataType="anyURI">integer</AttributeValue>
<AttributeValue DataType="boolean">false</AttributeValue>
</Apply>
</Apply>
</Apply>
</Apply>
</ForAny>
Allowing for variations such as attributes of different data types, boolean
expressions other than flat conjunction and disjunction, normalization of
attribute values for comparison, associations of associations, comparisons
between entity attributes, comparisons between attributes of different
associated entities, and so on, makes for a large set of patterns and thus
a large number of specialized bag functions.
Now you could say that we only specify the few most important patterns, but
users will inevitably need to go beyond that, so we will be locked into an
endless cycle of function creep. Users will be left waiting for the TC to
define the functions they need and for their vendors to implement those
functions, if it happens at all. Interoperability between implementations
will also suffer as they won't all be up-to-date with the latest list of
bag functions.
After some years a reasonable collection of specialized bag functions may
result, but they will always be the poor second cousin to what the iterator
expressions can achieve in one stroke. The iterator expressions achieve
more with greater economy of specification, implementation and user
comprehension.
Regards,
Steven
Thanks, Rich a specific category and attribute On 8/9/2013 2:35 AM, Steven Legg wrote:Hi Rich, On 8/08/2013 7:09 PM, rich levinson wrote:Hi Steven, I am going to try to reset the discussion a bit, because I think that w the discussion we have had the priority of concerns has evolved. Therefore, I will re-present the use case, drawn, I believe, from your description a couple emails back. That is followed by a specific example request, which, again, I think we agree on the org cats, but I am proposing a new middle ground subject-access, that contains an attribute containing a list of cats that provides some explicit binding between the subject-access and the associated organizations. Finally, there is an example policy, again, derived from some of your suggestions in earlier emails, which effectively goes thru each enumerated org category looking for one meets the two condition reqt of being both np and us. That is followed by some comments. I had first started by responding to the individual comments you made last time, and can provide those if you are interested, however, I think if we can re-baseline the issue then core issues that are being discussed will be easier to identify. Here is a rough cut of a new proposal to be considered as an alternative your proposal, which is in the prev emails. The use case is a request that will be processed by a policy that will ask the question: "Is the user associated with an organization that is both non-profit (np) and based in US (us)?" It has been agreed that the request can contain a uniquely named category for each organization that the user is associated with, and in this case we are naming the categories: organization-1 organization-2 ... The maximum number of such categories is a subject of discussion, however, the xacml requirement appears to be that to differentiate the organizations within the request, each must have a unique category name. The example request contains two organizations, each in its own category. In addition, the subject has its usual subject-access category. Additional categories, such as resource and env are suppressed as being extraneous wrt relevance to the issued being considered. The following is a simple minimal request that contains a subject-access containing one attr that has a list of orgs the user is associated w, represented by their category names as they appear elsewhere in the request. <Request> <Attributes Category="subject-access"> <Attribute AttributeId="organization-categories"> organization-1 organization-2 </Attribute> </Attributes> <Attributes Category="organization-1"> <Attribute AttributeId="organization-np"> <AttributeValue DataType="boolean" >true</AttributeValue> </Attribute> </Attributes> <Attributes Category="organization-2"> <Attribute AttributeId="organization-np"> <AttributeValue DataType="boolean" >true</AttributeValue> </Attribute> <Attribute AttributeId="organization-us"> <AttributeValue DataType="boolean" >true</AttributeValue> </Attribute> </Attributes> </Request> In this case the user's associations are represented by a single multi-valued attribute, that contains a list of the orgs the user belongs to. The policy condition might be written as follows (which is slightly adapted from Steven's comment in prev email as to how to simplify the proposal I had prev made): The logic of the following is basically: // is org 1 OR org 2 both np and us? // is org 1 in list of cats AND buth np and us? // is org 1 in subject list of cats? // is org 1 both np and us? // is org 1 np? // is org 1 us? // is org 2 in list of cats AND buth np and us? // is org 2 in subject list of cats? // is org 2 both np and us? // is org 2 np? // is org 2 us? <Apply FunctionId="or"> // is org 1 OR org 2 both np and us? <Apply FunctionId="and"> // is org 1 in list of cats AND buth np and us? <Apply FunctionId="string-is-in" // is org 1 in subject list of cats? <AttributeValue DataType="string">organization-1</AttributeValue> <AttributeDesignator Category="subject-access" AttributeId="organization-categories" DataType="string" MustBePresent="false"/> </Apply> <Apply FunctionId="and"> // is org 1 both np and us? <Apply FunctionId="boolean-is-in"> // is org 1 np? <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-1" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> // is org 1 us? <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-1" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> </Apply> <Apply FunctionId="and"> // is org 2 in list of cats AND buth np and us? <Apply FunctionId="string-is-in" // is org 2 in subject list of cats? <AttributeValue DataType="string">organization-2</AttributeValue> <AttributeDesignator Category="subject-access" AttributeId="organization-categories" DataType="string" MustBePresent="false"/> </Apply> <Apply FunctionId="and"> // is org 2 both np and us? <Apply FunctionId="boolean-is-in"> // is org 2 np? <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-2" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> // is org 2 us? <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-2" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> </Apply> </Apply> In the above policy, the fact that the list of org categories is in the subject-access category serves to loosely, but explicitly bind the attrs in those cats to the subject. There are 2 alternatives to this that also seem to make a degress of sense: - there can be no list of cats in subject-access, in which case the binding is implicit - the subject-access could also include a list of specific attributes that it points to in the org categories The 3rd alternative is what is given above, where the explicit binding is at the category level, so the 3 possible structures are: - implicit binding of subject-access to org-cats in request - explicit cat binding as shown aboveI'm not clear on what the distinction between the two above cases actually is. The explicit category binding only appears necessary if the category identifiers are permanent identifiers for organization entities. For example, there may be 10 organizations with fixed identifiers "organization-1", "organization-2", ... "organization-10". Supposing that an access-subject can be associated with up to two organizations, the explicit organization categories for one access-subject could be "organization-1" and "organization-2", but for another access-subject they might be "organization-3" and "organization-7". I think the implicit binding is what I had in mind. If an access-subject can be associated with up to two organizations, then the URIs "organization-1" and "organization-2" are defined as aliases for the associated organizations and the bindings are valid only for the duration of the request context. Different requests for different access-subjects will possibly bind these URIs to different real-world organizations, i.e., the ones associated with that access-subject. An "organization-categories" attribute isn't required in the access-subject because we know they will be "organization-1" and "organization-2", if categories with those identifers exist at all on the request context. If I've got the distinction right, then the explicit category binding has even worse scaling characteristics than the implicit binding. If there are ten organizations and an access-subject can be associated with up to two of them, then the "or" expression for explicit category binding would need to have ten "and" terms, while the "or" expression for implicit binding would only need two "and" terms. The expressions must grow to accommodate the maximum number of organization associations in the implicit case, but must grow to accommodate the maximum number of organizations in the explicit case. The former will usually be much smaller than the latter, and never larger. The expressions must also be rewritten in the explicit case when the number of organizations increases.- explicit attr by attr binding from subj to specific org attrs It is the 3rd case that was the focal point of the prev emails, however, given the above 3 choices the particular points in those emails may be too detailed for highest priority aspects of this issue. Using this as a starting point it might be easier now to compare the two solutions which I would now characterize as: 1. dynamic category processing using dynamic variables and iteration loops 2. static category processing using enumerated list of explicit category identifiers. imo, the main issue is whether "2" can be set up to be "enough", which can be done relatively few tweaks or possibly using xacml, as is, as might be the case for implicit or cat binding above. Attr binding would require a few "tweaks", or whether "1" is reqlly what's required, which really changes the xacml policy language quite significantly w loops and variables.The difference is not as great as you think. XACML already has many functions that loop; the variables are just hidden in the function definitions. Take the boolean-is-in function as just one example. An expression like the following: <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-2" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> </Apply> has an equivalent form using a ForAny expression: <ForAny VariableId="$value"> <AttributeDesignator Category="organization-2" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> <Apply FunctionId="boolean-equal"> <AttributeValue DataType="boolean">true</AttributeValue> <VariableReference VariableId="$value"/> </Apply> </ForAny> All the functions that take a bag argument are looping, but the body of the loop is either fixed by definition, as in boolean-is-in, or is determined by a single function argument, as in the higher-order bag functions. By exposing the loop variable and the loop body in the ForAny expression I can make the body of the loop any arbitrarily complex expression. It's a superset of what's already there. Regards, StevenThanks, Rich On 8/2/2013 2:42 AM, Steven Legg wrote:Hi Rich, On 31/07/2013 5:39 PM, rich levinson wrote:Hi Steven, I have quickly gone thru your comments and prepared some replies, but have not had time to edit or ensure that all the bases are covered. I am providing just your comments and my replies to each, leaving the prev email contexts behind (or at least only in the trailing part of this email) in order to make the replies more readable, but if anyone is just jumping in now, then they should probably go back to the earlier emails to get the full context. In any event, in summary, I think your comments have advanced the discussion and clarified the use case a bit more, and I have adjusted my replies as seemed appropriate. I think, as you will see way down below, that if you agree w the logic I am using to describe this situation, that my proposal, does, in fact, address the use case you have presented, however, we would then still have some more issues to address, but let's see whether you agree w what I have said here first. Below, your comments abut the left margin, while all the indented stuff is my replies. Thanks, Rich I intended that there be another entity represented by an Attributes element and identified by the URI"http://foo.com";. This is a specific organization associated with the access subject, which is neither the access-subject nor the resource. I could have conjured up a new, predefined category called "organization", but this assumes that the access-subject can only be associated with one organization. The "Attributes of Relations" thread is, in part, about how to deal with multiple instances of the same kind of entity. In this case, association with more than one organization. If each such organization's Attributes element used the same CategoryId, then this would be interpreted as a request for multiple decisions, which we don't want. So to allow more than one organization entity in the request context, they each need to have a unique CategoryId, which is really an entity identifier in their case, but I don't have the luxury of changing the core schema so CategoryId has to do double duty. ok, but I would create a categoryId for each organization role, such as employer-organization, customer-organization, etc.It's not hard to imagine an access subject being a customer of more than one organization, or even being employed by more than one organization, so role-specific category identifiers might be enough in some cases, but don't offer a general solution.or if it were to be the case that there were mult orgs in the same role, then: org-1 org-2 etc. and could use regex type logic to parse and select root and index.From the policy perspective, category matching is always by URI equality, so I don't see where regexes would fit in.keeping in mind that the values provided in the request are "policy-driven" in the sense that the PEP and/or requesting entity needs to know what type of info needs to be provided in the request. That was what I intended. The CategoryId of that Attributes element being"http://foo.com";. ok, then we are probably talking about the same concept. My main point is establishing a mechanism to access attributes in other categories. I understand that the presence of the XPathCategory XML attribute changes the actual data-type, but it's ugly to have the value proclaim it is one type when it is really a different type. I also realize that you can't fix that without breaking something else. The basic "motivation" I had for coming up w this is that: recognizing that this capability existed for accessing "Content" elements and the Attributes contained therein, in other categories than the one containing the XPath expression, by using the XPathCategory to identify the other category, it seemed to me that this "unbalanced" the symmetry of navigation, and so considered what would be the minimum adjustment necessary to "undo the imbalance", which is what the proposal is. Also, I don't think it is any "uglier" than the XPathExpression DataType not representing the DataType of the attribute returned by the XPathExpression. However, by providing the DataType here, enables the AttributeDesignator logic to test the DataType consistently w all other attributes, and the presence of the XPathCategory also implies that the DataType of the referenced attribute must have the same DataType as that specified by the AttributeValue in the referencing Attribute. Well that's kind of my point. The AttributeDesignator says get the organization attribute from the access-subject, but the values that are returned are actually from the non-profit-organization attribute in a different category. Or they might actually be from a boolean organization attribute in the access-subject because the values didn't carry the XPathCategory XML attribute. Or they might be from some other attribute entirely because the PEP or PIP put in something other than what you intended. We can't look at an AttributeDesignator and be certain where the values it fetches will be coming from. Control has passed from the policy writer to the PEP and PIP. Hmmm, I think I see your point, although I would like to say that this is the same case as the AttributeSelector.It's the same case as an AttributeSelector with a ContextSelectorId, but a policy writer can choose not to use the ContextSelectorId. The ContextSelectorId seems to be there to support requests for multiple decisions involving XML documents, so perhaps it wasn't intended to be used as a general redirection mechanism. Someone who's been in the TC longer than me might recall the rationale.However, as I read the AttributeSelector more carefully, it seems to contradict itself, by first saying about AttributeSelector@Category: "This attribute SHALL specify the attributes category of the <Content> element containing the XML from which nodes will be selected." Ok, this sounds like the Category that contains the Content that will be accessed by the XPathExpression, as opposed to any other Category that might contain the Attribute that contains the XPathExpression.I assume this first statement is referring to the Path XML Attribute, which isn't an XACML attribute, or in one, and so doesn't come with an implied category.But, it then goes on to say: "It also indicates the attributes category containing the applicable ContextSelectorId attribute, if the element includes a ContextSelectorId xml attribute. This would seem to say that both the Content and the Attribute identified by the AttributeId in the ContextSelectorId xml attribute must be in the same Category.I agree with your conclusion.It then goes on to say about the ContextSelectorId xml attr: "The XPathCategory attribute of the referenced attribute MUST be equal to the Category attribute of the attribute selector." This seems to go full circle, rendering the XPathCategory xml attribute as being redundant and unnecessary,It is redundant, but you have neglected to consider the XPath-based functions, which take xPathExpression values as arguments. There is no current category in the evaluation context of an XACML function, so it has to be specified somehow. The XPathCategory XML Attribute on the xPathExpression value is the mechanism to do that. My guess is that the ContextSelectorId XML attribute references an attribute with a value of the xPathExpression data-type because it was more convenient to use an existing data-type than to invent a new data-type that doesn't have the redundant XPathCategory. > sinceeverything has to be in the same Category. It's like saying an Attribute needs to have a Category xml attr specifying the Category-Id of the Category it is in. But the only reason it can say this about itself is that it is in an Attributes element with that Category, and since this is already specified in the parent, why specify it again in the child? However, if we look at the defn of XPathExpression beginning on line 4045 App A.2, it says this about XPathCategory: "... an XML attribute called XPathCategory gives the category of the <Content> element where the expression applies." This clearly implies that the XPathCategory contains a Category that may be other than the Category in which the Attribute containing the XPathCategory is contained.Considered from the point of view of an XPath-based function there is no Attribute or Category containing the xPathExpression value and thus nothing to be "other than". The statement in A.2 appears to be directed towards the use of xPathExpression values by the XPath-based functions. > Otherwise, what is the point ofgoing to the trouble of specifying what a piece of clearly redundant information that is already part of the current processing context? My understanding is that XPathCategory is supposed to specify some "other" Category, so unless I am reading the above text wrong, it would seem there is some correction that needs to be made for the intended use case to be possible based on the description, which I think it currently is not.I think the primary use case for xPathExpression is the XPath-based functions and that ContextSelectorId is a peripheral addition. It does not look like there was ever any intention to create a general mechanism to redirect from one category to another. We will have to poll the TC to get to the bottom of this question.That being said, if the wording of the AttributeSelector text were to be changed to something more accurate, such as changing the last sentence of the Category description to say: "It ALTERNATIVELY indicates the attributes category containing the applicable ContextSelectorId attribute, if the element includes a ContextSelectorId xml attribute." i.e. the Category xml attribute of the AttributeSelector cannot both represent the Category of the Content, AND the Category of the ContextSelectorId attribute, unless they both happen to be in the same Attributes element, in which case XPathCategory is unnecessary to have in the ContextSelectorId attribute. In addition, I think the last sentence of the AttributeSelector@ContextSelectorId should say: "The XPathCategory attribute of the referenced attribute MUST be equal to the Category attribute of the ATTRIBUTES ELEMENT CONTAINING THE CONTENT ELEMENT THAT THE XPATH IS INTENDED TO ACCESS." Assuming what I have said is correct, then finally we are at the point where I can say that the same situation exists w the AttributeSelector, i.e. that the AttributeSelector also does not know what Category the content containing the AttributeValue it is looking for, or, for that matter, the path that is used to access that attribute value. Finally, given all that, I don't think the situation is as dire as you seem to indicate that you think it is. From my perspective, the PEP needs to be relied on to be responsible for assembling a valid Request. And it would seem to be the PEP's choice as to have an Attribute in one Category reference an AttributeValue in another Category. As long as the metadata can be relied on, and validated appropriately, for example, DataType and Issuer, can be specified in all 3 places: AttributeDesignator, referencing Attribute, and referenced Attribute. It is up to the PEP to assemble a valid construct that can be relied upon by the PDP as part of a PDP-PEP "contract" that is currently outside the scope of the XACML specification.It is the assembly that is the problem. The more that the PEP and PIP are required to do to achieve the desired effect of policy then the less a policy writer can do to change policy without it requiring re-engineering or reconfiguration of the PEP and PIP. I will come back to this point at the end.Bottom line from my perspective is that if the proper governance is in place between the PEP and PDP then what we are looking at here is simply distinctions between the navigation within the Request structure as opposed to any substantive value proposition about one or the other being more reliable. So, I don't think "control" has passed from the policy writer to the PEP, but only a choice by the PEP as to how to package the information, any of which the PEP must be responsible for, in terms of valid content and in terms of what the sources/metadata are of the data that is contained in the Request. Actually it does "know" because the XPathCategory in an xPathExpression value does not affect the processing by the AttributeDesignator. The AttributeDesignator will fetch values of the nominated attribute and data-type from the nominated Attributes element. If those values have the xPathExpression data-type, then they will have an XPathCategory XML attribute, but the AttributeDesignator will just provide these XML attributes in the bag of XACML attribute values that it passes back. It is the XPath-based functions that process the XPathCategory XML attributes. The ContextSelectorId of an AttributeSelector will make the AttributeSelector pay attention to the XPathCategory XML attribute, but section 5.30 of the core specification says that the "XPathCategory attribute of the referenced attribute MUST be equal to the Category attribute of the attribute selector" ruling out the possibility of referencing into a different Attributes element. Thus the indirection you are proposing for the AttributeDesignator does not have a precedent in the processing of xPathExpression values by attribute designators and selectors. I think the previous comments address what you have said here. In particular, I agree w what you have observed about the AttributeSelector text, but I think that either the text is wrong, or the XPathCategory attribute is superfluous as described above. Clearly my proposal was based on the assumption that the XPathCategory xml attribute was not superfluous, which is why I proposed to extend its meaning. Attribute flattening is described in the IPC profile. ... Suppose there is a second boolean attribute of an organization that we want to use in decisions. Let's call it US-organization. We can't reference it using the same access-subject/organization attribute we used for non-profit-organization because that would be ambiguous. We need two access-subject attributes to do the job. Let's call them organization-np and organization-us. Allow that the access subject can be associated with zero, one or more organizations. We can fetch the values the subject's organizations' non-profit-organization attributes using an attribute designator like: <AttributeDesignator Category="access-subject" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> We can fetch the values of subject's organizations' US-organization attributes using an attribute designator like: <AttributeDesignator Category="access-subject" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> We can ask a question like "is the subject associated with a non-profit organization and associated with a US organization ?" using an expression like: <Apply FunctionId="and"> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> However, we have no way to ask the question "is the subject associated with an organization that is both a non-profit organization and a US organization ?" unless we know for certain that the user is associated with exactly one organization. The above "and" expression will work in that case because we know that any and all values returned for organization-np and organization-us are properties of the same organization. However, when the subject can be associated with one or more organizations we don't know which organization-np values belong with which organization-us values. These are the correlations that get lost with attribute flattening and with your proposal. I think this is exactly the situation my proposal can address. Let's assume the subject is associated w two organizations, each of which is represented in the request by an Attributes element. In order to be provided in the same request as processed by the PDP, the two Attributes elements would need different Category-id's such as "organization-1", and "organization-2" <Attributes Category="subject-access"> <Attribute AttributeId="organization-1-np"> <AttributeValue DataType="boolean" XPathCategory="organization-1" >organization-np</AttributeValue> </Attribute> <Attribute AttributeId="organization-1-us"> <AttributeValue DataType="boolean" XPathCategory="organization-1" >organization-us</AttributeValue> </Attribute> <Attribute AttributeId="organization-2-np"> <AttributeValue DataType="boolean" XPathCategory="organization-2" >organization-np</AttributeValue> </Attribute> <Attribute AttributeId="organization-2-us"> <AttributeValue DataType="boolean" XPathCategory="organization-2" >organization-us</AttributeValue> </Attribute> </Attributes> <Attributes Category="organization-1"> <Attribute AttributeId="organization-np"> <AttributeValue DataType="boolean" >true</AttributeValue> </Attribute> </Attributes> <Attributes Category="organization-2"> <Attribute AttributeId="organization-np"> <AttributeValue DataType="boolean" >true</AttributeValue> </Attribute> <Attribute AttributeId="organization-us"> <AttributeValue DataType="boolean" >true</AttributeValue> </Attribute> </Attributes> In this case, I think one could formulate an apply statement based on the 4 subject-access AttributeIds that would could look at the user's association w org-1 and org-2 and determine whether the user belonged to an org that had both booleans set to true.This is the kind of expression I think you mean: <Apply FunctionId="or"> <Apply FunctionId="and"> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-1-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-1-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> <Apply FunctionId="and"> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-2-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-2-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> </Apply> For this to work the PEP, PIP and policy writer have to be in on the act, and if that's the case, then this solution is over-engineered. It would be simpler to say to the PEP, PIP and policy writer that the first associated organization will use CategoryId "organization-1", the second will use "organization-2", and so on. The expression could then be written to directly reference the organization categories like so: <Apply FunctionId="or"> <Apply FunctionId="and"> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-1" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-1" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> <Apply FunctionId="and"> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-2" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="organization-2" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> </Apply> There is no need for the "organization-1-np", "organization-1-us", "organization-2-np" and "organization-2-us" attributes in the access-subject category and no need for a mechanism to redirect from one category to another. Whether you accept this simplification or not it is still not a very scalable solution. As the number of associated organizations grows, the size of the expressions and the number of defined attributes must also grow. A policy writer has to decide how many associated organizations their policy will cater for. Too few carries the risk of getting the wrong decision. Too many means wasted effort and excess verbosity. So far we have only been talking about one kind of association. Add in additional kinds of associations and the number of combinations quickly gets out of control. For comparison, this is how I would do things using my proposal. The expression to test whether the access-subject is associated with a non-profit organization looks something like this: <ForAny VariableId="$org"> <!-- $org is bound to each organization URI in turn --> <AttributeDesignator Category="access-subject" AttributeId="organization" DataType="anyURI" MustBePresent="false"/> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <Apply Function="attribute-designator"> <VariableReference VariableId="$org"/> <!-- CategoryId --> <AttributeValue DataType="anyURI">organization-np<AttributeValue> <!-- AttributeId --> <AttributeValue DataType="anyURI">boolean</AttributeValue> <!-- DataType --> <AttributeValue DataType="boolean">false</AttributeValue> <!-- MustBePresent --> </Apply> </Apply> </ForAny> The request context would look something like this: <Attributes CategoryId="access-subject"> <Attribute AttributeId="organization"> <AttributeValue DataType="anyURI">http://foo.com</AttributeValue> <AttributeValue DataType="anyURI">http://bar.com</AttributeValue> </Attribute> </Attributes> <Attributes Category="http://foo.com";> <Attribute AttributeId="organization-np"> <!-- was non-profit-organization --> <AttributeValue DataType="boolean">true</AttributeValue> </Attribute> </Attributes> <Attributes Category="http://bar.com";> <Attribute AttributeId="organization-np"> <!-- was non-profit-organization --> <AttributeValue DataType="boolean">true</AttributeValue> </Attribute> <Attribute AttributeId="organization-us"> <!-- was US-organization --> <AttributeValue DataType="boolean">true</AttributeValue> </Attribute> </Attributes> Now, if I want to test whether the access-subject is associated with an organization that is both a non-profit organization and a US organization the expression looks something like this: <ForAny VariableId="$org"> <!-- $org is bound to each organization URI in turn --> <AttributeDesignator Category="access-subject" AttributeId="organization" DataType="anyURI" MustBePresent="false"/> <Apply FunctionId="and"> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <Apply Function="attribute-designator"> <VariableReference VariableId="$org"/> <!-- CategoryId --> <AttributeValue DataType="anyURI">organization-np<AttributeValue> <!-- AttributeId --> <AttributeValue DataType="anyURI">boolean</AttributeValue> <!-- DataType --> <AttributeValue DataType="boolean">false</AttributeValue> <!-- MustBePresent --> </Apply> </Apply> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <Apply Function="attribute-designator"> <VariableReference VariableId="$org"/> <!-- CategoryId --> <AttributeValue DataType="anyURI">organization-np<AttributeValue> <!-- AttributeId --> <AttributeValue DataType="anyURI">boolean</AttributeValue> <!-- DataType --> <AttributeValue DataType="boolean">false</AttributeValue> <!-- MustBePresent --> </Apply> </Apply> </Apply> </ForAny> This works for any number of organizations from zero upwards. The request context is the same as before. In my proposal the redirection is explicit in the policy and therefore under the control of the policy writer. In the worst case, going from the first expression to the second expression, it might have been necessary to configure the PEP, but more likely the PIP, to know about and provide the "organization-us" attribute. This would be the same with your proposal, but with your proposal, going from testing just organization-np to testing both organization-np and organization-us, it is also necessary to configure the PEP or PIP to properly construct the "organization-X-np" and "organization-X-us" redirection attributes for X equals 2 to whatever. These are not natural properties of an access-subject, so they are exceedingly unlikely to already be available (unlike the "organization-us" attribute in an organization entity). This is why it is undesirable to have the redirection under the control of the PEP and/or PIP. It's not about correctness or security (although having the PEP control redirection probably increases the attack surface for injection attacks), it's about greater flexibility for policy writers. Regards, StevenIn the case above, org-1 does not, but org-2 does, so you could set up an Apply that did an OR of org-1,org-2, and within each did and AND of org-np, org-us to produce a true based on the attrs contained in org-2. Thanks, Rich On 7/30/2013 10:38 PM, Steven Legg wrote:Hi Rich, On 30/07/2013 3:00 PM, rich levinson wrote:Hi Steven, Apologies for taking so long to get back - as I indicated at the mtg, I was on vacation when this email arrived and simply missed it. I don't think I agree w your analysis/interpretation of my proposal. Let me try doing it more explicitly using your example as a basis. In the policy, the attribute designator contains, as you have suggested: <AttributeDesignator Category="access-subject" AttributeId="organization" DataType="boolean" MustBePresent="false"/> I think where my differs begins in the attribute directly targeted by the designator, which is "organization" in the "access-subject" category. I think the attribute would look like this: <Attribute AttributeId="organization"> <AttributeValue DataType="boolean" XPathCategory="resource" >non-profit-organization</AttributeValue> </Attribute> where the only difference is I have provided the Attribute envelope w the AttributeId, plus I have changed the XPathCategory to something that looks more like a category than what you had there (for which I did not understand the motivation?: did you intend that there be a category called "http://foo.com";? this did not seem to make sense to me.).I intended that there be another entity represented by an Attributes element and identified by the URI "http://foo.com";. This is a specific organization associated with the access subject, which is neither the access-subject nor the resource. I could have conjured up a new, predefined category called "organization", but this assumes that the access-subject can only be associated with one organization. The "Attributes of Relations" thread is, in part, about how to deal with multiple instances of the same kind of entity. In this case, association with more than one organization. If each such organization's Attributes element used the same CategoryId, then this would be interpreted as a request for multiple decisions, which we don't want. So to allow more than one organization entity in the request context, they each need to have a unique CategoryId, which is really an entity identifier in their case, but I don't have the luxury of changing the core schema so CategoryId has to do double duty. Now, if you are only going to use your proposal to reference from one predefined category into another predefined category, then I don't see the value in it. The attribute designator could just be written to directly access the other category instead, e.g.: <AttributeDesignator Category="resource" AttributeId="non-profit-organization" DataType="boolean" MustBePresent="false"/>In any event, given the way this example is set up, we would now look in the resource category "Attributes" element for an attribute w AttributeId="non-profit-organization" (again, I am just following the example, although the naming does not seem to make sense, which may have something to do w our differing views). <Attributes Category="resource"> <Attribute AttributeId="non-profit-organization"> <AttributeValue DataType="boolean" >true</AttributeValue> </Attribute> </Attributes> So, basically, the motivation here, in the context of this example, is that for some reason, the <Attributes Category="resource"> contains an attribute that the preparer of the <Attributes Category="subject-access"> wants to refer to. Maybe this is just the way they want to set up their policies w the subject-access containing attributes that are associated w other "entities" than the subject-access itself. However, let's leave the motivation until we have a common understanding of the proposed mechanism and then see if it addresses the attributes of relations use case, which would then be the motivation, if appropriate. Now, to address the issues you raised: First the summary statement would say "then the attribute designator would fetch the boolean value(s) of the non-profit-organization attribute in the resource Attributes category of the Request" So the statement begins the same, but now indicates that the actual value is obtained from another Attributes category element.That was what I intended. The CategoryId of that Attributes element being "http://foo.com";.Now, the issues: * "The content of the attribute value in the access subject (a URI) doesn't conform to it's nominated syntax (boolean)." o You are correct that the DataType in the AttributeValue in the Attribute w AttributeId "organization" does not match the "DataType" of the AttributeValue. However, the reason is that the "XPathCategory" xml attribute of the AttributeValue semantically changes the DataType xml attribute to apply to the target AttributeValue in the Attributes element w the category specified in the current value. i.e. the AttributeValue of the referencing Attribute, which is the one referenced by the AttributeDesignator contains the AttributeId of the Attribute to be found in the Attributes w the category specified by XPathCategory. i.e. The presence of the XPathCategory changes the AttributeValue element from being a value container to being a value "referencer".I understand that the presence of the XPathCategory XML attribute changes the actual data-type, but it's ugly to have the value proclaim it is one type when it is really a different type. I also realize that you can't fix that without breaking something else.* "It's not obvious from the attribute designator what attribute values are being fetched." o I disagree. The AttributeDesignator is pointing to the "access-subject" Attributes element, w metadata restrictions of AttributeId and DataType. Because the Attribute contains an XPathCategory this indicates that the target value is not here, but in another Attributes element.Well that's kind of my point. The AttributeDesignator says get the organization attribute from the access-subject, but the values that are returned are actually from the non-profit-organization attribute in a different category. Or they might actually be from a boolean organization attribute in the access-subject because the values didn't carry the XPathCategory XML attribute. Or they might be from some other attribute entirely because the PEP or PIP put in something other than what you intended. We can't look at an AttributeDesignator and be certain where the values it fetches will be coming from. Control has passed from the policy writer to the PEP and PIP.This appears to me to be the same as is done w the XPathExpression, where, if XPathCategory is set to anything other than that of the current Attributes element, then the value is retrieved from a different Attributes element. In that case, the XPathExpression, itself, acts as a kind of AttributeId, by pointing to a specific location in an external xml document, namely, the Content "document element", wherever it may be in the overall Request. i.e. in the XPathExpression case, the AttributeDesignator also does not "know" in which Attributes element that the AttributeValue will be found.Actually it does "know" because the XPathCategory in an xPathExpression value does not affect the processing by the AttributeDesignator. The AttributeDesignator will fetch values of the nominated attribute and data-type from the nominated Attributes element. If those values have the xPathExpression data-type, then they will have an XPathCategory XML attribute, but the AttributeDesignator will just provide these XML attributes in the bag of XACML attribute values that it passes back. It is the XPath-based functions that process the XPathCategory XML attributes. The ContextSelectorId of an AttributeSelector will make the AttributeSelector pay attention to the XPathCategory XML attribute, but section 5.30 of the core specification says that the "XPathCategory attribute of the referenced attribute MUST be equal to the Category attribute of the attribute selector" ruling out the possibility of referencing into a different Attributes element. Thus the indirection you are proposing for the AttributeDesignator does not have a precedent in the processing of xPathExpression values by attribute designators and selectors.* "The correlations between different attributes of the related entity are lost, just as in attribute flattening." o Ok, I'm not sure what you mean by "attribute flattening", but I do not believe anything is "lost" in my proposal.Attribute flattening is described in the IPC profile.The only thing that changes here is that the access is "indirect", just as it is w the XPathExpression that uses XPathCategory and AttributeValue to navigate to the actual value. i.e. in this case the "navigation" is also using XPathCategory to identify the Attributes element, but instead of "XPath'ing" to the target attribute value, it is "AttributeId'ing" to the target AttributeValue. Bottom line is that nothing should be lost because all the info is retained either in the referencing or the referenced Attribute element, and the same metadata controls can be applied as in the direct case. It's just the presence of (the poorly named) XPathCategoryId triggers a slightly more complicated navigation mechanism.Suppose there is a second boolean attribute of an organization that we want to use in decisions. Let's call it US-organization. We can't reference it using the same access-subject/organization attribute we used for non-profit-organization because that would be ambiguous. We need two access-subject attributes to do the job. Let's call them organization-np and organization-us. Allow that the access subject can be associated with zero, one or more organizations. We can fetch the values the subject's organizations' non-profit-organization attributes using an attribute designator like: <AttributeDesignator Category="access-subject" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> We can fetch the values of subject's organizations' US-organization attributes using an attribute designator like: <AttributeDesignator Category="access-subject" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> We can ask a question like "is the subject associated with a non-profit organization and associated with a US organization ?" using an expression like: <Apply FunctionId="and"> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> However, we have no way to ask the question "is the subject associated with an organization that is both a non-profit organization and a US organization ?" unless we know for certain that the user is associated with exactly one organization. The above "and" expression will work in that case because we know that any and all values returned for organization-np and organization-us are properties of the same organization. However, when the subject can be associated with one or more organizations we don't know which organization-np values belong with which organization-us values. These are the correlations that get lost with attribute flattening and with your proposal. Regards, StevenHopefully this makes the proposal a little more clear. I certainly welcome any issues that you may raise, but I think the current issues are just indicators that clarification of the mechanism was needed as opposed to substantive functional issues, which may still be present, but I don't see them yet. Thanks, Rich On 7/16/2013 8:33 PM, Steven Legg wrote:Hi Rich, On 13/07/2013 3:48 PM, rich levinson wrote:To Steven, Mohammad, & TC: At yesterday's meeting, I mentioned that I thought it might be possible to implement the "relationship based access control" reqts using the current 3.0 spec, but also that I have not had time to fully analyze the reqts and the applicability of the soln. In any event, I will explain things as far as I have gotten looking at this capability. The first thing that brought this to my attention was when I was looking at examples using XPathCategory in the 3.0 spec. I was aware that this had something to do w AttributeSelectors, but I was surprised to find one in an AttributeDesignator (in Rule 1 in sec 4.2.4.1): 1090 [f60] <AttributeDesignator 1091 [f61] MustBePresent="false" 1092 [f62] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 1093 [f63] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector" 1094 [f64] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/> 1095 [f65] The example is connected to the request in section 4.2.2, and, sure enough, there is an Attribute there that will be resolved w this designator: 963 [e43] <Attribute IncludeInResult="false" 964 [e44] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector" > 965 [e45] <AttributeValue 966 [e46] XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 967 [e47] DataType=" urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression" 968 [e48] >md:record/md:patient/md:patientDoB</AttributeValue> 969 [e49] </Attribute> There is nothing particularly remarkable about this particular example, however, it is fairly obvious that the xpathExpression value could apply to the <Content> of any <Attributes> element in the <Request>, simply by changing the value of XPathCategory to point to the Category w the desired value, such as category:action, or category:access-subject. Therefore we have a potential starting point for referencing attributes in some other category than the category that the associated Attribute element is in. i.e. in the above example the Attribute is in the category:resource collection, but its value can be in the <Content> element of either the category:resource collection OR any other <Content> element in some other category:xxx collection, simply by setting the Value of XPathCategory appropriately. There is an additional benefit that the xpath selection mechanism can also be associated w the metadata of the xpathExpression Attribute, which I don't think is the case w the plain vanilla AttributeSelector (but this is a secondary note, not the main point of this discussion). There are a couple of choices that I considered for making this mechanism more general: 1. We could allow XPathCategory to be used w any DataType, in which case the content of the AttributeValue would contain the AttributeId of the desired Attribute in the other Attributes collection-category. I believe this is functionally equivalent to the way the xpathExpression is used, if one considers the path in the content to effectively be the "id" of the attribute. Also, it could be the presence of the XPathCategory attribute that would trigger the semantic interpretation of the value as a reference instead of a normal value.So if a value fetched by an attribute designator has the XPathCategory XML attribute (not the best name for it, obviously), then the attribute designator instead fetches the attribute nominated by the original value's content from the entity nominated by the XPathCategory XML attribute for the data-type specified by the attribute designator ? For example, if this is the attribute designator: <AttributeDesignator Category="access-subject" AttributeId="organization" DataType="boolean" MustBePresent="false"/> and this is one of the values of the organization attribute in the access-subject: <AttributeValue DataType="boolean" XPathCategory="http://foo.com"; >non-profit-organization</AttributeValue> then the attribute designator would fetch the boolean values of the non-profit-organization attribute in the access subject's organization entity. If I've joined the dots correctly, then I see a number of drawbacks: - The content of the attribute value in the access subject (a URI) doesn't conform to it's nominated syntax (boolean). - It's not obvious from the attribute designator what attribute values are being fetched. - The correlations between different attributes of the related entity are lost, just as in attribute flattening. Regards, Steven2. I can't remember the other choices at the moment, but I think the above was the best one as I recall. So, I think the above should get the basic idea across. I had intended to go thru the emails on attributes of relations in more detail to determine if the above had the potential of meeting the reqts, but I have not had the time to do that, so I am asking the interested parties to that discussion if they think this approach would be viable, and also a path of minimal impact on the existing xacml specs. Thanks, Rich -- Thanks, Rich Oracle <http://www.oracle.com> Rich Levinson | Internet Standards Security Architect Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity Management 45 Network Drive | Burlington, Massachusetts 01803 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment-- Thanks, Rich Oracle <http://www.oracle.com> Rich Levinson | Internet Standards Security Architect Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity Management 45 Network Drive | Burlington, Massachusetts 01803 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment-- Thanks, Rich Oracle <http://www.oracle.com> Rich Levinson | Internet Standards Security Architect Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity Management 45 Network Drive | Burlington, Massachusetts 01803 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php-- Thanks, Rich Oracle <http://www.oracle.com> Rich Levinson | Internet Standards Security Architect Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity Management 45 Network Drive | Burlington, Massachusetts 01803 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment-- Thanks, Rich Oracle <http://www.oracle.com> Rich Levinson | Internet Standards Security Architect Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity Management 45 Network Drive | Burlington, Massachusetts 01803 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]