Right. What's required is that SPs can participate in the conformance
test for NameID Mapping (along with an IDP and one other SP).
From an SCR point of view, this really just means that SPs need to
support encrypted name identifiers.
From a test harness point of view, it means that SPs need some way to
accept the name identifier (or encrypted name identifier) returned from
a name identifier mapping operation and verify that it means something
to them. In Liberty ID-FF 1.2 conformance testing, the name identifier
mapping test involves three entities: SP1, SP2 and IDP. It is assumed
that SP1 and SP2 are from the same vendor and that the vendor's test
harness is set up to convey the result of a name identifier mapping
request issued by SP1 to IDP (with a target of SP2) to SP2 for this
verification step.
-Greg
On Aug 9, 2004, at 5:23 PM, Scott Cantor wrote:
>> 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.
>
> Ok, but I wouldn't call that a test of NameID Mapping. I asked a few
> times
> on calls whether we considered encryption a separate conformance item,
> but I
> got the sense people considered all uses of encryption in core to be
> MTI
> (subject to whatever algorithms we require). So if that's a concern,
> people
> should speak up.
>
> But NameID Mapping is a separate protocol, it just happens to make use
> of
> encryption. And I don't think it's an SP thing, in the sense that we
> define
> SP as the relying party for SSO.
>
> -- Scott
