RE: CORE draft 0.7 plus examples

MHonArc v2.5.2 -->

















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: RE: CORE draft 0.7 plus examples




From: Phillip Hallam-Baker <>
To: Hal Lockhart <>,'Phillip Hallam-Baker' <>,"''"<>
Date: Wed, 06 Jun 2001 04:33:21 -0700






Title: RE: CORE draft 0.7 plus examples




  
    
     
    As you say, tending towards policy. However it is 
    important to keep in mind that we want to support SAML and XACML in a 
    coherent framework. My belief is that the SAML subject and object elements, 
    plus some sort of inference calculus equals XACML.  
  I take the strongest exception to 
  this. I see SAML as providing an interim, limited functionality where many of 
  the inputs that went into a policy decision are "invisible" to SAML. For that 
  reason I was willing to live with what I consider the very limited 
  subject/object paradigm to avoid a protracted debate. However, if XACML is 
  going to be chained to the limitations of whatever we specify right now for 
  SAML, I want to raise it as an 
  issue.
   
  I see two 
  issues:
   
  1. Should the XACML be constrained to the assertion 
  claim structure defined by SAML? Obviously this is a XACML issue, so I 
  have copied the other list.
   
I don't think the XACML group should (can) be required 
to accept any SAML work. However I think that SAML should where possible look to 
leave open the option to XACML to make use of SAML 
components.
 
The only constraint I think we can usefully put on 
XACML is that where SAML defines an element XACML should not reuse the same 
element name to mean something different. Expanding an element to allow more sub 
clauses would be OK but two different semantics for <foo> would be a 
disaster.

  2. Assuming the answer to #1 is yes, Should SAML 
  assertion claims be structured around 
  subject/object?
   
  For the sake of example, a resource centric claim 
  might look something like this:
   
  Evidence
    Assertion 
  Reference
    Authentication 
  Method
    
  Date/time
    
  Intermediaries
    
  Location
    
  Subject
  Resource
    
Object
    
  Operation
    
  Signature
    
  Instance
   
I am missing something here, I still don't see what the 
distinction that you are trying to draw is.

  
    The AssertionID provides a unique reference for the 
    assertion. This in AI lab ideology turns it into a first class object, which 
    in the AI lab catechism is 'A Good Thing (tm)'.
    Within SAML 1.0 the principle use of an AssertionID would 
    be to allow one assertion to reference another (see previous Tim discussion) 
    thus allowing statements of the form 'this assertion was constructed from 
    that assertion'.
    The principle use of the AssertionID however would be in 
    systems built around SAML, they provide the basis for audit and 
    accountability for example. If a system is built that allows for second 
    order logic (assertions may be true or false and other assertions may make 
    statements about validity (c.f. TASS meta-assertions)), then an assertionID 
    is essential. 
  You 
  misunderstand me. I was not asking  what 
  Assertion IDs are for in general, specifically in a query. If I had to guess, 
  I would speculate that you want to specify the id of an assertion that already 
  exists. If so, this should be stated. Also I would like to see some rules 
  about what the asserting party is supposed to do if the assertion doesn't 
  exist or if the specified assertion doesn't have the other information 
  requested, etc. 
O.K. will take as an action item. 

  
    By definition the Advice field can contain anything, 
    however a SAML processor is not required to understand it. It is only 
    required not to barf if it sees something in Advice that it does not 
    understand.
    When we have a policy language I think we will find the 
    Advice field useful for stating the reasons why a request was permitted or 
    denied. However I suspect that that whole area tips us into policy. 
  Sounds good, 
  can you document this?  
   
O.K. 
will expand on the description. 
 
Phill
Phillip Hallam-Baker (E-mail).vcf












[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]


  









Powered by eList eXpress LLC