Subject RE: comments on eduID
From "Vries, Ale de (ELS-NYC)" <ale@xxxxxxxxxxxx>
Date Wed, 21 Oct 2009 11:12:32 -0400

I think the search-for-your-IdP idea has some flaws and implications
that, in my opinion, doesn't make it much of an improvement:

- It assumes that the user knows who their IdP is. That is the key
difference between browse and search: search requires prior knowledge of
what you're trying to get to, and browse allows users to "find their
way" (that is another area of usability research we have a lot of
experience in). Since the concept of an IdP is alien to a user, I think
we shouldn't assume that users know what to search for. At the least,
you'd need both search AND browse.
- It requires the SP to build its own search functionality for IdPs.
Since we only want to show IdPs on our UI that we know have licenses to
our content, it means that we'd have to create and maintain our own
searchable list. Nothing major, but it is an extra thing to do, and
there are no standard implementation models or software packages for it
- which also means that it is another source for inconsistency.

I also think that there is some over-concern about being locked into
brands. Sure, it may be that a brand is created that is domain-specific,
and that there are going to be different brands for different sectors.
Bob's point is that this wouldn't be nice for SPs like us, but I think
that in reality it's more workable than you'd think:

After all, the context of where we'd show the "login brand" to an end
user would be a particular web site, say Now - is geared towards academia and - to some extent -
research-intensive companies. We don't expect e.g. that many lawyers,
burses, high school students, etc. to go to for their
information needs - so even if these other sectors/users have their own
login brands, we'd not show it on anyway (or maybe put
them on a different page). Same for - we wouldn't necessarily
show eduID as the prime federated brand there, but rather legalID or
something (if that would exist).

So, my point is: we don't necessarily need one federated brand for all
sectors, because services offered to different sectors are often branded
by sector themselves, and as long as clusters of services in different
sectors are more or less served by one brand, you can user confusion
limited. You just need to pick the name and scope of your brand really

Also, another thought - I don't think brands HAVE to be exclusive. A
certain institutional credential might be usable under both the legalID
and the eduID brand - so, "fringe" users (e.g. law school faculty) could
choose either brand and still be able to log in.

In conclusion - I agree that having multiple brands, each scoped to a
sector will create some mess and some confusion somewhere, but I think
that a. trying to create one single brand is reaching too high, b.
trying to stay brand-less is denying yourself the "power of branding"
that is so useful in driving uptake, and c. we can't stay where we are
today much longer if we want to move forward.

Best - Ale

-----Original Message-----
From: Peter Schober [mailto:peter.schober@xxxxxxxxxxxx] 
Sent: Wednesday, October 21, 2009 7:31 AM
To: REFeds
Subject: Re: [refeds] comments on eduID

* Nicole Harris <n.harris@xxxxxxxxxx> [2009-10-21 13:03]:
> I think what we are trying to get to is what do we say in the
> "" label, when we don't have a foo ;-)

I may have to re-read that google UI paper (it's been a while) but
sticking with this example: Wouldn't be a local account at the
SP you're accessing? So wouldn't be necessarily different for
every publisher/SP/RP?

But IMO these suggestions by Google assume (which will certaily be
right for the Googles and Amazons of the world, but may not be right
for every federated SP on the planet):

* Local accounts at the SP/RP are available in the first place
* Local accounts are used by the majority of accessing users
  (otherwise why bother all users with this)?
* Doesn't this plainly contradict the conventional wisdom what users
  will gladly enter their credentials anywhere if there's a form field
  for that? That's the reason we usually make local authenticaion less
  prominent (i.e. if the application can show one mode of
  authentication first, and "need more choices/help" later, defer the
  local authentication until last).

In other words this may be adequate if you're only offering federated
authentication as an afterthought or a fallback mechanism, not as the
main (or only) means of login.
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677 (The Netherlands)