OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

RE: [xacml] urn:oasis:names:tc:xacml:1.0:function:present

  • 1.  RE: [xacml] urn:oasis:names:tc:xacml:1.0:function:present

    Posted 06-29-2004 18:49
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

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


    Subject: RE: [xacml] urn:oasis:names:tc:xacml:1.0:function:present


    I do not feel strongly about it.  I think MustBePresent usually
    works.  If someone wants to avoid errors where an attribute is
    not present, they either put the test for the attribute in the
    Target, or set MustBePresent=false and test for the size of the
    resulting bag.
    
    Anne
    
    On 29 June, Tim Moses writes: RE: [xacml] urn:oasis:names:tc:xacml:1.0:function:present
     > From: Tim Moses <tim.moses@entrust.com>
     > To: 'Polar Humenn' <polar@syr.edu>, 'XACML' <xacml@lists.oasis-open.org>
     > Subject: RE: [xacml] urn:oasis:names:tc:xacml:1.0:function:present
     > Date: Tue, 29 Jun 2004 13:30:21 -0400
     > 
     > Polar - Yeah.  That is more complicated.  Do people feel this is
     > functionality we have to have?
     > 
     > All the best.  Tim.
     > 
     > -----Original Message-----
     > From: Polar Humenn [mailto:polar@syr.edu] 
     > Sent: Monday, June 28, 2004 1:02 PM
     > To: 'XACML'
     > Subject: RE: [xacml] urn:oasis:names:tc:xacml:1.0:function:present
     > 
     > 
     > 
     > We have to be thorough on treatment of this function. I believe we would
     > need four "isPresent" functions, one each for subject,resource, action, and
     > environment.
     > 
     > I can see why we this function got left in the lurch, but I do believe IT IS
     > NEEDED,
     > 
     > I'd rather have a formal way to make decisions based on presence of
     > attribute values, instead of relying on forcing ERROR conditions to
     > calculate policy decisions.
     > 
     > I believe the "present" functions would have to have multiple arguments, to
     > match the semantics of the attribute designators. We would need the URI for
     > the attribute id, the datatype, and the issuer.
     > 
     > urn.oasis.....function:subject-attribute-is-present
     > 
     > This function SHALL take four arguments. The first argument is one of
     > data-type "...anyURI", which matches by URI equality the subject-category.
     > The second argument is one of data-type "...anyURI", which matches by URI
     > equality the id of the attribute(s). The third argument is one of data type,
     > "...anyURI", which matches by URI equality, the data-type of the
     > attribute(s). The fourth argument is a string that matches by string
     > equality, the issuer of the attribute, otherwise may contain the string
     > value of "*" to match any issuer.
     > 
     > urn.oasis.....function:*-attribute-is-present
     >         (where * is one of resource, action, or environment)
     > 
     > This function SHALL take arguments. The first argument is one of data-type
     > "...anyURI", which matches by URI equality the id of the attribute(s). The
     > second argument is one of data type, "...anyURI", which matches by URI
     > equality, the data-type of the attribute(s). The third argument is a string
     > that matches by string equality, the issuer of the attribute, otherwise may
     > contain the string value of "*" to match any issuer.
     > 
     > Did I just make the problem way too hard?
     > 
     > -Polar
     > 
     > 
     > On Mon, 28 Jun 2004, Tim Moses wrote:
     > 
     > > Colleagues - If we are to retain the function "present", how about 
     > > this as a definition?
     > >
     > > urn:oasis:names:tc:xacml:1.0:function:present
     > >
     > > This function SHALL take one argument of data-type 
     > > "http://www.w3.org/2001/XMLSchema#anyURI"; and SHALL return a 
     > > "http://www.w3.org/2001/XMLSchema#boolean";.  The return value SHALL be 
     > > "True" if there exists anywhere in the request context an attribute 
     > > with an attributeId attribute whose value is the same as that of the 
     > > function argument, according to the 
     > > urn:oasis:names:tc:xacml:1.0:function:anyURI-equal function.  
     > > Otherwise, it SHALL return "False".
     > >
     > > What do you think?
     > >
     > > All the best.  Tim.
     > >
     > >
     > >
     > >
     > > -----Original Message-----
     > > From: Polar Humenn [mailto:polar@syr.edu]
     > > Sent: Thursday, June 24, 2004 8:34 AM
     > > To: Seth Proctor
     > > Cc: Tim Moses; 'XACML'
     > > Subject: Re: [xacml] urn:oasis:names:tc:xacml:1.0:function:present
     > >
     > >
     > >
     > > I don't think we trashed that function. Did we? What was confusing 
     > > about it? I don't recall. -Polar
     > >
     > > (won't make the confernce call today. I'm a the OMG meeting.
     > >
     > > -Polar
     > >
     > > On Tue, 22 Jun 2004, Seth Proctor wrote:
     > >
     > > > On Tue, 2004-06-22 at 16:18, Tim Moses wrote:
     > > > > Colleagues - We list the function 
     > > > > "urn:oasis:names:tc:xacml:1.0:function:present" as "mandatory" in 
     > > > > the conformance section.  But, I can't see a definition for it.  
     > > > > Can anyone explain?  All the best.  Tim.
     > > >
     > > > Late into the 1.0 work there was a present function for determining 
     > > > if a value was present, but the semantics got too confused so we 
     > > > trashed it and instead created the MustBePresent attribute on 
     > > > Designators and Selectors. I suspect it's just a mistake that the 
     > > > attribute was left in. I suggest it should be removed.
     > > >
     > > >
     > > > seth
     > > >
     > > >
     > > > To unsubscribe from this mailing list (and be removed from the 
     > > > roster of the OASIS TC), go to 
     > > > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_wor
     > > > kg
     > > > roup.php.
     > > >
     > >
     > 
     > To unsubscribe from this mailing list (and be removed from the roster of the
     > OASIS TC), go to
     > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p
     > hp.
     > 
     > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
     > 
    
    -- 
    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
    
    


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