PersistentId / principalName

[Cantor, Scott]

> Well - that's how the StoredIDDataConnector does it. And this works if the
> localId is applicable for this job (persistent, never reassigned,...).

My point was, you shouldn't use one that isn't.
 
> But the other way around (mapping a persistentId to a
> principalName/username/netid/accountname and then use this
> principalName to resolve the user's attributes) gets messed up if I don't
> update the user's principalName in the database in case it has changed
> (StoredIDPrincipalConnector).

Again, I might be confused, but my assumption is that only the localId matters and that should be the lookup key for any attributes, not a "principal name".

> As I not yet have implemented the update of the DB-entries, this is why I can
> generate a persistent eduPersonTargetedID, but not yet a persistent
> SAML2StringNameID.

Meaning you can't reverse the mapping to a principal identity.

I do understand that if you use an unstable underlying identifier, you have problems. I was merely saying "whoa, that's a pretty big red flag and a good reason for not supporting the attribute".

-- Scott