Back before Sakai 2.0, we analyzed the cross-institutional user ID needs and found that the framework needed to support several different person IDs, two of which are:
- Enterprise integration ID : What ties user data together across different software systems. This might be human-understandable or it might not. But it shouldn't be in itself a huge confidentiality risk, and it will probably be difficult to change. (Both of which are good reasons for it not to have much meaning to human beings.)
- Authentication ID : What the user types in as a login identifier is determined by the particular authentication service. It may be the same as the user's display ID which is shown in roster lists, or it may be the same as the service integration ID which ties everything together in software, or it may be a Kerberos principal ID (which is considered private data here at UC Berkeley) or it may be a magnetic keycard code, or a retinal scan, or..... The point is that it can be thrown away after authenticating.
Currently, Sakai supports the notion of an EID, but does not cleanly separate it from the Authentication ID. This blocks Kerberos-based authentication at UC Berkeley and UC Davis. The authentication provider needs to be given a chance to send back an EID (and, if available, other user data).