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",
"profile": "http://iiif.io/api/image/2/auth/login",
"label": "Login to Example Service"
}
}"the @id field is the URI that the client should load to allow the user to authenticate, the profile field is fixed and MUST have the above URI as a value, allowing clients to understand the use of the service, and the OPTIONAL label is the text suggested to be presented to the user to initiate the loading of the authentication service."
This can fit very nicely into the most common scenario at the Wellcome Library, "accept terms to continue":
http://wellcomelibrary.org/player/b1818893x
This current UI represents the end result of much wrangling with the legal department. This archive, like many others, is that of a recently deceased person and refers to living people. Acceptance of terms and conditions is required for access. When this digitised material went live 2 years ago, a user was required to register on the site, either as a full library user or via a social login, so that they could check a box at the foot of a terms and conditions page. Now, it has been agreed that this box is equivalent. The "accept terms" button is a link to the following URI:
This logs you in a guest for 10 minutes and redirects you back to the same page.
We'll get back to the redirect URL in a minute, but if we made the decision that the Wellcome Player should render the info.json login information in the way it currently renders this popup, we could generate the same effect (pretty much) by crafting our info.json like this:
{
"service" : {
"@id": "http://wellcomelibrary.org/service/login/guestlogin?redirectUrl=",
"profile": "http://iiif.io/api/image/2/auth/login",
"label": "<h1>Archival material less than 100 years old</h1><p>This digitised archival material is free to access. By accepting our terms and conditions, you agree to the following:<br><br>By viewing this and any subsequent archive material under 100 years old, I agree that I will use personal data on living persons for research purposes only. I will not use personal data to support decisions about the person who is the subject of the data, or in a way that causes substantial damage or distress to them.</p> <a href=\"http://wellcomelibrary.org/terms\">Read full terms and conditions</a>"
}
}The info.json
Assertion of range with motivation authDescription - if used as such, ALL images in the range must be subject to the same auth - this means that the viewer can interrogate the info.json of the first image (or any image)
Let the viewer know "if you're logged in for this one you'll be logged in for all the others associated with it (in some way) But what about multiple images on the canvas where the two images have different permissions?