Core 20 states:
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.
Conditions is not the place to put subject confirmation.
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
781 245 6996 x227
> -----Original Message-----
> From: Irving Reid [mailto:]
> Sent: Wednesday, October 03, 2001 12:00 PM
> To:
> Subject: Multiple subjects in SAML assertions
>
>
> During the 18 Sept. SSTC/Focus conference call, I raised an
> issue about the
> fact that in the draft schema, <Subject> elements can contain
> an arbitrary
> number of <NameIdentifier>, <SubjectConfirmation>, and
> <AssertionSpecifier>
> elements.
>
> <Subject> elements are used (at least) in Assertions and in
> SubjectQuery
> protocol messages.
>
> In the last published Core document,
> http://www.oasis-open.org/committees/security/docs/draft-sstc-
> core-15.pdf,
> the supporting text states that "If a <Subject> element
> contains more than
> one subject specification the issuer is asserting that all the subject
> specifications present specify the same subject."
>
> For the rest of this message, I'll base discussion on the -19
> schemas Phill
> sent out in
> http://lists.oasis-open.org/archives/security-services/200109/
> msg00073.html;
> there have not been substantive changes to the <Subject> element.
>
>
> One of the reasons to allow multiple subject specifiers
> within the <Subject>
> element is to allow for a <NameIdentifier> and a
> <SubjectConfirmation>, such
> that the confirmation data and method corresponds to the
> NameIdentifier. The
> current schema doesn't quite work for this, since there could
> be more than
> one of each and there is no way to determine which
> <SubjectConfirmation>
> applies to which <NameIdentifier>. Frankly, I think we need
> to re-think the
> entire <SubjectConfirmation> issue, but that's for a different thread.
>
> Another use for multiple subject specifiers was brought up by
> Phill on the
> 18 Sept. call. In this case, a single real-world entity has
> multiple digital
> identities. For example, Phill might have separate private keys and
> certificates on each of his laptops, his cellphone, PDA, and
> workstation. An
> issuing authority may want to provide an assertion that
> applies to all those
> identities.
>
> For this case, Phill suggested that it might be OK to have
> the assertion
> apply "jointly and severally" to all the subjects listed in
> the assertion,
> with no implication that all the subjects somehow represent
> the same entity.
>
>
> My main problem with all of this is that it opens a lot of
> questions about
> how the relying party is supposed to behave when it gets assertions
> containing multiple <NameIdentifier> elements.
>
> For attribute assertions, it's not too difficult - as long as
> the relying
> party starts with a single NameIdentifier, it can figure out
> which attribute
> assertions apply. To me, this case is an optimisation - instead of an
> authority generating a separate attribute assertion for each
> subject, it can
> take a shortcut and generate a single assertion for a group
> of subjects that
> all have the same attribute.
>
> In the context of Web SSO applications, I'm more concerned about the
> possibility of AuthenticationAssertions with more than one
> subject. As far
> as I can tell, the relying party must now query for desired
> attributes for
> all the subjects in the AuthnAssertion, and resolve possible conflicts
> between those attributes. I don't want to spend the time in
> SSTC trying to
> define the semantics of this before SAML 1.0; I think we have
> more important
> things to do.
>
>
> While I'm debating the content of the <Subject> element, I
> also dislike the
> <AssertionSpecifier> element. The intended semantics of this
> element are:
> The assertion containing the <AssertionSpecifier> subject
> element applies to
> exactly the same subject as the assertion referred to by the
> <AssertionSpecificer>. If this is really what we want, why
> not just copy the
> <Subject> element from the referent into the new assertion,
> rather than
> putting in the <AssertionSpecifier>. With the existing schema
> and semantics,
> we're forcing the relying party to find the other assertion
> just to copy its
> <Subject>.
>
> The other reason I don't like <AssertionSpecifier> is that it
> will confuse
> people into thinking that one assertion can have another
> assertion as its
> subject, rather than our intended "copy-the-subject" semantics.
>
>
> So, my proposal is to drastically reduce the scope of the
> <Subject> element
> so that, for SAML 1.0, it contains exactly one
> <NameIdentifier> and nothing
> else. The <SubjectConfirmation> element should move into
> <Conditions>, and
> probably be renamed. I'll start another email thread about that.
>
> As far as I can tell, this satisfies all the use cases in the
> Use Cases and
> Requirements document
> (http://www.oasis-open.org/committees/security/docs/draft-sstc
> -saml-reqs-01.
> pdf). We can make the <Subject> element extensible, so that we can add
> alternatives when we work out clear semantics for them.
>
>
>
>
> - irving -
>
>
> --------------------------------------------------------------
> ---------------------------------------------------
> The information contained in this message is confidential and
> is intended
> for the addressee(s) only. If you have received this message
> in error or
> there are any problems please notify the originator immediately. The
> unauthorized use, disclosure, copying or alteration of this
> message is
> strictly forbidden. Baltimore Technologies plc will not be
> liable for direct,
> special, indirect or consequential damages arising from
> alteration of the
> contents of this message by a third party or as a result of
> any virus being
> passed on.
>
> In addition, certain Marketing collateral may be added from
> time to time to
> promote Baltimore Technologies products, services, Global
> e-Security or
> appearance at trade shows and conferences.
>
> This footnote confirms that this email message has been swept by
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
