 |
 |
>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