RE: Multiple subjects in SAML assertions

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

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>
>

Phillip Hallam-Baker (E-mail).vcf