tomcrane

@prefix wdrs: <http://www.w3.org/2007/05/powder-s#>.

<http://wellcomelibrary.org/resource/b18180279> wdrs:describedBy <http://wellcomelibrary.org/iiif/b19708440/manifest>
<http://wellcomelibrary.org/iiif/b19708440/manifest> a <http://iiif.io/api/presentation/2#manifest>.

tomcrane

These notes are specifically from the point of view of the Wellcome Library's current auth requirements, to see how the current proposed IIIF services fit.

The Wellcome Library does not support degraded access on the image service. You're either authorised or you're not. For certain otherwise protected content, it allows a thumbnail to be served to anonymous users - but will provide that as the "thumbnail" property of the canvas, not as a size degredation on the image service. This "thumbnail" property might be a URI, ot it might be an image service - see other gist. This means that viewers should use the "thumbnail" to get thumbnails.

The Image API spec adds a login service to the info.json:

{
  "service" : {
 "@id": "http://authentication.example.org/login",

tomcrane

This is based on the implementation described in IIIF Search Straw Person: https://docs.google.com/document/d/1F9-zelMCJqVjh-UMk8VeaPULBY2yRbI17X5EsrtcmSY

...and on the comments on this thread: https://groups.google.com/d/msg/iiif-discuss/cecb6B_21kk/3GIwpBWPMAsJ

The Wellcome Library already has search within, based on OCR data persisted in ALTO files. The implementation can be seen on any searchable book or archive: http://wellcomelibrary.org/player/b18035978

There are two services involved:

tomcrane

Thoughts on thumbnails

Rendering thumbnails might be the activity that puts most stress on servers if not given some care both on server and in viewer.

We have to remember that IIIF consumers are under no obligation to do what you want them to do. It’s not necessarily your viewer looking at the endpoints. While you can arrange a careful honourable agreement between client and server if it’s your viewer looking at your server, other viewers won’t know the rules – or may choose not to play by them.

An uncaring viewer app takes no notice of any hints, recommended sizes or explicit thumbnails declared in the manifest and goes straight to the first image service it finds for a canvas and requests an image in the size it thinks appropriate for a thumbnail. It doesn’t know whether this is an optimum size for the server to produce, or whether the server has this cached.

This is what the our Viewer is doing currently. If generated images are cached then over time the performance of thumbnails for an already

tomcrane

This post follows on from https://groups.google.com/forum/#!topic/iiif-discuss/mcs4T1KMyN4 and https://groups.google.com/d/msg/iiif-discuss/IIuduLgkRA0/X7xTZcUTmUAJ.

In the last IIIF call (2014-11-26) it was suggested that the auth information was better provided by a service - which can also be on any node - rather than an annotationList. So here are some further questions around that.

Is it OK for a service to return annotations too? It feels as if an annotation is a good mechanism to apply overriding auth information to a particular part of the structure, but via a service on a node rather than an annoList on a node.

Whether it is service or annolist, is it acceptable for a single profile supplied in an annotation to override ALL profiles "underneath" the target (i.e., descendant nodes in the JSON-LD)? It seems economical and reasonably easy to understand, but something about it doesn't feel right:

The "profile" term is dcterms:conformsTo. Here's my earlier example of an annotation providing an overri

tomcrane

Ref: https://github.com/IIIF/iiif.io/blob/master/source/event/2014/london_auth_scenarios.md

Ref: https://github.com/IIIF/iiif.io/blob/master/source/event/2014/london-auth-workflow.png

Reiterate assumptions from london_auth_scenarios:

Assumption 1: In both the Image API and the Presentation API, a given URI for an Image Information request, an Image request, or a Manifest request will result in the same bytestream if access is granted, irrespective of credentials and user identity.

(Is this compatible with london-auth-workflow.png? Think so because of the 301)

tomcrane

Auth Notes

I appreciate that these aren't technically use cases, the use cases I had were too cluttered by the process of acquiring a cookie rather than the metadata's appearance in response to that cookie. We haven't had to solve the problem of describing in metadata HOW a consumer might acquire the authentication token our service layer is looking for, our viewer just knows - which obviously doesn't lend itself to interoperability. Nevertheless I hope these are useful in describing what Wellcome does in the rest of the authentication and authorisation scenarios.

These are the assumptions and use cases that underpin the Wellcome Library's authentication and authorisation requirements.

For clarity, I'll use terms similar to IIIF concepts (e.g., manifest) even though the Wellcome Library doesn't yet use IIIF. Also it's worth pointing out that if IIIF Auth turns out not to be implemented this way, it doesn't mean we can't adapt to it!

Assumption: The manifest doesn't contain any secrets -