RE: CORE draft 0.7 plus examples

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