[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Subject confirmation (was RE: Multiple subjects in SAML assertion s)
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > 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. This leaves us with no way in the standard to link a <SubjectConfirmation> with a <NameIdentifier>, as Chris pointed out in his follow-up. It also still leaves open the question I raised in my Multiple Subjects message http://lists.oasis-open.org/archives/security-services/200110/msg00029.html, about what a Relying Party should do when faced with an AuthenticationAssertion with more than one <NameIdentifier> in its <Subject>. > Conditions is not the place to put subject confirmation. > Phillip Hallam-Baker FBCS C.Eng. A number of the suggested uses for the existing <SubjectConfirmation> element feel like Conditions to me. For example, the SOAP profile that Prateek presented at F2F4 put a ds:KeyInfo into <SubjectConfirmation> to indicate that an assertion was only applicable in the context of a document signed by the corresponding key. That, to me, certainly belongs in <Conditions>. Perhaps we need to clarify the distinction between: (1) Authority asserts whatever about Subject, and only wants RelyingParty to rely on this assertion if presented by holder-of-key (or similar mechanism) and (2) Authority asserts whatever about Subject, only wants RelyingParty to rely on this assertion if presented by holder-of-key, *AND* asserts that holder-of-key is Subject and the slightly less strict (3) Authority asserts whatever about Subject, and if RelyingParty cares, it can verify that the presenter is the Subject by checking holder-of-key I'm using the phrase "presented by holder-of-key" in a rather generic sense to refer to any way that the RP can determine that a principal involved in a process satisfies the <SubjectConfirmation> criteria - could be because that principal signed a document containing the assertion, presented a SAML Artifact (corresponding to the assertion) over an HTTP/SSL connection with client certificate, etc. My feeling is that (2) is what most people mean when they say SubjectConfirmation, and I think that's as good a definition as any. I think we still need to change the <Subject> schema to enforce the correspondence between <SubjectConfirmation> and <NameIdentifier> elements (if there is one). Bob Blakley's message http://lists.oasis-open.org/archives/security-services/200109/msg00041.html suggests that <SubjectConfirmation> is only meaningful in an assertion. Unless I'm misreading his intent, it would not be possible to make a SAML Protocol request, asking an attribute authority for attribute assertions corresponding to a <SubjectConfirmation> subject. To me, this implies that an assertion _must_ have a <NameIdentifier> in its subject if we want an RP to be able to request other relevant assertions. With that in mind, I'd be happy if we simplified the <Subject> schema to: <element name="Subject" type="saml:SubjectType" /> <complexType name="SubjectType"> <sequence> <element ref="saml:NameIdentifier"/> <element ref="saml:SubjectConfirmation" minOccurs="0"/> </sequence> </complexType> - 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC