[Advisory] Sending pupil-level data outside of the school

[Mike Kendall]

All of this seems to be based on the ubiquity of the VLEs.  I have also had conversations recently with smaller publishers who have commented how surprisingly easy it has been to enable Shibboleth once they had decided to do commit to doing it - this is in the context of embc.

I do agree that WAYFLESS urls and sensible ones are necessary.

Mike

-----Original Message-----
From: advisory-admin@talk.naace.org [mailto:advisory-admin@talk.naace.org] On Behalf Of Crispin Weston
Sent: 03 December 2009 08:23
To: 'Paul Browning'; advisory@talk.naace.org
Subject: RE: [Advisory] Sending pupil-level data outside of the school

> Is this not where the UKAMF comes in?
>
> http://www.ukfederation.org.uk/
Hi Paul,
Yes and no! And apologies in advance for the essay.
You have to face the fact that, five years after its initial roll-out for
the schools sector, take-up of Shibboleth, particularly by commercial
publishers, remains poor.
Personally, I have always had my reservations about Shibboleth, believing
that, at least as originally conceived, it implemented an inappropriate, HE
model. It assumed that students would land on whatever resource they wanted
and this resource would call back, via a "Where are you from" service, to
fetch whatever personal data the service required from the identity
provider.
Back in I think 2004, my principle objections were
(1) the clunky "Where are you from" service pretty much defeated the whole
object of single sign-on, which was to make sign-on transparent.
(2) at schools level, students will access resources *through* the VLE
gateway. Given this model and given proper attention to VLE
interoperability, the VLE can handle authorisation transparently without the
unnecessary complexity of Shibboleth (diagram at
http://www.saltis.org/shib.gif).
(3) Shibboleth requires commercial content providers to implement special
authorisation services. This may not be a great burden to larger publishers
(though I understand that the technology has not always been easy to work
with). But it is often prohibitive for small cottage industries which, if
there is to be a healthy supply of innovative learning services, must not be
excluded from the market.
(4) the amount of personal data that gets thrown across the net just to
support an authorisation process which does not actually need any personal
data at all (a product key or school-level username/password might suffice).

My understanding is that Shibboleth has moved in two significant directions
since 2004:
(1) to remove the WAYF by the use of "wayfless urls", the WAYF being found
to be unnecessary where students, as predicted, tend to access content
through the VLE (this addresses problems 1 & 2, though, if you had started
with this assumption, you would not have adopted Shibboleth in the first
place); and
(2) to remove any personal data from the profile, ending up with an
anonymous ID and an affiliation to a school (addressing point 4). As Frances
I think suggests, Shibboleth is not really suited for use as a provisioning
system, which would be better managed by a SIF-like system.
My own view is that both these developments are moves in the right direction
and open up opportunities for convergence between existing SAML/Shibboleth
implementations and new content packaging technologies.
Let me try and explain why I think the convergence is required.
1. Everything is moving, as stated above, in the direction of wayfless urls.
Here is an example of a wayfless url:
https://idp.protectnetwork.org/protectnetwork-idp/SSO?target=https%3A%2F%2Fg
abriel.lse.ac.uk%2Fsimon%2Fcgi-bin%2Fprintenv.pl&shire=https%3A%2F%2Fgabriel
.lse.ac.uk%2FShibboleth.sso%2FSAML%2FPOST&providerId=urn%3Amace%3Aac.uk%3Asd
ss.ac.uk%3Aprovider%3Aservice%3Agabriel.lse.ac.uk
This essentially combines the URL of the site being visited with all the
information required to manage authentication via a particular identity
provider. These wayfless URLs need therefore to be created separately for
every institution and for every specific link which the institution wants to
provide for its learners. The creation of wayfless URLs may be a trivial
task for university computer departments, but for a small primary school, I
suspect that it is a bit of a show-stopper.
There is a need for content to be disaggregated, so that teachers can send
their students straight to the particular piece of content that is required
for a lesson or homework - this means that there need to a lot of very
teacher-specific links to be created.
What is needed is for content to distributed (in content packages) without
any school-specific authentication and authorisation data, but with whatever
data is required to enable the VLE to add automatically the learner-specific
authentication and authorisation data required to access the remote site
transparently.
Transparent authorisation of disaggregated content is an essential
prerequisite for the effective integration of content with VLEs - and
Shibboleth, even after 5 years of development, does not yet provide a viable
solution.
2. The publishing industry perceives that a key pedagogical requirement is
to achieve data integration with the school VLE, e.g. for the storing of
marks in a common markbook, the saving of state and the returning of student
product for marking and sharing. This requires that third-party content
calls back to an API provided by the school VLE. If content providers need,
for pedagogical reasons, to implement this callback anyway, and all the
student identity information is held by the school VLE anyway, why should
the content providers implement two callbacks where one will do?
I would ask two further questions (and they are genuine questions - there
may well be good answers):
1. If it is now recognised that data being passed via Shibboleth should be
restricted to anonymous data, why is the bureaucratic overhead of a trust
federation required at all? There is a pressing need to encourage innovation
in the market and any unnecessary barrier to entering the market should be
removed. Why should I have to establish that I trust someone before I send
them anonymous data?
2. If the industry can implement this functionality without all the bodging
involved with the creation of wayfless urls, and all the student identity
information is held in any case in school MIS/VLEs, then why do we need
duplicate systems to be run at local authority level?
What I expect is a convergence of SAML/Shibboleth technology and SCORM-type
technologies being used for content-VLE integration. I am hoping that SALTIS
will be able to set up a working group in the early summer to look at this,
on the back of the outcomes of the BECTA/ISB content packaging project, and
we would welcome the participation of the UKAMF and anyone else working in
this space.
Details of the content packaging project are at
http://www.saltis.org/papers.htm.
Crispin.


_______________________________________________
Advisory mailing list Advisory@talk.naace.org http://talk.naace.org/mm/listinfo/advisory
To unsubscribe send a message to Advisory-admin@talk.naace.org with the body text:

unsubscribe Advisory YourEmailAddress

or: send a message to Advisory-request@talk.naace.org
with the body text:

unsubscribe YourPassword YourEmailAddress