[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Re: [xacml-comment] D024
On Tue, 3 Dec 2002, Anne Anderson wrote: > Polar, I disagree. In my opinion, the type checking for > arguments to functions should be done at the time the function is > evaluated, not at the time the policy is parsed. Hmmm. so, we must be calling every policy that merely passes the policy schema a "valid" policy? That's like saying that class Josed { String ridiculous(String s) { return 1 + s; } } is a valid Java class definition. Try to evaluate that. > Since we have not specified the type-correctness of XACML functions > using XML, the type correctness must be checked after the policy is > parsed by the XML parser. Well there is no way to describe type correctness in XML through the use of a schema. That technology is far less advanced than the idea. The schema is merely a syntax grammar. That's why we have the document. To describe the semantics that cannot be described in XML. > It could be done as a second, XACML-specific parsing step, but I believe > it is probably cleaner to have the type checking done at the time the > function is evaluated. This may make it easier to deal with plug-in > custom functions. Now, doesn't that force a PDP to accept BAD policies? I wouldn't call that "security savvy". Any policy that has something wrong with it, like a type error is extremely suspect and leaves me no assurance as to its correctness of its other parts. Are we forcing PDP's to accept policy sets with nonsensical policies, accept policies with nonsensical rules, accept rules with nonsensical conditions, and accept conditions with nonsensical elements, for example, within an AND or and OR, of which only depending on certain input you find them invalid? IMHO, horrible! If XACML forces my PDP to accept Policy Sets that merely validate against a parse tree but cannot come to some semantic meaning or integrity of evaluation, then why bother with the types at all? In fact, why even bother validating against the policy or request schema? Do we have conformance tests for Policies and RequestContext that do not conform to the schemas? If not, why not? If so, what do they evaluate to? A conformance test for: <?xml version="1.0" encoding="UTF-8"?> <Policy/> against <?xml version="1.0" encoding="UTF-8"?> <RequestContext/> Both structures are valid XML, aren't they? What would a compliant valid PDP evaluate this scenario to? Cheers, -Polar > > Anne Anderson > > On 3 December, Polar Humenn writes: Re: [xacml-comment] D024 > > From: Polar Humenn <polar@syr.edu> > > To: Anne Anderson <Anne.Anderson@sun.com> > > Subject: Re: [xacml-comment] D024 > > Date: Tue, 3 Dec 2002 10:51:40 -0500 (EST) > > > > > > D024 > > > > The condition that John is referring to in > > > > urn:oasis:names:tc:xacml:1.0:conformance-test:IID024:policy3 > > > > in test D024 is not type correct and therefore is not a valid policy, and > > therefore not a valid policy set. Although it might niavely parse through > > the policy-schema, it should not even be evaluated, because it is not type > > correct. > > > > Cheers, > > -Polar > > > > On Tue, 3 Dec 2002, Anne Anderson wrote: > > > > > John Merrells, > > > > > > As in D002, this Condition was intended to produce an > > > Indeterminate result (by passing the wrong argument type to the > > > function) in order to test the requirements of the > > > "first-applicable" algorithm, which says that a Permit or Deny > > > result will be returned even if an Indeterminate result follows. > > > > > > Please let me know if I am overlooking something. > > > > > > Anne Anderson > > > > > > On 26 November, John Merrells writes: [xacml-comment] D024 > > > > From: John Merrells <merrells@jiffysoftware.com> > > > > To: "'xacml-comment@lists.oasis-open.org'" <xacml-comment@lists.oasis-open.org> > > > > Subject: [xacml-comment] D024 > > > > Date: Tue, 26 Nov 2002 17:36:20 -0800 > > > > > > > > > > > > Same as D002... > > > > > > > > <Condition > > > > FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> > > > > <SubjectAttributeDesignator > > > > > > > > AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" > > > > DataType="http://www.w3.org/2001/XMLSchema#string"/> > > > > <AttributeValue > > > > > > > > DataType="http://www.w3.org/2001/XMLSchema#string">Zaphod > > > > Beedlebrox</AttributeValue> > > > > </Condition> > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > To subscribe or unsubscribe from this elist use the subscription > > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > > -- > > > Anne H. Anderson Email: Anne.Anderson@Sun.COM > > > Sun Microsystems Laboratories > > > 1 Network Drive,UBUR02-311 Tel: 781/442-0928 > > > Burlington, MA 01803-0902 USA Fax: 781/442-1692 > > > > > > > > > ---------------------------------------------------------------- > > > To subscribe or unsubscribe from this elist use the subscription > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > -- > Anne H. Anderson Email: Anne.Anderson@Sun.COM > Sun Microsystems Laboratories > 1 Network Drive,UBUR02-311 Tel: 781/442-0928 > Burlington, MA 01803-0902 USA Fax: 781/442-1692 > > > ---------------------------------------------------------------- > 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