garemoko
commented
8 years ago This is deliberately ambiguous as there are no interoperability issues around how the LRS gets this data, or even if it bothers to associate personas under people. The LRS is free to get this data however it likes.
I can, however, give you a real world example here..
Watershed LRS does offer persona association as a feature. This means that report creators can filter and group by person, rather than personas. We have a separate API that we hook into HR systems, LRSs etc. to get that data.
There's an example of one such integration, in this case with Moodle LMS, here: https://github.com/WatershedLRS/moodle-report_watershed/blob/master/classes/task/update_people.php
https://github.com/adlnet/xAPI-Spec/blob/1.0.3/xAPI-Communication.md#agentsres
This endpoint is expected to return a person object for a specified agent. The person object is meant to contain all IFI fields and names associated with a particular person. The ambiguity is in how exactly this is to be achieved.
The spec states that the aggregation information should come from a outside source such as a directory service. Since a single LRS may service multiple organizations, it is likely to require multiple directory services that are maintained by third parties. This introduces a variety of issues such as, having access to the services, having to query a multitude of outside services to aggregate the information, and having to provide a multitude of implementations to access multiple outside services.
Cane additional information be provided on how this is meant to be used and how integration with the outside service is meant to work?