RE: SAML FTF draft #3 contribution deadline

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

I am trying to work out how to revise the core assertions piece while not
writing large chunks of text that are likely to be discarded or going beyond
current consensus.

Current plan:

1) Leave the Protocol section more or less as it is but with minor tweaks
since this will either remain pretty much as is or require a complete redo

2) Rename the <Assertion> element <SAMLAssertionPackage> for reasons
discussed on list.

3) Promote (demote?) elements to attibutes as discussed.

4) Rejig the assertions structure as follows (after prolonged reading of the
XML Schema spec)

<SAMLAssertionPackage [Basic info as attributes]>
    <Claims>
        <AbstractClaimType> *
    <Conditions>
        <AbstractConditionType> *
    <Advice>
        <SAMLAssertionPackage> | ANY

<SAMLQueryTemplate> = <SAMLAssertionPackage>

<AbstractClaimType> ->
    <AuthorizationClaim> |
    <AttributeClaim> |
    <DecisionClaim> ...

<AbstractConditionType> ->
    <AudienceRestriction>

I am still trying to work out the implications of the various #ANY like
mechanisms. What I think we want is to allow extension schemas to declare
new claims and conditions by extending the relevant abstract types but not
put any old junk in there.

My reading of the spec suggests that if we have extension schema foo.xsd
then the following would be legitimate XML?

<SAMLAssertionPackage xmlns:foo="foo.xsd">
   <Claims>
      <foo:AccessControlList>

Is this the case? I can either work on the document reorg today or get my
validating parser to behave.

If we end up introducing separate assertion packages then the distance from
the new draft to the end point should be much smaller.

5) Description of Assertion claims types.

I will leave these blank for now since I am sure there will be use case text
to be snarfed.

		Phill


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

Phillip Hallam-Baker (E-mail).vcf