On Aug 9, 2004, at 2:14 PM, Scott Cantor wrote:
>> 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.
In Liberty ID-FF 1.2 conformance testing, this simply meant that a
target SP was able to decode the encrypted name identifier that was
produced for it by an IDP. As a practical matter, it's hard to bless an
IDP's implementation of NameIdentifier Mapping without having an SP
implementation to consume the result, at least where encryption is
involved. I can see how this isn't (as much of) an issue in use cases
where privacy concerns don't require encrypting name identifiers, but I
think it's still nice to have an end-to-end test.
> 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
-Greg
