 |
 |
On Thu, Oct 14, 2010 at 11:11 AM, MJ Ray <[log in to unmask]> wrote: > Ross Singer wrote: >> Unlike Twitter, however, we're starting from nothing. There's nothing >> currently invested in ILS-DI clients that would break by committing >> solely to OAuth (or anything, for that matter). > > Are you sure there's nothing currently invested? I thought the Koha > community was already implementing ILS-DI so I assume there's some > client using it, as people don't tend to fund useless developments. I > don't remember if any of the co-op's client libraries are using it > yet, though. > I am pretty certain of this. The current group is focusing on a different set of functionality (primarily around borrower account services) than the DLF group got to (which was about harvesting bib records and limited item availability support). In some ways, however, any answer I give here is correct. The DLF group provided no specifics on how to implement their functionality. HarvestBibliographicRecords could be provided via OAI-PMH or Atom, they provided a new XML format for including holdings availability, but no specification on how it would be delivered, etc. That is, the DLF ILS-DI provided guidelines of functionality that needed to present, but not a specification on how it needed to operate (they did give "recommendations"). So any Koha implementation would just be an interpretation of these guidelines, but there was no specification that anyone can point to to say that an implementation is compliant. > [ILS-DI] >> It's no longer under the auspices of the DLF and the priority of >> functionality has changed. [...] > > OK, if it's no longer under the auspices of the DLF are you still > in contact with BibLibre? > They are more than welcome to participate. It's not a closed process. >> Indeed, and I hope the reply was likewise helpful. > > It was. More answers than questions, which is always good! > > That said, I'm still not seeing the benefits of OAuth for ILS-DI > compared to existing HTTP authentication and authorization methods, > really. > Ok, so let me provide you with a use case: Imagine a vendor hosted discovery service (EBSCO Discovery Service, Worldcat Local or Summon, for example, so we're not talking about any sort of 'edge case'). To use HTTP authentication, one of the following scenarios would need to be true: - they would either need to have access to a user's credentials (which is a non-starter in many places) - they would need to be a trusted superuser of the ILS-DI API service (they authenticate elsewhere, say an SSO, then can perform lookups as anybody) - some kind of token based access would need to be established between the discovery layer and the ILS-DI API The last scenario is exactly what OAuth standardizes, so we're not rolling our own, niche security protocol. If you want another use case, imagine a service such as LibraryElf (http://www.libraryelf.com/). A protocol like OAuth would allow you to share your borrower account with a (useful, I think!) service like this *without* handing over your user credentials. One can also imagine all sorts of interesting services cropping up in places like LibraryThing about what you've currently got checked out, placing holds on books recommended for you, etc. HTTP Authentication/Authz pretty much assumes all services will be provided locally which I think is a fairly antiquated assumption. -Ross. > Regards, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for Koha work http://www.software.coop/products/koha >