[security-services] Action Item A23

[Chris McLaren <chris.mclaren@ieee.org>]

Proposal:
Eliminate the <SingleAssertion> Element and SingleAssertionType.
Rename the <Assertion> element to <AbstractAssertion>.
Rename <MultipleAssertion> to <Assertion> and MultipleAssertionType to
AssertionType.

Rationale:
In the current core the <Assertion> element is of type AssertionAbstractType
and contains assertion header data and no statements. <SingleAssertion> is
of type SingleAssertionType and contains assertion header data and exactly
one statement. <MultipleAssertion> is of type MultipleAssertionType and
contains assertion header data and ZERO or more statements.

There are a number of problems with this.

First of all it is entirely possible to construct a SAML assertion
containing one statement in two valid ways: as either a <SingleAssertion>,
or as a <MultipleAssertion> that contains exactly one element. In general we
want to avoid creating languages that allow you to say the same thing
different ways--primarily to avoid the possibility of implementers drawing a
distinction between the two cases.

I would suggest doing away with the <SingleAssertion> element and type
altogether, since it's functionality is entirely incorporated into the
<MultipleAssertion> element and type.

Theoretically we lose the benefit of being able to make slightly more
efficient systems for cases where it is KNOWN that only single statements
will be contained in the assertions passed. I would assert that this benefit
is illusory, but that even if it were real in some cases it's loss is
certainly outweighed by the fact that general SAML systems would not have to
handle both <SingleAssertion> and <MultipleAssertion> elements--without even
considering the general gain of avoiding the "two ways to say one thing"
problem.

Secondly there is the problem of the <Assertion> element. I assume that it
is declared to allow people to specify that other elements will contain an
"assertion", and that the intention is that in practice this will be
populated with an descendant type that is identified via the xsi:type
notation. In other words, I think the intention is that no one will even
create an <Assertion> element that actually has the "AssertionAbstractType"
type--they will only ever use it as a placeholder to indicate that a
descendant of the "AssertionAbstractType" should be inserted. If this is the
case then I suggest that we make this explicit by renaming the <Assertion>
element to <AbstractAssertion>.

Thirdly, we can now rename <MultipleAssertion> to <Assertion> and
"MultipleAssertionType" to "AssertionType".

The result:
A core where the <AbstractAssertion> element is of type
"AssertionAbstractType", and contains only assertion header data, and the
<Assertion> element--which is of "AssertionType" contains assertion header
data and zero or more statements.

No new schema is required, only changes to this:

	<element name="AbstractAssertion" type="saml:AssertionAbstractType"/>
	<complexType name="AssertionAbstractType" abstract="true">
		<sequence>
			<element ref="saml:Conditions" minOccurs="0"/>
			<element ref="saml:Advice" minOccurs="0"/>
		</sequence>
		<attribute name="MajorVersion" type="integer" use="required"/>
		<attribute name="MinorVersion" type="integer" use="required"/>
		<attribute name="AssertionID" type="saml:IDType" use="required"/>
		<attribute name="Issuer" type="string" use="required"/>
		<attribute name="IssueInstant" type="dateTime" use="required"/>
	</complexType>

and this:

	<element name="Assertion" type="saml:AssertionType"/>
	<complexType name="AssertionType">
		<complexContent>
			<extension base="saml:AssertionAbstractType">
				<choice minOccurs="0" maxOccurs="unbounded">
					<element ref="saml:Statement"/>
					<element ref="saml:SubjectStatement"/>
					<element ref="saml:AuthenticationStatement"/>
					<element ref="saml:AuthorizationStatement"/>
					<element ref="saml:AttributeStatement"/>
				</choice>
			</extension>
		</complexContent>
	</complexType>