>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" <[log in to unmask]> 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
>
> [log in to unmask]
>
> 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
|
