1) If both NameIdentifier and SubjectConfirmation are present
> does that mean that a relying party (for the containing assertion)
> MUST/SHOULD/MAY check the s-c value as part of assertion validation?
> core-25 seems to imply this is a MAY, but I'd rather it be
> explicit (I don't mind which is chosen really).
I think it is quite clear that this needs to be no stronger than
MAY. Otherwise we force Authorities to go through a burdensome and
complex process that is unnecessary in many cases.
> 2) One 1)'s answered, then same question for the case where there's
> only a SubectConfirmation. I guess a MUST might be more easily
> argued in this case?
The relying party will make whatever decision is best for them. MUST
is not only unnecessary, it is pointless.
> 3) Let s1 = <Subject><n-i=fred/></Subject> and
> s2 = <Subject><n-i=fred/><s-c=fred-cert/></Subject> (i.e. s2
> is s1 with the addition of a SubjectConfirmation). Now, when
> do I consider s1=s2 and when not? E.g. if I send you an
> AuthenticationQuery containing s1 and you send me back an
> assertion containing s2, is that ok? In this case I've no
> suggested answer, since I don't believe I understand the
> consequences well enough - maybe someone else does?
You may consider the two to be equivalent for the purposes of the
assertion only. So for example it is quite likely that you have a
name-identifier that may be ambiguous.
What we want to avoid is the situation in which people start to
use base SAML assertions to create an implicit certificate for
a subject/subject name binding. While there is nothing to stop
people using such assertions for freeswan like opportunistic
crypto we certainly don't want to establish a reliance or
warranty model without being very explicit about it.
> Finally, given that these questions arise, I guess I should
> ask whether its really a good idea to couple the s-c stuff
> with the Subject instead of including it elsewhere in the
> assertion or protocol constructs?
It is a part of the subject definition.
Phill
