[security-services] Assertion Specifier as Subject

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

As the F2F the issue of the Assertion specifier in the subject was raised.
currently there is almost no text to support this use and nobody could
remember the use case justifying its inclusion.

The only justification I can remember is that there might be a legal
distinction between specifying the subject directly or through an assertion.
For example Alice says to the service 'X is true, should I trust Y?', if the
service replies 'trust Y' the service has greater legal risk than if it says
'on the bassis of your assertion that X is true, Y is trustworthy'.

While this is an interesting use case I suspect that it is better dealt with
using Conditions.


Proposal:

	REMOVE the Assertion Specifier from the subject element and
supporting text.


This would change 1.4.2 to read:
The <Subject> element specifies a party by any of the following means:
	*	A name.
	*	By information that allows the party to be authenticated.
	[*	By reference to another assertion or by containment of
another assertion.]
If a <Subject> element contains more than one subject specification the
issuer is asserting that the statement is true for all of the subjects
specified. For example if both a <NameIdentifier> and a
<SubjectConfirmation> element are present the issuer is asserting that the
statement is true of both parties.
The definition of a <Subject> element that intentionally identifies more
than one principal is deprecated.
The following schema defines the <Subject> element:
	<element name="Subject" type="saml:SubjectType"/>
	<complexType name="SubjectType">
		<choice maxOccurs="unbounded">
			<element ref="saml:NameIdentifier"/>
			<element ref="saml:SubjectConfirmation"/>
		[	<element ref="saml:AssertionSpecifier"/>]
		</choice>
	</complexType>


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227 <<Phillip Hallam-Baker (E-mail).vcf>>

Phillip Hallam-Baker (E-mail).vcf