RE: [security-services] SubjectConfirmation errata

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

> 3. If the <subjectconfirmation> element in (2) does not include a 
> <NameId> element, then attesting entity == subject.
> 4.  If the <subjectconfirmation> element in (2) includes a  <NameId> 
> element, compare it to the value of <Subject>/<NameId>.
>       If the two are identical (after normalization), then attesting 
> entity == subject
> 5. Otherwise, attesting entity != subject.

I think the question is whether (4) is realistic. I tend to think it's not,
at least not in the general case. There's no way a relying party could
really base a decision on a normalization that it may not be able to
perform.

I think the point is that, as Ron said, the use of a second identifier is
explicitly exactly that, another identifier. It's up to policy to define
whether that means something important or not, but you can do policy
matching based on that second identifier in a reliable fashion, seems to me.

> I guess the concern here is with the relative indirectness of the 
> process versus the use of a new condition element that signals 
> the issuers intent (attesting entity != subject).

I think the problem is that you'd have to craft language around that
condition that somehow explains that it's not legal to put an identifier in
there that "normalizes" to the same principal as the subject. That seems
like a difficult thing to enforce, but if you wanted to enforce it, I think
it falls within the intent of having the second identifier in there now. In
other words, I don't think it adds anything new, nor solves the problem any
differently.

I've been arguing that whatever you want that condition to do is what the
current schema "means" because it was all about sender!=subject (mostly for
HoK, but not exclusively). So if some more language is needed, we just need
to come up with it and decide if it's in scope for SAML to try and dictate.

> Obviously, there is a cost associated with the latter approach (schema 
> for the new element). But maybe it is worth the expense?

I think the key is the use case, and the use case for the core feature was
this thing. We shouldn't have to allow it to be misused for some other use
case, even if we're not 100% sure how to state exactly what the use case is
yet.

> SenderVouches is a SAML 1.1 legacy. SAML 1.1 HoK assertions are tightly 
> bound to assertion subjects; SV is a one-off that allows others to speak 
> for the subject.

Very weakly though, which is why I never saw it in those terms. There could
have been a key proof included there, but there wasn't. Something else was
going on.

> The generalization of HoK in SAML 2.0 removes the need 
> for use of SV. If appropriate, we could even move to deprecate its use
> in SAML 2.x at some point.

That I certainly agree with.

-- Scott