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

# security-services message

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

Subject: Assertions, claims etc.

• From: Phillip Hallam-Baker <pbaker@verisign.com>
• To: "'security-services@lists.oasis-open.org'"<security-services@lists.oasis-open.org>
• Date: Thu, 07 Jun 2001 08:09:51 -0700

```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