Refeds


Subject Re: comments on eduID
From Nicole Harris <n.harris@xxxxxxxxxx>
Date Wed, 21 Oct 2009 13:02:14 +0200

Hi Bob

Only actually got this fully after the talk as our e-mail was down.  Again :-)  I think these are valid arguments, and fit in well with the conclusions we came to.  My only disagreement is that Google uses a 'nameless' approach.  It doesn't, it says 'do you have a Google password' and Google is one hell of  brand.  I think what we are trying to get to is what do we say in the "foo.com" label, when we don't have a foo ;-)

N
---------------
JISC Executive
JISC London office
1st Floor, Brettenham House South
5 Lancaster Place
London WC2N 7EN

tel: +44 (0)20 3006 6035
mobile: +44 (0)7841951306
fax: +44 (0)20 7240 5377


RL 'Bob' Morgan wrote:
[Sigh, also sent to tf-emc2, probably more appropriate here ...]

In this note I will try to explain as clearly as I can why I think that the
idea being promoted under the name "eduID" (that is, an academic brand to be
widely used as a user-interface element to initiate federated login) is not an
effective approach to the goal of login consistency, and (as Nicole asked a few
weeks ago when I first complained about this) to suggest what we should do
instead.

First let me say again that I appreciate the work that went into the JISC
publisher interface report, and I agree with the obvious need for consistency.
I also appreciate the urgency of the issue.  But I don't think that's a reason
to rush in the wrong direction.

Let me also say that for the sake of understandability I will refer to the
proposed approach as "eduID" rather than "higher-education brand to be
widely used, etc".  But I'm not arguing with the term "eduID" itself, but
with the concept of a higher-ed brand, regardless of the specific term
used.

There are a number of interrelated issues.

(1)  federated-login UI consistency

The scope of the JISC report is UK users using academic publisher
resources.  The recommendation in the report is that a "brand should be
created for academic federated access".  It's hard to tell what the
intended scope of the proposal for the federation brand is.  Is it to be
used with the academic publishers that are the subject of the report?  Or
is it to be used for all web resources that might be accessed by users
from any higher-education IdP?

I assume the answer is something like: let's start with the urgent problem
of consistency with the publishers, and see where it goes.  We have to
start somewhere, after all.  But when I follow this argument, I don't like
where it goes.

Suppose the proposal is just for the publishers and succeeds with them, ie
they put the brand on their pages and something consistent and usable
happens when users click on it, and higher-education users are educated to
do so.  If it stops there, has a reasonable consistency goal actually been
met?  From the point of view of JISC Collections, and presumably their
peers in other countries, yes, since this is their domain:  academic
users accessing academic publishers.

But from the point of view of users, I would say no.  In this scenario
users learn that for some resources (the publishers) they click on eduID
to do a federated log in, but for all others, they have to do something
else.  I know the US is an outlier when it comes to publisher access, but
even if we did federated access to all the publishers this would still
represent a small percentage of overall resources.  There would, I think,
be resistance at many US campuses to investing in a user-education program
around eduID if it is only a small set of resources and is different from
all others.

As I mentioned before, I don't think it meets consistency goals for
publishers either.  For academic users eduID provides consistency, but
eduID excludes all other users, so if the publisher SP has non-academic
users, they have to do something else.  That could be <something>ID by
analogy, but now the publisher has to depend on that sector organizing
itself, or the publisher has to do the organizing.

So the consistency provided by having eduID only apply to publishers is a
very limited consistency.

If the intent with the eduID proposal is to apply to any instance of
academic federated login, then, even assuming this is realistic, it still
suffers from lack of consistency from the SP point of view, for the reason
given above.  That is, eduID is only for academic users (whatever that
means), so federated access for all other users has be done some other
way.

Since we're from academia, we might say:  we don't care, as long as our
users are served.  For many SPs, that may work.  But it is my strong
feeling that as we go forward many SPs will not want to lock themselves in
to a federation approach that is sector-specific.  And when I say "lock
in", I mean it:  once eduID is on lots of sites and millions of users have
been trained to click on it, it will be around more or less forever.  SPs
serving many communities, making a commitment to federated access, will
want to use an approach that can work for their whole user base, not one
that is intentionally, and irrevocably, limited to only one part of it.

My principle here is this:  real consistency requires an approach (to
federated login initiation) that can apply to any users, any IdPs, any
SPs.

