Higher education and research federations are using the eduPerson schema, where eduPersonAffiliation and eduPersonScopedAffiliation is the basic way of handling roles. The only well-defined roles consist of the vocabulary for eduPersonAffiliation, with some local extensions.  Some federations have defined other well-scoped vocabularies for roles in special attributes.  eduPersonAffiliation is used in a large number of applications.

I would like to see some more simple roles for learning, staff duties and high performance computing.  Currently I am trying to gather the information that will make it possible to make some small steps towards semantic interoperability for roles within our community, as requested in a recent report on Strategies for shared administrative services in Norway (Norwegian only) and by several universities.

Learning roles should take up the vocabulary defined in IMS Enterprise, which is used for populating e-learning support systems (Fronter, It’sLearning) for courses: Learner, Instructor, Content Developer, Member, Manager, Mentor, Administrator, TeachingAssistant.  These values are also used in Norwegian Standard NS4170, Person Information Flow in Education (PIFU).  Mappings from the roles in FS, the shared Student Registry are well-defined.

Research roles include project manager, project participant, main author and co-author.  Other research roles may be related to the grid community.  Work on Short Lived Credential Service (SLCS) based on federated login is going to give us more information on the role requirements from the grid community.

Administrative staff comes in the flavors of: finance officers, HR, archivists, IT and student registrars.  All of these groups are present in universities and colleges, and the functions of a staff member is linked to a specific place in the organizational chart.  This should, in theory, make it possible to identify roles and use these roles to limit access to specific services.

Currently the web services seems able to handle information about a single end user, so the roles must be mapped onto each user account (probably in LDAP or such-like).  In addition to this information, there should be restricted meta-information about the groupings/roles themselves available.  And having the roles represented as groups (isMemberOf) in the local LDAPs could be helpful.

Earlier attempts to define semantics for shared roles has failed, mostly due to the inability to define a problem statement.  My problem statement so far:  Define semantics for shared roles that are preventing interoperability or administration of security domains in key IT services for staff administrative services, learning and research in Norway’s higher education.

Still work to do on these issues…  to be continued