Right, except OpenID isn¹t going to do this; there needs to be an
infrastructure in place where OpenID (or some other standard persistent
identifying system) can sit on top of, and that¹s still the big problem.
Right, that's exactly what Nathan's original post suggested. Are we
reading the same original post?
But yes, this infrastructure is the real issue, whether is uses OpenID
or Shibboleth, or something else. But it ought to use _some_ "universal
single sign-on" method.
I suggested that the OCLC Registry would be the logical house for this
infrastructure, as its' already 75% of the way there. I think OCLC
Registry is the... um, I've lost my metaphor. The thing that will wag
the dog's tail. But you still need a way for individuals to log in. I
suppose it could just be an OCLC-provided account. If OCLC implements
OpenID for their Registry, after adding a feature for _individual_
registrations (individuals expressiong associations with the
institutional registrations already there), then that's the way to wag
the, um, dog.
Jonathan
Jeremy Frumkin wrote:
On 3/26/07 6:35 AM, "Jonathan Rochkind" <[EMAIL PROTECTED]> wrote:
Jeremy Frumkin wrote:
Ok, so this is a good example for where I¹m failing to see the advantage to
OpenID over the current local authentication provided by a university /
library.
As Nathan explains, to identify your link resolver(s) to a particular
database (or 'source') you are using. How can a foreign third party
(vended or free) database use your local authentication login? Instead,
what they use currently is IP address.
Which is broken in several ways anyone who has worked with
IP-address-as-identity, common for authentication in our current
environments, has realized. IP address is not identity. Several people
(with different institutional affiliation/licenses held/link resolvers
used) may share an IP address, and one person may have several IP
addresses. IP address to people is a many to many mapping, and thus is
horribly broken for identification and authentication, and leads to all
sorts of problems many of us must continually try to work around, not
very succesfully.
-------
Right, except OpenID isn¹t going to do this; there needs to be an
infrastructure in place where OpenID (or some other standard persistent
identifying system) can sit on top of, and that¹s still the big problem.
Now, maybe the tail will wag the dog, and OpenID will lead to efforts to
build underlying trust infrastructure, but at the moment, that
infrastructure does not exist. The easiest way to implement that
infrastructure probably would be for every institution that might adopt
OpenID to also become an OpenID provider, but then, unless there is a
standard mechanism for linking one OpenID to another in a secure manner,
we¹re back at having multiple OpenIDs depending on our context. I completely
agree that IP-based authentication is not the long-term answer; maybe there
is a path, however, to applying OpenID over our current IP-based auth /
proxy servers in a manner that does add user-side value. As Nathan stated in
an earlier email, the one big advantage OpenID has right now is that it is
easy to start playing with, and maybe that¹s enough to start the wagging.
-- jaf
===============================================
Jeremy Frumkin
The Gray Chair for Innovative Library Services
121 The Valley Library, Oregon State University
Corvallis OR 97331-4501
[EMAIL PROTECTED]
541.737.9928
541.737.3453 (Fax)
541.230.4483 (Cell)
===============================================
" Without ambition one starts nothing. Without work one finishes nothing. "
- Emerson
--
Jonathan Rochkind
Sr. Programmer/Analyst
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
