Alistair Young wrote:

> > AIUI, that's a policy rather than a technical decision
>
> sounds to me like a technical decision that has decided the policy.

Nope.  The only relevant technical fact is that implementing account
linking in the application would require a non-zero amount of
development effort.

> The EPTI value it gets from the shibb to athens gateway
> cannot be replicated by an IdP AFAIK.

I thought we were talking about direct Athens vs. direct Shib.?

If you want to talk about the gateway, it's basically the same story
though: it's another, different way in, so account linking is possible
in principle but not implemented in practice.

> I wonder who will attempt [account linking]? Or will [Digimap] just set
> a precedent?

A binding precedent is unlikely: it's in the nature of a federated
system that everyone will do their own thing.

> It's a classic case of vendor lockin. Those users who have been  
> accessing Edina via the shibb to athens gateway are now locked into  
> that. Unless they're willing to chuck away all their settings [...]
> I'm talking about years worth of references, alerts etc.

That's the policy decision for the SP, balancing the user inconvenience
against commitment of development effort to build in account linking
at the application level (it not presently being in the middleware).
Going back to your previous point, different services will view this
balance differently.  And in the specific references system you now
seem to be talking about again (rather than Digimap) more of the
value of the service may lie in this accumulated context, so they may
decide to do account linking.

In the Digimap case, the people who made the decision did have previous
experience of similar transitions (from Athens to AthensDA) and chose
not to do account linking.

> All because a URL has changed?

It's not just a URL: the access mechanism is completely different.

> It's still shibboleth.  It's still the uk federation.  
> All that's changed is a URL!!!!!!!

No.  In the original case you mentioned (direct Athens vs. Shib)
you have two completely different middleware systems and Athens is
not in the federation.  Even in the gateway vs. direct Shib case that
you are talking about now, you have two different federation IdPs.
And as you mention above, at the Shib level the IdP used affects
targeted IDs, so that the same SP will see different targeted IDs
for the same person, when that person uses different IdPs.

> I thought middleware was meant to be transparent?

But often it isn't.

Fiona.