(2)  what users need to know, and need to do

The three necessary parties to federated login are the user, the SP, and
the IdP.  Everything else: federations, protocols, countries, sectors,
discovery services, etc, is only there to be useful to the end result of
letting the user log in (and be authorized).  It seems natural to OpenID
advocates to promote user recognition of OpenID, but as OpenID UI work has
shown users don't care about the OpenID protocol, and if it is put in
front of them they'll be confused and won't use it.  So real sites using
OpenID use logos of the big OpenID providers and/or ask for email address.

Similarly it seems natural to us academic federation operators to make users
identify themselves as academic users, and to pick from a list of our academic
federations.  As the JISC report suggests, users find this cumbersome at best,
and it will only grow worse as more federations emerge and more sites join.
Someone recently estimated the total number of IdPs in HE federations at 2,000.
While few SPs will work with all those IdPs, still just due to sheer scale the
notion of the hierarchical federation-based WAYF is one we have to move away
from.

As the report suggests, when users need to pick from a large number of possible
IdPs, a "well implemented dynamic search facility" (ie, selecting an IdP based
on typing some search characters) would be appealing to users instead.  It
would be consistent with many web-2.0-style search interfaces users see today.
The main thing to note is that such a search facility could include all IdPs
(or authentication methods generally) used by a site, not just academic ones.

If eduID is being proposed as a means of invoking the classic
pick-your-academic-federation WAYF, it is a move in the wrong direction.
And eduID is not the right label for a dynamic search facility that can
include any IdP.

(3)  a name isn't needed

As the report says, the publishers support many existing signon methods,
often with user-recognizable service names ("Athens" being the big dog
apparently).  This I suppose is what makes it seem necessary for the new
thing, federation, to have a service name too, to be a named alternative.
I'm proposing here that we specifically avoid giving federation a
user-visible name, precisely because such a name will be inherently
limited, as I describe above, or create unnecessary baggage (eg a branding
program).  Can federation be used if it doesn't have a name?

Fully-federated services (e.g. the Internet2 spaces wiki, or the Refeds
wiki) don't need a special label to indicate "use federation".  All they
need is a Login link or button.  Such services may seem to be the
exception today, but I observe that at my campus pretty much every new web
app (if it using federation at all, which most do) just has a Login link
that invokes federated login (often just using the UW IdP, or offering a
choice of IdPs).  I believe this is becoming a standard approach as apps
seek to externalize authentication.  And in this approach a name for
federated login isn't needed.

The Google research on federated login I mentioned earlier
(http://sites.google.com/site/oauthgoog/UXFedLogin) takes the no-name
approach.  In their generic use case a site is adding federation to
local-account login, so needs to help the user choose between them.  They
end up suggesting:

   Do you have a foo.com password?

to ask the user to make the "local account" choice, to avoid the
difficulties with the word "account".  If the answer to this is no, they
offer the equivalent of the federation search box with the label:

   Enter your e-mail address

I don't agree with these labels, but I do agree with their goal, which is
to lead the user to indicate their interest in federation and enter info
to find their IdP without introducing new concepts or jargon, and trying
to be entirely generic.  I think they show it can be done.

(4)  a modest proposal

I do think we need to strive for consistency in the areas the report
identifies, and I do think that it's important to do dedicated work to
that end.  As I mentioned, I'm helping chair the Kantara ULX WG
(http://kantarainitiative.org/confluence/display/ulx/Home) which is
working in this area, though more focused on multi-protocol consistency.

It would be great for JISC or Refeds or whoever to do more user studies,
preferably with publisher participation, and to come up with solid
proposals to really address the problems instead of being distracted by
creating a brand.  Here are things to do:

(a) Promote things that I hope we can all agree on, like using "Log in"
(appropriately localized) for the login link or button, instead of the
various alternatives.

(b) Take a publisher's user-confusing "login technology page" (oy) and
redesign it around the idea that federation will be the main way to login
going forward.  See if this can be done without attaching a name to the
federation choice.  Try it out on users.  If successful use the
before/after to show publishers the way.

(c) Use a modern UI toolkit to do an attractive dynamic search box for
finding an IdP.  Do user studies, do cool demos, give away the code.

(d) Try out some options for the label on the dynamic search box.  As a
starting point let me suggest the venerable:

   Where are you from?

which the report indicates users seem to like.

That's my highly-inflated 2 cents,

  - RL "Bob"