FTF #3 Contribution for core assertions

[Phillip Hallam-Baker <pbaker@verisign.com>]

All,

	In order to keep to the deadline set (sorta) I enclose a revised
core assertions draft and a revised schema. Since Bob has graciously stated
he will allow submissions up to Monday I suggest folk with issues on the
docs raise them before that time.

I have not yet got the schema through a validator, am working on that issue.

The major change is to reorganize the draft so that it conforms (with minor
discrepancies) to the class diagrams being circulated. The schema now
specifies a toplevel <SAMLAssertionPackage> element which wraps basic
information arround a sequence of <Claims> <Conditions> <Advice>.

The new schema makes heavy use of abstract types. This seems to me to clean
things up remarkably. Extension schemas can define elements that are only
for use as a claim or a condition or whatever. Strong typing and all that
good stuff.

In the process I have nuked all but one of the occurences of ##any (in the
advice element where it is anything goes in any case).

The new draft does not preclude further reorganization. However if we wanted
to percolate the assertion type further up the structure the changes would
be less than before.

I have not added support for conditions on a per claim basis, however I have
indicated in the schema where that support would go as a comment.

I have added in one possible means of supporting the <AssertionRef> idea
floated on the list. We do not have support for transclusion at this point
however, the semantics are 'I got the subject from this assertion' and not
'get the subject from this assertion yourself' as Prateek suggests. There is
an option for defining extension subject types however (and it is only the
subject where I think the issue is likely to be critical). The main reason
for wanting transclusion as opposed to an advisory reference is that with
transclusion you can force the relying party to locate the dependent
assertion and take note of the relevant conditions.

I have not yet got the examples draft rejigged to match. Will do that over
the weekend and next week. I also suggest that we write a trial extension
schema to see if the mechanism really works in practice. It may look
unimportant but I have a lot of folk asking me if XACML is meant as a
competitor to SAML, It would be good for PR if XACML assertions can appear
wrapped in the SAML package so that folk realise that the policy statements
are an extension of the SAML scope and not a competing scope.


		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

Phillip Hallam-Baker (E-mail).vcf

draft-sstc-core-08.doc

saml.htm