Thanks for the feedback and attempted clarification on
AttributeValueType :). I admit I am still a little confused, let me
try to explain. I think the problem is that a definitive example is
needed. Here is my perspective: A typical attribute in the
RequestContext has the following form:
<Attribute AttributeId="def" Issuer="ghi" IncludeInResult="jkl">
(Couple points worth noting are that DataType has moved from being an
attribute of Attribute in XACML 2.0 to being an attribute of
AttributeValue in XACML 3.0., also that IncludeInResult is new in 3.0,
and Category is expanded in 3.0 to be general, from the SubjectCategory
special case from 2.0)
Presumably, all the attributes in the response sent by IncludeInResult
appear in this same form in the Response.
The first additional case we addressed was MissingAttributeDetail,
section 5.56, which appears to come back in the following form:
<MissingAttributeDetail Category="abc" AttributeId="def"
This has essentially the same form as the other attributes, except:
I am ok w those differences, since an AttributeValue may not be
returned, in general, because, after all, the point is that it is
"missing" and the PDP may tell the PEP what dataType is needed, it
probably is not going to say what value to provide. However, and empty
AttributeValue w DataType attribute might be an improvement.
- Category is pushed down so it now appears alongside AttributeId
- DataType is above <AttributeValue> as it was in XACML 2.0
Also, I am satisfied with pushing down Category into the
MissingAttributeDetail, because the StatusDetail can hold multiple of
these elements and there is not reason why they would all have the same
Category, which is unlike the case on Input, and to some degree
IncludeInResult as well.
With that context in mind, what I am "expecting" to see for
AttributeAssignment is something along the following lines:
<AttributeAssignment Category="abc" AttributeId="def"
>do this and that</AttributeValue>
I have not found any examples to confirm the above "expectation", so I
have been relying on interpreting the xml, which is the reason for my
From the meeting minutes, I see the TC agreed w your suggestion to
include Category as optional, which seems fine to me.
So, all that remains in my mind is straightening out what is actually
returned. It sounds from your description that
I apologize for being picky, but with the absence of examples, I
still find this sentence difficult to parse in a way that makes sense.
I interpret "content" as "child", so in this case if I take the first
part of the sentence literally, AttributeAssignment "replaces"
AttributeValue, so there is no "AttributeValue" and it just has the
text content, no contained elements.
- "AttributeAssignment has the same content as AttributeValueType,
except that the XML attribute AttributeId is required"
Now the second part of the sentence says that "except that the XML
AttributeId is required", which I interpret that AttributeId is
attribute of AttributeAssignment. Finally, w decision for optional
Category, we would have:
<AttributeAssignment Category="abc" AttributeId="def"
>do this and that</AttributeAssignment>
Is this correct?
If so, then I guess my comment is why the need to squeeze out the
AttributeValue element? Also, if it can be squeezed out why is it there
in the first place?
Bottom line: I think the reason I am still confused it that there
appears to be some non-intuitive behavior, which appears somewhat
arbitrary, possibly because AttributeValue may be functionally
extraneous, which doesn't bother me, and even if it is, my
recommendation is that we use it consistently and not arbitrarily
squeeze it out.
Also, might want to consider "Issuer" in the AttributeAssignment as
well in case, policy designers want to distinguish where Obligations
are coming from, at a finer granularity than just "the PDP".
Erik Rissanen wrote:
I presume you are referring to the following schema fragment:
This means that an AttributeAssignment has the same content as
AttributeValueType, except that the XML attribute AttributeId is
required. Like this:
some value here
We want to declare the XML attribute, although xs:anyAttribute is
already allowed, since without the declaration the AttributeId is not
I haven't thought about the category for attributes in obligations. I
have thought them as parameters of the obligation, not parts of the
request. But I see the point. What about making the Category an
optional XML attribute? That way it won't "pollute" those obligations
which just contain obligation parameters, but it will still be possible
to return parts of the request.
While reviewing where we have ended up with
the handling of Obligation elements in 3.0, I have 2 questions which I
am unable to resolve based on my reading of the text (question 2
contains a possible issue of functionality, question 1 might just be
clarification either by response to this email or by issue for more
explanatory info in the text):
1. AttributeId in Obligation in Response: In section 5.41,
AttributeAssignmentExpression, it says:
* "It SHALL contain an AttributeId and an expression which
SHALL by evaluated into the corresponding attribute value."
* Presumably, this means that these two items will be what
the PDP puts into the Obligation element that is put into
the Response. This interpretation is also in agreement, I
believe, with the description of this element in section
o "The expressions SHALL be evaluated by the PDP to
constant <AttributeValue> elements, which shall
the attribute assignments in the <Obligation>
returned to the PEP. "
* Presumably the two items above (AttributeValue,
AttributeId) are then put by the PDP into the
AttributeAssignment element (section 5.36) which is child
to the Obligation (section 5.34)
* Here is my basic question on section 5.36, which may be
simply that I do not understand the mechanics of the
extension element in the schema: it appears on lines
2543-2546 that AttributeId might be defined here as an
attribute of AttributeValue:
o So, that's the 1st part of the question. Is this the
same AttributeId identified in section 5.41, and
does it show up in the output Obligation as an
attribute of the AttributeAssignment element or of
the AttributeValue element? (It appears based on the
above that it might be the latter, if not please
o If it is the an attribute of AttributeValue, the 2nd
part of the question is does this not kind of
violate section 5.31 AttributeValue, because this
AttributeId would presumably now be part of the
2. (2nd question) Should we include the "Category" in the
Obligation (probably not because that would apply to all
AttributeAssignments) or preferably in the AttributeAssignment
(assuming the AttributeId is already there from question 1)?
* The reason for asking is that it does not seem
unreasonable that in many cases the AttributeId assigned
to the Obligation/AttributeAssignment will be the same
AttributeId used to pull an attribute out of the Request.
Granted, it doesn't have to be, but let's assume that is
what some people might want to do.
* Assuming people want to do this, we now run into the same
ambiguity that led to the addition of Category to
MissingAttributeDetail (section 5.56), namely that if the
PEP needs to know how to correlate the returned attributes
with the input request, then both AttributeId and Category
are needed, in general.