RE: Multiple subjects in SAML assertions

[Chris McLaren <cmclaren@netegrity.com>]

I must have nodded out for a second there when we agreed to make this
change.

I assume the discussion that lead to the change included an answer to the
question: "If the various contents of the <Subject> are not asserted to
refer to the same entity, how do we make correlations between
<NameIdentifier>s and <SubjectConfirmation>s? In other words, how do I say
'the identity of the entity named X can be confirmed via method Y'?"

C.

> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> Sent: Wednesday, October 03, 2001 1:55 PM
> To: 'Irving Reid'; security-services@lists.oasis-open.org
> Subject: RE: Multiple subjects in SAML assertions
>
>
> 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.
> pbaker@verisign.com
> 781 245 6996 x227
>
>
> > -----Original Message-----
> > From: Irving Reid [mailto:Irving.Reid@baltimore.com]
> > Sent: Wednesday, October 03, 2001 12:00 PM
> > To: security-services@lists.oasis-open.org
> > 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>
> >
>
>