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.
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
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,
Steven
Hopefully 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,
Steven
2. 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
Rich Levinson | Internet Standards Security
Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Oracle is committed to developing practices
and products that help protect the environment
|