We recommend that each CO configure at least one identifier assignment in order to create a unique identifier for each CoPerson in the CO that can be provisioned to and consumed by federated applications such as wikis, mail list managers, and domain specific applications.
The advantage of having federated applications consume the unique identifier and use it as the primary identifier or key for the user is that even if a user's organization changes, and hence her federated eduPersonPrincipalName (eppn) changes, the new eppn can be linked in COmanage Registry to the existing CoPerson record and the same unique CO identifier can continue to be provisioned to the application so that the user does not lose access to the application during the transition from one home organization to another.
Often the unique identifier is provisioned to LDAP using the Registry LDAP Provisioner and then either the application is configured to consume it directly from LDAP or a SAML attribute authority (AA) is configured to resolve it from LDAP and then the SAML service provider for the application queries the AA to consume the identifier.
Since some applications, particularly legacy applications, have specific requirements for user identifiers (eg. the identifier must take the form of an email address but can only have 8 characters) it is fairly common to configure more than one CO unique identifier assignment to support a mix of general and specific application requirements.