[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC