OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]