OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  RE: [xacml] New working drafts posted

    Posted 12-18-2009 15:27
    Thanks for the code samples, Erik.
    
    As far as I can tell, the problem is limited to casting from text to
    boolean values.  I encountered this problem repeatedly in xslt 1.0
    processing, but I never determined whether the defect was in the
    specification or the implementations.  The problem has disappeared in
    xslt 2.0.
    
    The Java 5 xpath api is based on xpath 1.0, so it is not surprising to
    see this problem there as well.
    
    However, this is not a severe limitation.  It only causes ambiguity in
    the case where you want to distinguish between "does this node exist?"
    and "does this node have a lexical value corresponding to 'true' for the
    xsd:boolean datatype?"  The workaround requires the policy author to
    write xpath expressions that test the node value against the expected
    lexical values (e.g. "true","1", "yes", "false","0", "no") using the
    string equality operator.
    
    I modified Erik's sample to test numeric values, and it successfully
    evaluated "/ns:Foo/ns:Bar" with a numeric return value for
    "".
    
    Therefore, I still believe we should allow any type of xpath expression
    in AttributeSelector/@Path, and specify that the result must be returned
    to the XACML environment as @DataType.  The rules for converting
    datatypes from xpath to XACML are well-defined.  Aside from the
    text-to-boolean problem noted above, this will in general be a useful
    and reliable way of testing XML content and structure.
    
    Regards,
    --Paul
    
    > 


  • 2.  Re: [xacml] New working drafts posted

    Posted 12-19-2009 11:39
    Paul,
    
    I am not convinced yet. :-)
    
    XACML 2.0 has a specification which says that the xpath selects text 
    content, which is then constructed into an XACML data type.
    
    What you instead propose is that an XPath can select any XPath data 
    type, and the return value of the xpath is directly the XACML value.
    
    I see value for both approaches, but we cannot mix them in the same 
    construct. This is what my code sample says. The same XPath gives two 
    different XACML datatype end results depending which approach we use for 
    the definition. We cannot mix them (at least not for any given XACML 
    data type).
    
    So this opens up the question about replacing the XACML 2.0 approach 
    entirely with Paul's new proposal. It has the benefit that more clever 
    things can be done with the xpath expression.
    
    However, Paul's approach has the problem that not all XACML data types 
    are available in XPath, or at least not in XPath 1. And definitely not 
    in XPath 2 either if we consider that XACML is extensible so users could 
    define arbitrary data types on their own. So to handle all XACML data 
    types, including extensions, we need the "select string content" 
    approach from XACML 2.0.
    
    Another benefit with the old selector approach is that it easily handles 
    selection of bags of attributes from the XML. I don't know how that 
    would work in Paul's approach.
    
    So I think the conclusion should be that we introduce a separate 
    construct which is purely XPath based, which takes the XPath return 
    value directly as the value of the XACML data type. For XPath 1 only 
    string, boolean and integer will be possible return values. For XPath 2 
    there will be many more.
    
    And then I think there is ambiguity in the XACML 2.0 attribute selector 
    definition as well. It's not clear to me what the "text representation" 
    of an element node would be. For intance , would the 
    selector "peek" inside the element to get "true"? That seems 
    inconsistent, if we imagine a custom extension data type type such as 
    , where the 
    book on the whole is treated a data type. There we would like to pass 
    the entire 


  • 3.  RE: [xacml] New working drafts posted

    Posted 12-21-2009 14:41
    OK, this is too difficult to work out for 3.0.  I don't use this
    feature, so I don't have a wide range of realistic use cases.  But from
    my experience with xslt and schematron, this will be a significant
    limitation for people who want to write complex rules around their XML
    content.
    
    A quick fix, as suggested by Erik, would be to add a boolean xml
    attribute like "EvaluateXpathAsNodes", which the implementation could
    use to make the correct API call.  But this puts an extra burden on the
    policy-writer, which I am not sure is necessary, and would introduce an
    additional potential source of conflicting directives.  So we should
    probably skip over this for now and consider it post-3.0.
    
    I suggest revising the opening paragraph of section 5.30 to something
    like:
    
    =======================
    The 


  • 4.  Re: [xacml] New working drafts posted

    Posted 12-21-2009 15:41
    Hi Paul,
    
    Ok. I think I prefer to not put in the EvaluateXpathAsNodes into the 
    XPathSelector. The behavior of the attribute selector changes in a 
    significant, but subtle and hard to understand manner because of this 
    attribute, so I think a completely different element is better.
    
    Since we want to stabilize 3.0 now, let's leave that to a later date or 
    an additional profile in the next batch of documents.
    
    Given this I think at least Paul and I have reached some kind of 
    consensus on the remaining issues. I'll post updated working drafts 
    before Christmas so everybody has something to read over the holidays. ;-)
    
    Best regards,
    Erik
    
    On 2009-12-21 15:40, Tyson, Paul H wrote:
    > OK, this is too difficult to work out for 3.0.  I don't use this
    > feature, so I don't have a wide range of realistic use cases.  But from
    > my experience with xslt and schematron, this will be a significant
    > limitation for people who want to write complex rules around their XML
    > content.
    >
    > A quick fix, as suggested by Erik, would be to add a boolean xml
    > attribute like "EvaluateXpathAsNodes", which the implementation could
    > use to make the correct API call.  But this puts an extra burden on the
    > policy-writer, which I am not sure is necessary, and would introduce an
    > additional potential source of conflicting directives.  So we should
    > probably skip over this for now and consider it post-3.0.
    >
    > I suggest revising the opening paragraph of section 5.30 to something
    > like:
    >
    > =======================
    > The