Shibboleth Developers

["Scott Cantor" <>]

> If the user says don't release the persistent opaque identifier, it is 
> *replaced* by the transient one.

Alternatively you return an error. That's something we can do now that
wouldn't have been possible before. If an SP requests a particular kind of
identifier that it can't have, the proper response is to say "no", not just
return something different.

> For what it's worth, that does sound like the right approach to me, I 
> just can't think what the details will look like yet.

Neither do I, I just think that it will be impossible to understand
otherwise.

> I suppose the trick is to be able to achieve things like:

You left out NameIDPolicy, which is the more significant part. Metadata
might be a factor, but mostly it's what the SP asks for.

This is another reason why sticking with persistent and transient as the
design focus makes things cleaner. SAML doesn't permit an SP to say "I want
an identifier with certain properties". Some people might prefer that, but
that's not how it works. And nothing except for transient and persistent
have any useful properties that could be defined.

> I suppose it is possible to do most of that explicitly in the ARP, but I 
> can't see how you would model it all purely by the current attribute 
> filtering model.

You can't, but I think the ARP can simply indicate what the user permits and
the rest could just be implemented as the logic of the response. The point
is for the permissions to cover the identifier types the user wants to
permit (as well as potentially tracking consent to federate, to use the
Liberty term).

-- Scott