I can make an HTML page with image tags that point at other people’s images: a page of Rembrandts from different art museums. If those images are open then it doesn’t matter whether my browser sends cookies for the publisher’s domain. The images will be served with or without those cookies.
But if the images are access-controlled, the publisher will expect to see a session cookie or similar credential in the request. My page of Rembrandts could include a note for the user: “log in over at example-museum.org, if you want to see this image”. If the user logs in there, comes back, and reloads my page, the images will work.
If the browser doesn’t send those cookies, the museum server will respond to requests coming from my third-party context with a 401 status — even though the user just logged in. They can see the image in a first-party context on the museum site, but not in a third-party context on my page.
This is not a typical scenario for access-controlled images on the web, because it’s only going to work if a user has an active session at the publisher site(s). This would likely result in a very poor user experience if the only way of doing this was to provide human-readable guidance and assume the user is going to follow it.
However, a more sophisticated version of this happens in a cultural heritage, research or educational context. Libraries, archives and museums publish interoperable content for use on their own sites, but are happy for it to be reused in other software, viewers and tools, and on other sites. This content is usually open, but sometimes it requires access control. This might be for rights management, issues of cultural sensitivity, or (rarely) commercial considerations. The web applications that use the content are viewers, annotation tools, crowdsourcing platforms or simply arbitrary HTML that references these resources cross-domain (e.g., a web page made by a student).
This access control is enforced by the publisher, on HTTP requests. The publisher might use OAuth2, CAS, Shibboleth or other protocols for the interactions that establish the session, but once established, the session is usually maintained by cookies that the third-party client (my web page) doesn’t care about (and has no visibility of or access to anyway), rather than tokens in the request that the client has to understand and supply itself (e.g., per-image-request tokens as query string parameters).
That is, there is no additional protocol layered on top of the image requests, only standard HTTP, once we have jumped over the initial problem of establishing the session at the publisher’s site.
Libraries, archives and museums gain interoperability by publishing digitised books, manuscripts, paintings and films as IIIF Manifests and Image Services.
The IIIF Authentication Specification supplies a set of interaction patterns for clients to follow to orchestrate that initial step of getting the user to establish a session at the content publisher.
IIIF Authentication relies on two things that are currently possible:
- The third party client can know whether or not the user can currently see an image on the first party site. This doesn’t mean having any access to content of or credentials for that image; the third party context cannot see those. It uses a simple protocol and the postMessage API to allow the first party context to convey just the fact of whether or not the user can see the image.
- Once a session is established, and following rules for SameSite cookies, the third party client will send the first party’s cookies.
It would be nice to have a simpler and more widely understood way of establishing the first of these. But without the second — without third party cookies — none of this works any more.
Notes