[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Assertions, claims etc.
On the con-call the issue of assertions, assertion lists, claims etc was raised. I thought I would elucidate some of the points raised. First off there is the potential for confusion to arise due to the fact that our assertions have named issuers and the truth of an assertion may be argued ad hominem. In boolean logic I may have two assertions A and B, the assertion A /\ B [A AND B] is also an assertion. In our particular calculus an assertion alway has a named issuer and the trustworthiness of the assertion is dependent on the specific issuer. This 'ad hominem' calculus does not appear to appear in the math textbooks. If we use the notation x:A to indicate 'x claims A', we can form the following substitution rule: x:A /\ x:B ---------- x:(A /\ B) and x:A /\ x:B ---------- x:(A /\ B) However the following substitition rule is not valid: x:A /\ y:B ---!--!--- x:(A /\ B) In order to develop a full calculus we would have to introduce the concept of authority and a means of reducing the assertions in the ad-hominem calculus to predicate calculus statements. This would be policy stuff however and is outside the current topic. What we end up with is the following: An assertion x:A consists of an issuer (x) and a claim A. The other issue that crops up is that of conditions, if we have an assertion x:A with condition P then this is equivalent to x:(P=>A) [x asserts that if the condition P is true then A is true] From a calculus perspective we can deal with assertions of the form x:((P=>A) /\ (Q=>B)) however this leads to a complex XML structure and leads to processing of nested or recursive items. I would much prefer supporting only statements of the form x:((P /\ Q /\ ... T)=>(A /\ B /\ ... F)). Althought this is much less than a full boolean calculus I believe it is sufficient for the SAML use cases. We can state two separate claims and conditions as two assertions x:(P=>A) /\ x:(Q=>B). That raises the question of whether we should only allow x:((P /\ Q /\ ... T)=>(A)) and not the conjunction list of claims. I believe the conjunction list of claims with a shared issuer and conditions and assertionID is valuable because it allows the issuer to make a single statement whose validity or invalidity can be dealt with as a single entity. The issuer can assert that six attributes are bound to the same subject in one go and if the statement is to be revoked (e.g through the session mechanism) the assertion can be revoked in one go. Given our subject matter (authorization) I believe that the most general case is when all the claims in a given assertion either hold or fail together. Note that we do not have a way of stating 'NOT A', we cannot draw infrerences from the revocation of an assertion, the only effect is that we can no longer draw new inferences. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227
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