RE: Multiple subjects in SAML assertions

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

The objection that was made is that the original wording allows a SAML
assertion to be used to create an implicit assertion about the
authentication credentials of Alice.

The feeling was that any such assertion should be explicit rather than
implicit.

I seem to recall that I entered the change during the call. I am not
claiming that it is best wording, but clearly the original wording was not
the intended meaning. We might want the ability to make such a statement but
is certainly should not be implicit.


The point is that when Alice authenticates herself to the merchant PEP and
the merchant retrieves the artifact the merchant probably wants to say
something like 'hello Alice here are your personal recomendations'.

The problem is that Alice might have more than one name, a user name and a
real name, etc. so it seemed a good idea to say that they should all be the
same.


Perhaps what it needed is to distinguish between the authenticated name and
a subject name. The first is an output of the authentication server 'the
person with the abc artifact is called "Fred", the second is an input to the
PEP "The person you call Alice has the 'engineer' attribute. 

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Chris McLaren [mailto:cmclaren@netegrity.com]
> Sent: Wednesday, October 03, 2001 1:50 PM
> To: security-services@lists.oasis-open.org
> Subject: RE: Multiple subjects in SAML assertions
> 
> 
> 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>
> > >
> >
> >
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>

Phillip Hallam-Baker (E-mail).vcf