RE: [saml-dev] Question concerning linking of principals

["Scott Cantor" <cantor.2@osu.edu>]

> So I'm inclined to think a profile of People Service, as you suggest, is
> most appropriate.

ID-WSF, not the People Service. My solution only uses the raw bits of ID-WSF
that give you secure messaging with SAML. The PS is a fully-formed service
on top of that stuff, and while I'm not very experienced with it, I don't
see it as necessary for the basic aggregation problem.

> Do SAML implementations typically provide the levers to make these
> 'after the fact' attribute requests using a different NameID, and
> possibly a different authority, from that given in the original SSO
> event?

I don't know. Probably not without effort.

> For example, does the Shibboleth 2.0 SP Attribute Resolver
> support this kind of operation? I'm trying to understand what would make
> life easiest for the application developer...

That's easy, use a global ID. ;-)

Yes, my SP's resolver API is designed for this use case, and I'm pretty sure
it's possible to do it, because I thought about it a lot while designing the
API. But it's certainly not implemented. The API just lets the rest of the
SP function without knowing where the attributes came from and allows a
uniform set of processing after the resolver runs.

-- Scott