[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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.
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:EvidenceAssertion ReferenceAuthentication MethodDate/timeIntermediariesLocationSubjectResourceObjectOperationSignatureInstance
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?
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