Shibboleth Developers

["Scott Cantor" <>]

> One practical issue would be related to services that provide different 
> levels of functionality, such as optional personalisation, depending on 
> whether a persistent identifier is available for the subject.

I think the context is lost here...I said I didn't see why I would use the
attribute version in SAML 2.0 when I can just carry the data in the subject
and save the space.

As Tom noted indirectly, though, you do have to acknowledge the issues of
phishing and presence. If I support persistent IDs, then I either explicitly
shut-off queries or I give the SP the ability to ask any time.

In any case, there's no way we're going to somehow *not* support the
attribute, so it's a moot point. We have enough to argue over without
including stuff nobody is actually disagreeing about.

> On the IdP side, at present such things are controlled by the ARP, which 
> is purely a filtering mechanism.  Releasing or not releasing an ePTI 
> would, if that were deprecated, become a *choice* of name identifier 
> formats.  If we think the release filtering should be under the user's 
> control, we'd presumably want that choice to be made by the user as 
> well.  That has implications for tools like SHARPE (even just the name!) 
> as well as user education.

SHARPE has to deal with the unification of subject format and attributes as
well, but presumably through the overall unification in the APIs. The whole
goal is for ARPs and the mappings to merge in some way.

-- Scott