[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] SubjectConfirmation errata
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]