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