OASIS eXtensible Access Control Markup Language (XACML) TC

  • 1.  Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

    Posted 02-17-2008 11:14
    This is a major rewrite of the obligation families profile.
    
    Summary of changes:
    
    - Use 


  • 2.  Re: [xacml] Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

    Posted 02-18-2008 08:52
    All,
    
    I just realized that the second option regarding the return value (embed 
    the families in an attribute assignment in an obligation) makes this 
    profile easily available even on XACML 2.0. So perhaps we could do the 
    "cleaner" choice for 3.0 and also support 2.0 using the second choice.
    
    Regards,
    Erik
    
    erik@axiomatics.com wrote:
    > This is a major rewrite of the obligation families profile.
    >
    > Summary of changes:
    >
    > - Use 


  • 3.  Re: [xacml] Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

    Posted 02-24-2008 14:12
    I would like to propose that we introduce a "TTL" attribute to  
    ObligationFamiles, specifically for those that are to occur after the  
    decision has been rendered. The use for post decision Obligations  
    would be along the lines of:
    
      make request (PEP)
      compute decision (PDP)
      generate response (PDP)
      execute decision (PEP)
      execute obligation; ERROR state if not complete by TTL (PEP)
    
    The thinking here is that if you specify that you wish something to  
    happen after the decision is made/enforced then it seems logical that  
    you would want it to be time bound. In other words, I am suggesting is  
    that there are two reasons why an Obligation may not be met, one  
    quantitative (Obligation simply failed), the other qualitative (the  
    Obligation is taking longer to fulfill than is considered reasonable  
    by the Policy writer).
    
    What is "reasonable"? I don't know, but my opinion is that it is  
    defined by the Policy writer not the system administrator because the  
    former has the context of what the Policy is supposed to achieve. I  
    also suspect that the specification of the TTL value is best suited at  
    the ObligationFamily level since it defines the expected behavior for  
    that class of Obligation.
    
    How the ERROR behaves and how that information is dealt with is  
    implementational.
    
    b
    
    On Feb 17, 2008, at 3:13 AM, erik@axiomatics.com wrote:
    
    > This is a major rewrite of the obligation families profile.
    >
    > Summary of changes:
    >
    > - Use 


  • 4.  Re: [xacml] Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

    Posted 02-25-2008 19:47
    All,
    
    I think this is a good use case which we should support.
    
    After some off list clarifications from Bill, I would like to explain 
    how this fits in the current obligation families working draft. I think 
    the document could be improved with respect to this, and I will try to 
    do so for the next version.
    
    The current draft defines "After", "Before" and "With" options for 
    obligations after the proposal from David Chadwick. What is currently a 
    bit unclear perhaps is that when I thought about David's proposal, I 
    made two distinct interpretations from the metadata "After", "Before" 
    and "With".
    
    The first interpretation is what I would call the "Causality" 
    interpretation. According to this interpretation the metadata is 
    intended to guarantee that, for instance, if the obligation is "After", 
    then any side effects from the access enforcement will be visible to the 
    obligation enforcement.
    
    The second interpretation is what I would call the "Atomicity" 
    interpretation. According to this the metadata is intended to guarantee 
    that, for instance, if the obligation is "After", then it is guaranteed 
    that if the obligation is successful, then the access has also been 
    successful.
    
    I tried to think what David intended and I thought that he was mostly 
    interested in the atomicity guarantees, so that is what I wrote in the 
    draft.
    
    What Bill is proposing is the causality interpretation.
    
    I think we should support both. I haven't really thought through yet how 
    these two can interact and be perhaps combined. My gut feeling is that 
    the atomicity guarantees should be supersets of the causality 
    guarantees, that is, if you ask for the atomicity guarantee, you get the 
    causality as well.
    
    Regards,
    Erik
    
    Bill Parducci wrote:
    > I would like to propose that we introduce a "TTL" attribute to 
    > ObligationFamiles, specifically for those that are to occur after the 
    > decision has been rendered. The use for post decision Obligations 
    > would be along the lines of:
    >
    >  make request (PEP)
    >  compute decision (PDP)
    >  generate response (PDP)
    >  execute decision (PEP)
    >  execute obligation; ERROR state if not complete by TTL (PEP)
    >
    > The thinking here is that if you specify that you wish something to 
    > happen after the decision is made/enforced then it seems logical that 
    > you would want it to be time bound. In other words, I am suggesting is 
    > that there are two reasons why an Obligation may not be met, one 
    > quantitative (Obligation simply failed), the other qualitative (the 
    > Obligation is taking longer to fulfill than is considered reasonable 
    > by the Policy writer).
    >
    > What is "reasonable"? I don't know, but my opinion is that it is 
    > defined by the Policy writer not the system administrator because the 
    > former has the context of what the Policy is supposed to achieve. I 
    > also suspect that the specification of the TTL value is best suited at 
    > the ObligationFamily level since it defines the expected behavior for 
    > that class of Obligation.
    >
    > How the ERROR behaves and how that information is dealt with is 
    > implementational.
    >
    > b
    >
    > On Feb 17, 2008, at 3:13 AM, erik@axiomatics.com wrote:
    >
    >> This is a major rewrite of the obligation families profile.
    >>
    >> Summary of changes:
    >>
    >> - Use 


  • 5.  Re: [xacml] Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

    Posted 02-25-2008 23:02
    On Feb 25, 2008, at 10:07 AM, Erik Rissanen wrote:
    
    > I think we should support both. I haven't really thought through yet  
    > how these two can interact and be perhaps combined. My gut feeling  
    > is that the atomicity guarantees should be supersets of the  
    > causality guarantees, that is, if you ask for the atomicity  
    > guarantee, you get the causality as well.
    
    
    This is what spawned my initial proposal a while ago for a hierarchy  
    between ObligationsFamilies.
    
    
    
    The idea behind this approach is that the unbound nature of  
    Obligations makes it difficult to define generalities like "atomicity  
    supersedes causality". By creating a hierarchy within the XACML Policy  
    specification I believe we have the ability to unambiguously define  
    precedence (at least in the decisions) without complex combining rules  
    or external "black box URIs".
    
    Again, this was just the starting point for the initial idea so there  
    is a lot of room for improvement now that we have tangible schemas to  
    start measuring it against :)
    
    b
    


  • 6.  Re: [xacml] Groups - xacml-3.0-obligation-v1-wd-03.zip uploaded

    Posted 02-28-2008 15:35
    Minor suggestions from my end:
    name="ObligationFamiliesDecl"
    
    should be expanded fully
    name="ObligationFamiliesDeclaration"
    
    
    erik@axiomatics.com wrote:
    > This is a major rewrite of the obligation families profile.
    > 
    > Summary of changes:
    > 
    > - Use