OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [security-services] Subject identification constraints


[Assuming that we remove Assertion Specifier from the subject]

The aubject element currently allows multiple NameIdentifier and
SubjectConfirmation elements. There have been ongoing problems with the
interpretation of multiple identifiers of each type, are they equivalent or
not? At the F2F the preference was to allow no more than one element of each
type, constraining the schema thus:

Core 19 schema minus the assertion specifier:

 	<complexType name="SubjectType">
 		<choice maxOccurs="unbounded">
 			<element ref="saml:NameIdentifier"/>
 			<element ref="saml:SubjectConfirmation"/>
 		</choice>
 	</complexType>

Would become

The <Subject> element specifies a party by either or both of of the
following means:

·	A name.
·	By information that allows the party to be authenticated.

If a <Subject> element contains both a Name Identifier and a Subject
Confirmation element it is asserted that the specified name is valid for a
party whose identity is established by the specified subject confirmation
method.

	<complexType name="SubjectType">
		<choice>
			<sequence>
				<element ref="saml:NameIdentifier"/>
				<element ref="saml:SubjectConfirmation"
minOccurs="0"/>
			</sequence>
			<sequence>
				<element ref="saml:SubjectConfirmation"/>
			</sequence>
		</choice>
	</complexType>


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