> I would support addition of transient and one-time NameID format and
> affiliations into all of the SP and IdP conformance modes. My reading of
> the ID-FF 1.2 SCR is that these were considered separately purely
> for historical reasons (developed later in the game).
That was also my feeling.
> One question is whether we need to add more text to conformance
> enumerating these features, or whether it is enough just to strike the
> two columns from the extended IdP/SP matrix.
I think it would at least be necessary to say that all of the formats (and
semantics) defined in section 8.3 are MTI (if that's what we mean).
> NameID Mapping and IdP proxying feel like somewhat more heavy weight
> features. My suggestion would be to maintain an extended IdP/SP
> operational mode that incorporates these features.
Basically agree, but I'm still not clear on how an SP specifically
"supports" NameIdentifier Mapping. I would hope for some help from Liberty
on what that meant exactly.
There were in fact no use cases in ID-FF that required it, I argued for its
inclusion as a means of crosswalking between ID-FF and pure SAML
environments and as a huilding block for other profiles. So I don't know
what the conformance scenario was on the requesting side.
-- Scott
