Shibboleth Developers

["Scott Cantor" <>]

> My issue with this approach, if I understand the mechanics correctly,  
> and this is purely an issue with today's implementations - is that  
> the Shib AA demuxes on the Format attribute to call the appropriate  
> namemapper plugin. Since the encrypted handle approach shares with  
> the default Shib Handle, in practice this means a Shib IdP can do one  
> or the other. Meaning if we go this route, folks have to use a non- 
> default IdP configuration (encrypted vs regular handles).

Nobody uses the memory implementation today if they're serious about the
software. It's not usable in a cluster, and this is a service that has to be
reliable. Chad's extension is a possible alternative, but even then I think
it's a replacement/extension for the in-memory mapper, though I could be
wrong about that.

So there's "default" and there's "useful in anything but a pilot".

> Now I understand from a technology perspective, it should all just  
> work, but I'm concerned from a deployment perspective that if we tell  
> folks, "you can use our stuff, you just have to change how your IdP  
> does handles for all clients and SPs" they are very likely to go  
> "yeah, right" and even if they do take this path, they end up in a  
> murky backwoods of the community since it's not the Shibboleth default.

It is the only practical version used in Shibboleth today. It's not the
default only because it requires generating a key.

-- Scott