Shibboleth Developers

["Scott Cantor" <>]

> Our different understanding is not whether an ePTID can ever change.
> The causes you mention are valid reasons to change an ePTID.
> However, absent some special agreement or action between the SP
> and IdP, I think an ePTID for a user to a particular SP has to be
> invariant, forever.

The relevant property is non-reassignment. Under various circumstances the
value may change, and of course it's useful to have mechanisms to inform the
SP of that, as SAML 2 does. But a given value is never recycled.

The requirements here from a software standpoint are the same as for SAML 2
persistent NameIDs. That's why we changed the syntax to match it.

The additional requirements that adds are SP affiliations and SP-attached
aliases for the value, which turns it from a triple (IdP, SP/Affiliation,
value) into a quadruple (IdP, SP/Affiliation, value, SP value).

-- Scott