To set the scene, you can download the slides of a presentation I did at Oxford University Computing Services, at the Guanxi summit meeting on October 26th 2004.
Interesting philosophical debate at the moment. You can use Shibboleth to grant access for a student at another institution’s VLE, though currently only Bodington is supported. Shibboleth will handle the procurement of attributes for the user and compare them against the policy map, granting or denying access accordingly.
However, what to do once the student has access? Where is the value to the student when they’re working through content, assessments or participating in online discussions with their peers, all within the remote VLE, if they can’t be identified?
Working within a fully Shibboleth 1.2 namespace, an origin cannot divulge the identity of a user to a target. You could argue that it could mangle the identity to provide an opaque ID but it also has to be temporary. To be of any use though, an ID must be:
- Long lived enough to accumulate enough data for assessment purposes
- Capable of being resolved to an individual at the origin
Once you nit-pick through the Shibboleth 1.2 draft spec it becomes clear that you can pass longer lived identity information by using standard the W3C namespace. So, the next question is – What attribute should carry the ID as a payload?
There are two possible routes for identifying a wrapper attribute for identify transfer between an origin and a target:
- Local vocabulary, specific to a particular Shibboleth trust club, such as the standard LDAP DN
- Global vocabulary, such as eduPerson, that incoming members of a club can prepare to use, mapping their identify info to a known attribute format
A local vocab would in effect be a dialect, possibly restricting new members, as they don’t speak tha language. VLEs don’t have DNs for example. How would you construct a DN from user info in a VLE and what format should it follow? eDirectory dotted or conventional LDAP?
That leaves eduPerson but there are issues, such as suitable attributes possibly being deprecated or restricted in target site scope. Ideally, an origin could produce an opaque identifier as a one off process and use that ID for all target sites that the student visits. eduPerson won’t let you do that.
So what to do? How to come up with a global attribute wrapper for identity information that is both long lived enough for assessment and can be used across multiple targets?