RE: [saml-dev] strongly matches

["Scott Cantor" <cantor.2@osu.edu>]

> - What does it mean for one NameIdentifier to be "identical" to
> another?  In particular, if one NameIdentifier has no Format attribute
> while the other has a Format value of 'unspecified', are the two
> NameIdentifiers "identical"?

For the purposes of the use cases that reference strong matching, yes.

> - It appears that S1 may have more SubjectConfirmation elements than
> S2, as long as every SubjectConfirmation element in S2 has an
> "identical" counterpart in S1.  Correct?

I suspect that's true, yeah, assuming you can define "identical", which I
don't think is well-defined here. I read it as being fairly strict and
having something to do with the XML. But that's why I used the word
identical in 2.0 when I discussed things like whether two BaseIDs match. If
it's not related to the raw XML, I couldn't figure out what it could mean.

Even that doesn't really help anything, since XML equivalence isn't
well-defined. Looking at it now, I think 2.0 needed to clarify that and
didn't.

> - If the answer to the previous question is yes, then "strongly
> matches" is clearly not symmetric.

Should it be? I don't see any reason for that.

> SAML 2.0
> 
> - Same question about "identical" NameIDs.

Same answer. NameID is a pathological case.

> - I do not understand the condition on SubjectConfirmation elements at
> all.  Can somebody explain this to me?

It's complicated. It's explicitly acknowledging the impossibility of trying
to define what it means for two confirmation elements to be "equal", since
the notion of confirmation isn't well-defined without more context. This was
the problem with the word "identical" in the original spec, and this
eliminates the illusion that you can do it.

For an example, consider a query which includes (roughly):

<SubjectConfirmation Method="...holder of key">
	<SCData>
		<KeyInfo>
			<KeyName>Name of Key</KeyName>
		</KeyInfo>
	</SCData>
</SubjectConfirmation>

It's plausible for the result to "match" if it contains:

<SubjectConfirmation Method="...holder of key">
	<SCData>
		<KeyInfo>
			<X509Data>
				<X509Certificate>...</X509Certificate>
			</X509Data>
		</KeyInfo>
	</SCData>
</SubjectConfirmation>

It has to be possible for this to "match", or the spec is invading territory
it doesn't control. In SAML 1.1, the language seemed to imply that the XML
itself had to match in some way. In 2.0, what matters is that the parties
consider the implications of the two confirmations to be "consistent". This
is critically important with AuthnRequest, which reuses some of these rules.

There are an infinite number of cases with holder of key alone because
KeyInfo is an open content model. SubjectConfirmationData is also, so the
issue extends beyond holder of key. Bearer is the pathological case.

It's far from clear that all this works or is interoperable (actually quite
the opposite). What was clear was the original text didn't because it
precluded things that had to be legal.

-- Scott