RE: [security-services] Moving subjects up to assertions

Maybe I'm off track, but my thinking was that we could simplify this by
embedding the distinction within the single AssertionType/<Assertion>
structure.

I would propose something like this (forgive the pseudocode notation):

<Statement> of StatementAbstractType (empty)
<SubjectStatement> SubjectStatementAbstractType (<SubjectConfirmation>*)

SubjectStatementAbstractType does not derive from StatementAbstractType.

Then inside AssertionType, you do something like the following (I've tweaked
a few elements to jump the gun on some abbreviations):

	...usual assertion header, conditions, etc.
<choice>
	<sequence>
		<choice>
			<element ref="saml:BaseIdentifier"/>
			<element ref="saml:NameIdentifier"/>
			<element ref="saml:EncryptedIdentifier"/>
		</choice>
		<choice maxOccurs="unbounded">
			<element ref="saml:SubjectStatement">
			<element ref="saml:AttributeStatement">
			<element ref="saml:AuthnStatement">
			<element ref="saml:AuthzDecisionStatement">
		</choice>
	</sequence>
	<sequence>
		<element ref="saml:Statement" maxOccurs="unbounded"/>
	</sequence>
</choice>

So either an assertion is one or more subject-less statements, or it's a
name identifier (of any sort) plus one or more subject statements.

I think this is cleaner, personally, though it hides more of the
distinctions. I guess the point is, where do you want to fork off the
processing model? I don't think, as long as we continue to bottom-type the
statements that are the real content, we need to top-type on this one issue.
An assertion should still be commonly processable in either case.

-- Scott