Image auth from Presentation

[azaroth42]

Lots of use cases for caching authentication requirements in manifests / collections.

[azaroth42]

Decision at eds meeting: create a viewing hint that means everything below the resource with the hint can be used without needing authentication. Lack of the hint doesn't mean that it is required, or it could be out of date ... it's just a hint.

Rationale was that we should be promoting open access where possible, rather than flagging access controlled resources.

[azaroth42]

For the second and subsequent instances of the same authentication service in a single manifest, only the URI of the login service is needed from a graph perspective. The other features are all identical for that URI.

So ... would:

"service": "http://example.com/auth/login"

be sufficient when there has previously been a service with all the info laid out?

[tomcrane]

I agree that URI-only assertions of auth services are a better solution than introducing new viewing hints or other mechanisms, once the full service information has been asserted in the graph.

My concern is how easy it is for JavaScript clients to find the full service definition in the JSON-LD. This could be the first time the service is encountered in the "parse order" of the JSON-LD - but that might be on the thumbnail service attached to the 27th canvas, or somewhere equally buried deep in the manifest. Consider a manifest that recombines a book - the first 300 images are open from Institution A, the second 300 require auth for Institution B. We could assert the full auth services on image 301 and then URI only for images 302-600, thus saving a lot of repetition, but the client would have had to have scanned through the whole graph to locate the full service.

I have a manifest in which the first occurrence of the auth services, in "json reading" order, is on an image service for the thumbnail property of the canvas (i.e., not an image service on the normal image annotation of the canvas). Anyone who protected thumbnails with the same service they used for the images would have the first auth service in parse order appearing here (as the canvas is parent to the images). The manifest gets pretty messy, but that's not necessarily an issue.

Continuing the discussion from #547 (my comment of 24 Aug), we could:

1. assert the full service on the first instance of the auth service, wherever that may be in the serialisation order of the JSON (not necessarily on an image anno - could be asserted on other resources too). Are we happy that "first instance" is meaningful? If a viewer encounters a service defined by URI only, it must scan the graph to find the full definition (the JSON-LD resource with this URI as @id). It doesn't even know it's an auth service until it finds this and sees the profile.

My (slight) problem with this is that it puts more onus on the viewer to behave like a consumer of RDF, of a graph - "yes, we have declared the full service info at least once in the graph, that should be all you need" - rather than as a JavaScript client processing JSON that happens to be -LD.

2. Get the assertion of services out of the way early, in a consistent place (directly on the manifest). We still need to include the URI of the auth service where it is needed, but all of our thumbnails and image annos that require auth services look consistent (example).

My problem (and yours) with 2) is that while this gets the assertion of services in the graph out of the way neatly and consistently, the auth services don't actually apply to the manifest. All the things that the services DO apply to still get the correct assertion by URI only, but we're left with an additional assertion of the services at the manifest level that is at best redundant and at worse a lie.

However, is it a lie? It's not invalid - we're stating that the manifest has these services too, but we returned the manifest with HTTP 200 so don't worry about them, you didn't need to use them.

Some people might want to use auth services here to protect manifests with the IIIF Auth model - which could be the real flaw with 2). If you assert all the services up front on the manifest, and you need to assert a variety of services because your images are coming from different places, how do you then protect the manifest itself with the same auth model - how does a client processing the auth flow for the manifest itself know which service really applies to the manifest?

3. Reserve the assertion of full resources for a different but valid special location - first image on first canvas or startCanvas, or the second image.

This avoids the problems of 2) but wouldn't work for the 600 page book described earlier, or other similar scenarios, and maybe it isn't that different from first serialisation instance in terms of what the viewer needs to do.

---

Although I favoured 2) (and have implemented it) I've now persuaded myself that 1) is better, and clients will just have to traverse the graph until they find the full service definition for a URI to find out what it is. They can then store it for next time.

Or is there some other place we could assert auth service consistently, where they could be easily found, that unlike the manifest is always valid - maybe another service at the manifest level (profile "authServicesContainer" or something) that acts as a container/basket for auth services used in the manifest? Code that serialises a manifest on the server could put the full instance into the basket when it first encounters it, but always assert the URI only on the images.

[azaroth42]

Links from 11/11 call:

• https://gist.githubusercontent.com/tomcrane/093c6281d74b3bc8f59d/raw/070b71f31c05f42d22a9da2a9cfa18ee3dd6b9ac/thumbnails-auth-status.png Desirable potential UI if the issue can be resolved
• http://library-uat.wellcomelibrary.org/iiif/b17564980/manifest Note caslogin service at manifest level, and then only referenced from other resources

[azaroth42]

Proposal is: The full auth service description MUST be included at least once in the manifest. The manifest SHOULD have an auth service description on the first matching resource in manifest tree order, and then afterwards use just the URI of the service. Clients are thus recommended to store the service descriptions when they are encountered.

Note that the manifest may be out of date and hence the source of truth is the service description in the info.json of the image.

To be added to section 8 of Presentation API.

(proposal from IIIF tech discussion at LDCX (Eds plus @tpendragon @aeschylus @escowles @mekarpeles)