Multiple subjects in SAML assertions

[Irving Reid <Irving.Reid@baltimore.com>]

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.