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


Subject: Re: [xacml] CR 144: function "present" needs to be fixed.


On Tue, 22 Oct 2002, Simon Godik wrote:

> If we adopt must-be-present it should have additional args:
> must-be-present(attr-kind, attr-id, type-uri);

Ah, yes, do you mean, "Subject", "Resource", "Action"?

Okay, now I can see a problem I didn't see before.

We still will not be able with this method, write a simple "present"
predicate for Subject, since we have requirements for which subject
to get it from.

How about this:

action-attribute-is-present
action-attribute-must-be-present

resource-attribute-is-present
resource-attribute-must-be-present

subject-attribute-is-present
subject-attribute-must-be-present

> We also need similar function for the attribute-selector.
> must-be-present-xpath(xpath-expr, type-uri)

likewise.

The resource-* and action-* functions will take two arguments, which are
attribute values containing the id and data type,
The subject-* functions will take an extra argument that will
be an attribute value that carries the subject category identifier.

> We can not put functions in the target.

That is correct.

> I'd prefer to have mustBePresent attribute in the attribute-designator
> and attribute-selector elements. When it's value is set to 'true' and
> attribute is not found, attribute-designator expression shall evaluate to
> indeterminate.

That may be simple in the condition, but like I said before, this
complicates targeting.


-Polar

> Simon
>
> ----- Original Message -----
> From: "Polar Humenn" <polar@syr.edu>
> To: "XACML" <xacml@lists.oasis-open.org>
> Sent: Tuesday, October 22, 2002 9:25 AM
> Subject: [xacml] CR 144: function "present" needs to be fixed.
>
>
> >
> > The function "present" as we discussed yesterday in spec 18d is vague in
> > whether it returns "false" or raises an "indeterminate" if the attribute
> > is not present.
> >
> > This needs to be cleared up, and we might address some of Simon's concerns
> > of which he alluded to yesterday on "indeterminate" for an attribute that
> > is not present. I don't like that, but I'm not against it. So, how about
> > two functions?
> >
> > Since we now requiring DataType to be present in both the attribute of the
> > context and in the attribute designator of the policy, such that the look
> > up for the attribute is comprised of both the id and data type, we need to
> > address this lookup requirement in the function "present". It needs to be
> > fixed anyway.
> >
> > I suggest that we have two functions, summary:
> >
> > is-present
> >     returns true if the attribute is there, and false if not.
> >
> > must-be-present
> >     returns true if the attribute is there, and raises
> > indeterminate if not. (The PDP can easily carry a "missing-attribute"
> > status from this, if it wanted).
> >
> >
> > So, I suggest replacing the last bullet and paragraph in Section A14.5
> > Logical Functions, (i.e. "present") with the following:
> >
> >
> > o is-present
> >
> > This function SHALL take two arguments. The first argument SHALL be an
> > attribute value of type "xs:anyURI" as used in the "AttributeId"  XML
> > attribute of an <AttributeDesignator> element. The second argument SHALL
> > be an attribute value of type "xs:string" containing the identity of the
> > data type as used in the "DataType" XML attribute of the
> > <AttributeDesignator> element. This expression SHALL result in "true" if
> > the named attribute can be located in the request context, which means
> > that an <AttributeDesignator> or <AttributeSelector> element for this
> > named attribute will return a bag consisting of at least one element. If
> > no value can be found for the attribute in the request context, then this
> > expression SHALL result in "false", which means that an
> > <AttributeDesignator> or <AttributeSelector> element for this named
> > attribute will return an empty bag. If it cannot be determined whether the
> > attribute is present or not present in the request context, or its value
> > is unavailable, the expression SHALL result in "indeterminate".
> >
> > o must-be-present
> >
> > This function SHALL take two arguments. The first argument SHALL be an
> > attribute value of type "xs:anyURI" as used in the "AttributeId"  XML
> > attribute of an <AttributeDesignator> element. The second argument SHALL
> > be an attribute value of type "xs:string" containing the identity of the
> > data type as used in the "DataType" XML attribute of the
> > <AttributeDesignator> element. This expression SHALL result in "true" if
> > the named attribute can be located in the request context, which means
> > that an <AttributeDesignator> or <AttributeSelector> element for this
> > named attribute will return a bag consisting of at least one element. If
> > no value can be found for the attribute in the request context, which
> > means that an <AttributeDesignator> or <AttributeSelector> element for
> > this named attribute will return an empty bag, this expression SHALL
> > result in "indeterminate". If it cannot be determined whether the
> > attribute is present or not present in the request context, or its value
> > is unavailable, the expression SHALL result in "indeterminate".
> >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC