[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 onObligation
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]