OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: 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



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


Powered by eList eXpress LLC