[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Possible Issue: XACML 3.0 WD 9 - 2 questions on Obligation
I don't understand this alternative. Could you clarify? Regards, Erik Hal Lockhart wrote: > Just thinking out loud, but as an alternative would it make sense to make Obligation (and/or Advice) input a category type? Or do we expect to be using the same attribute for multiple purposes? > > Hal > > >> -----Original Message----- >> From: Erik Rissanen [mailto:erik@axiomatics.com] >> Sent: Thursday, March 19, 2009 2:03 AM >> To: Rich.Levinson >> Cc: xacml >> Subject: Re: [xacml] Possible Issue: XACML 3.0 WD 9 - 2 questions on >> Obligation >> >> Hi Rich, >> >> I presume you are referring to the following schema fragment: >> >> <xs:element name="AttributeAssignment" >> type="xacml:AttributeAssignmentType"/> >> <xs:complexType name="AttributeAssignmentType" mixed="true"> >> <xs:complexContent mixed="true"> >> <xs:extension base="xacml:AttributeValueType"> >> <xs:attribute name="AttributeId" >> type="xs:anyURI" use="required"/> >> </xs:extension> >> </xs:complexContent> >> </xs:complexType> >> >> This means that an AttributeAssignment has the same content as >> AttributeValueType, except that the XML attribute AttributeId is >> required. Like this: >> >> <AttributeAssignment AttributeId="urn:....:foo" DataType="urn:...:bar"> >> some value here >> </AttributeAssignment> >> >> We want to declare the XML attribute, although xs:anyAttribute is >> already allowed, since without the declaration the AttributeId is not >> _required_. >> >> 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. >> >> Best regards, >> Erik >> >> Rich.Levinson wrote: >> >>> 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 >>> >> 5.39: >> >>> o "The expressions SHALL be evaluated by the PDP to >>> constant <AttributeValue> elements, which shall be >>> 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 " >>> >>> <xs:extension base="xacml:AttributeValueType"> >>> >>> <xs:attribute name="AttributeId" >>> type="xs:anyURI" >>> >>> use="required"/> >>> >>> </xs:extension> >>> >>> " >>> 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 >>> explain.) >>> 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 >>> xs:anyAttribute. >>> 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. >>> >>> Thanks, >>> Rich >>> >> --------------------------------------------------------------------- >> 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 >> >> > > > --------------------------------------------------------------------- > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]