OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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