Re: [CODE4LIB] First draft of patron account API
>>> Jakob Voss 5/28/2012 04:04 AM >>> > http://gbv.github.com/paia/paia-868166f.html > http://gbv.github.com/paia/ [...] > The API should be made available to end-users and to third parties. A > mapping to RDF should be possible, similar to DAIA, but the first goal > is to provide an easy and defined access for automatically accessing > patron accounts. How would you make use of such an API? We've a lot of other patron data in Koha and it would be good to access that - and update it as well, auth permitting. Should we extend PAIA or is there another standard that we should consider? (Of course, Koha can use things like LDAP for its patron data, but for various reasons, some libraries want Koha as primary store and SIP is a bit hard-core and doesn't cover all updates.) Thanks for any feedback, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
Re: [CODE4LIB] First draft of patron account API
On Tue, May 29, 2012 at 5:31 AM, Jakob Voss wrote: > What are your major complaints with NCIP? >> > > 2. NCIP is rarely implemented in total, so you never know what you get > 2(a) Each implementation is usually of a different subset :-/ One existing protocol that might be serviceable is LDAP. It's an obvious choice for the person information, including the authentication parts, and may already be the primary repository for this information in the existing ILS (so no risky auth bridging). It would be possible to use custom back-end LDAP code to handle circulation functions (it's even possible to do this in javscript via ldapjs). However this would lose the benefits of being able to use an existing LDAP infrastructure, so a pure circulation API would still be cleaner. Simon
Re: [CODE4LIB] First draft of patron account API
Hi,
I added a recent changes list at http://gbv.github.com/paia/ to easier
follow modifications to the PAIA specification.
P Williams wrote:
I'm very interested in this problem space. Good to see that someone is
taking the initiative to try to solve the problem. I guess I'll have to
learn some German :)
Ach, das ist nicht nötig :-)
You better correct my English by proofreading the current PAIA spec.
You mention VuFind ILS drivers. You might also be interested in the
"connectors" from the XC NCIP toolkit [http://xcncip2toolkit.googlecode.com]
and LAI Connector from Equinox's FulfILLment [
http://www.fulfillment-ill.org/].
Thanks, I started a page with related work, open for contributions:
https://github.com/gbv/paia/wiki/Related-work
I think OAuth is a good starting place when you talk about authentication.
This would address some of the issues of trust with applications that want
to access your library related information and how to securely grant access
to these client applications. With an OAuth model the server (ILS) doesn't
have to know about the client application before the first request in order
to establish trust. The trust is established by the user just in time.
With library systems username and password are usually barcode and pin.
The pin is usually a four digit number which is substantially easier to
break with brute force than a true password (alpha-numeric + case +
punctuation). I think that unfortunately PAIA has the potential to make
this type of attack easier. Any thought to hardening library systems
against brute force authentication attempts?
You are right, but library systems should not have allowed weak
passwords in the first place. I added a section on secuity considerations:
http://gbv.github.com/paia/paia-5c2005c.html#security-considerations
I think the best way is to enable PAIA only for patron accounts with
strong passwords.
> What did you mean by decoupling of authorization and access?
One reason to decouple authorization (PAIA auth) and access (PAIA core)
was to be free to use different authorization methods in addition to
username and password. You could also support access tokens bound to
specific clients which can access multiple patron accounts or access
tokens with read-only access to a patron account. With username/password
one would only have all or nothing.
What are your major complaints with NCIP?
1. One of the most important bits of information ("circulation status")
is not defined but free text.
2. NCIP is rarely implemented in total, so you never know what you get
3. Identifiers are not URIs.
4. I don't know of any library that allows open access to their NCIP
interface by patrons and third-parties.
But I've seen worse library APIs than NCIP ;-)
I can see this being useful with authenticating for use of licensed
databases, to determine eligibility for ILL services, or to verify a valid
user for reciprocal borrowing in person within a consortia. It might also
be useful for a service like Library Elf.
Interesting case. You could think of a database as a document which can
be requested - so the patron sends a PAIA "requestItems" and the
resulting document state is 3 ("held") or 4 ("provided") on success and
5 ("rejected") on failure.
Jakob
--
Jakob Voß , skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de
Re: [CODE4LIB] First draft of patron account API
Hi, I'm very interested in this problem space. Good to see that someone is taking the initiative to try to solve the problem. I guess I'll have to learn some German :) You mention VuFind ILS drivers. You might also be interested in the "connectors" from the XC NCIP toolkit [http://xcncip2toolkit.googlecode.com] and LAI Connector from Equinox's FulfILLment [ http://www.fulfillment-ill.org/]. I think OAuth is a good starting place when you talk about authentication. This would address some of the issues of trust with applications that want to access your library related information and how to securely grant access to these client applications. With an OAuth model the server (ILS) doesn't have to know about the client application before the first request in order to establish trust. The trust is established by the user just in time. With library systems username and password are usually barcode and pin. The pin is usually a four digit number which is substantially easier to break with brute force than a true password (alpha-numeric + case + punctuation). I think that unfortunately PAIA has the potential to make this type of attack easier. Any thought to hardening library systems against brute force authentication attempts? What are your major complaints with NCIP? What did you mean by decoupling of authorization and access? I can see this being useful with authenticating for use of licensed databases, to determine eligibility for ILL services, or to verify a valid user for reciprocal borrowing in person within a consortia. It might also be useful for a service like Library Elf. Viel Glück, Tricia On Mon, May 28, 2012 at 2:04 AM, Jakob Voss wrote: > Hi, > > In the last month we worked on specification of a patron account API > (PAIA) because existing (or more: non-existing) APIs such as NCIP and > SLNP don't fit our needs (most of all: simplicity, strict definitions, > and decoupling of authorization and access). The API is based on DLF-ILS > recommendations, VuFind ILS drivers, and OAuth among other input. I'd > hereby like to share the current draft for comments: > > http://gbv.github.com/paia/paia-868166f.html > http://gbv.github.com/paia/ > > How to contribute: > * Implement a server and/or client of the PAIA specification for your > ILS and/or discovery interface > * Fork and modify the specification at github > * Comment on the specification and report bugs: > https://github.com/gbv/paia/issues > * Think about useful apps and mashups that make use of PAIA > > The API should be made available to end-users and to third parties. A > mapping to RDF should be possible, similar to DAIA, but the first goal > is to provide an easy and defined access for automatically accessing > patron accounts. How would you make use of such an API? > > Jakob > > > -- > Verbundzentrale des GBV (VZG) > Digitale Bibliothek - Jakob Voß > Platz der Goettinger Sieben 1 > 37073 Goettingen - Germany > +49 (0)551 39-10242 > http://www.gbv.de > jakob.v...@gbv.de >
Re: [CODE4LIB] First draft of patron account API
Jakob, Good work - looks promising. Some use-cases that I can think of are: - Integration with client-side notification system e.g., pull overdue or resource availability events - Sync online social network profiles with library systems to find people with common interests based on book selection matt >>> Jakob Voss 5/28/2012 04:04 AM >>> Hi, In the last month we worked on specification of a patron account API (PAIA) because existing (or more: non-existing) APIs such as NCIP and SLNP don't fit our needs (most of all: simplicity, strict definitions, and decoupling of authorization and access). The API is based on DLF-ILS recommendations, VuFind ILS drivers, and OAuth among other input. I'd hereby like to share the current draft for comments: http://gbv.github.com/paia/paia-868166f.html http://gbv.github.com/paia/ How to contribute: * Implement a server and/or client of the PAIA specification for your ILS and/or discovery interface * Fork and modify the specification at github * Comment on the specification and report bugs: https://github.com/gbv/paia/issues * Think about useful apps and mashups that make use of PAIA The API should be made available to end-users and to third parties. A mapping to RDF should be possible, similar to DAIA, but the first goal is to provide an easy and defined access for automatically accessing patron accounts. How would you make use of such an API? Jakob -- Verbundzentrale des GBV (VZG) Digitale Bibliothek - Jakob Voß Platz der Goettinger Sieben 1 37073 Goettingen - Germany +49 (0)551 39-10242 http://www.gbv.de jakob.v...@gbv.de
[CODE4LIB] First draft of patron account API
Hi, In the last month we worked on specification of a patron account API (PAIA) because existing (or more: non-existing) APIs such as NCIP and SLNP don't fit our needs (most of all: simplicity, strict definitions, and decoupling of authorization and access). The API is based on DLF-ILS recommendations, VuFind ILS drivers, and OAuth among other input. I'd hereby like to share the current draft for comments: http://gbv.github.com/paia/paia-868166f.html http://gbv.github.com/paia/ How to contribute: * Implement a server and/or client of the PAIA specification for your ILS and/or discovery interface * Fork and modify the specification at github * Comment on the specification and report bugs: https://github.com/gbv/paia/issues * Think about useful apps and mashups that make use of PAIA The API should be made available to end-users and to third parties. A mapping to RDF should be possible, similar to DAIA, but the first goal is to provide an easy and defined access for automatically accessing patron accounts. How would you make use of such an API? Jakob -- Verbundzentrale des GBV (VZG) Digitale Bibliothek - Jakob Voß Platz der Goettinger Sieben 1 37073 Goettingen - Germany +49 (0)551 39-10242 http://www.gbv.de jakob.v...@gbv.de
