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.
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.
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.
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.
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.
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, since
everything 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. Otherwise, what is the point of
going 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.
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.
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.
In 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
