Question - why only one IFI?

[rayaskew]

Hey, new to xAPI this year and looking to understand what the logic is behind limiting to only allowing a single IFI per Actor (Agent). I ask because the use of email vs employee ID seems to be heterogenous enough such that allowing inclusion of one or more unique IDs should be okay in order for more universal interoperability across the LMS/LRS ecosystem.

Thanks in advance for any information on this.
Ray

[thomasturrell]

I would suggest using the account Inverse Functional Identifier. The account IFI can represent a single sign on account. The authenticating server can store (and maintain) other identifiers of the user.

The more you store the more you have to maintain and protect, it should be remembered that statements are immutable and can only be voided and not deleted.

In my opinion the other Inverse Functional Identifiers defined in the specification should be avoided. Many users are concerned about sharing their email address, SHA1 is too weak and OpenId is deprecated.

[brianjmiller]

In a much earlier version of the specification (up through Tin Can 0.9) the Agent/Group objects allowed arrays of identifying information, and based on very early usage of the specification it became quite clear that allowing more than one piece of identifying information became problematic very quickly. In real life circumstances as soon as this was applied someone would mistakenly include multiple identifiers, but for different entities and things on the reporting side got very ugly from there. Ultimately it was decided that it would be most practical to limit identifiers to a single piece of identifying information per object and that mapping of multiple identifiers (ultimately what is considered a Person) would be up to an external system (or at least outside the minimal requirements of the LRS).

As far as the list of available IFIs, this was essentially done to match another specification that appeared that it would become popular at the time, specifically FOAF (Friend of a Friend) (I'll let readers Google that one for themselves).

I tend to agree with Thomas' take that an account is most practical though I don't know that the others will or even should get removed.