[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FTF #3 Contribution for core assertions
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC