Access Control for general content resources

[tomcrane]

IIIF Auth only works for services (which means image services right now).

This IIIF API issue attempts to generalise the flow for any resource linked from a IIIF manifest (audio, video, 3D models, PDFs, static images):

IIIF/api#1290

This doesn't just mean canvas content (.items) - it could mean a PDF linked by rendering, for example. Any linked content resource may have auth services.

The UV needs to implement this flow in the general case, when it sees auth services asserted for content resources. It is not unlike the pre-IIIF-auth flow for audio and video, where the UV makes HEAD requests against the resource itself in the absence of a service. The above issue refines that approach to make it compatible with the approach taken in IIIF Auth 1.0; once the resources playing the roles of various actors in the auth flow are established, the flow is the same for all resources (not different code for image services and videos, for example).

[tomcrane]

The UV has an extra complexity for AV - it supports MPEG-DASH and HLS, via the dash.js and hls.js libraries. The British Library want to enforce access control such that a user without permission gets versions of audio with parts redacted, whereas an authorised user gets the full content.

This can be done by analogy to the "degraded" pattern for image services, whereby the two different users get different info.jsons - for adaptive bitrate content, the users get different source manifests (not IIIF manifest). But we can't enforce this behaviour through the Auth spec as we can for image services, because mpd and hls manifests are not IIIF resources; the spec doesn't know anything about them.

The UV has to ensure that a credentialled request is made for the mpd or hls manifest, so that if you happen to have credentials, you get the manifest that points to the audio content without missing bits.

Comparing this to the behaviour for images, we should treat the mpd/hls manifest as a Content Resource from the point of view of the spec, as it's outside the world of IIIF. It happens to be a service description, but it's not a IIIF service description, therefore it's a piece of content.

Clients make credentialled requests for images - they can't help it, it's how browsers work (unless you are loading the bytes into an HTML5 canvas).

Therefore the UV should ensure that a credentialled request is made for an mpd/hls manifest (via dash.js or hls.js):

• Dash-Industry-Forum/dash.js@d127e25
• https://github.com/video-dev/hls.js/blob/master/docs/API.md#xhrsetup

The problem is that the content resource is no longer being handed off to the browser for the browser to make a simple request, as it would do for an image tag. The UV (via these libraries) is requesting the content resource, with XHR under the hood. Which has CORS implications.

The BL may wish to use the mpd/hls manifest as the probe service in a HEAD request scenario, but that isn't relevant, as a IIIF client doesn't make .withCredentials requests for the probe service - it makes a tokened request, which isn't the same thing (to avoid requiring explicit origin ACAO), and doesn't process the body of a probe service... a probe service doesn't have a body at the moment. But it might need a body to support detection of degraded access scenarios.

This is the issue still to resolve in IIIF/api#1290 (comment)

[tomcrane]

Observations:

The UV should only get dash/hls to make a credentialled request if auth services are present on the resource. This will make it easier for simple server implementations (host it anywhere).

dash.js and hls.js are libraries that make it appear that the browser supports these formats natively. If they did support them natively, setting the src of an audio tag would result in a simple HTTP request ("simple" in CORS terms).

But they don't support them. Edge does... and other browsers are patchy. So we need these libraries. But the simulation of native support moves the goalposts - it's no longer a simple request, the simulation requires XHR to make the requests for us. Which means that the server response to a secure .withCredentials request must include the Access-Control-Allow-Origin header set to an explicit domain - that of the UV's executing script. We avoid requiring that anywhere else - but is the dash/hls scenario enough of a special case to introduce this extra constraint? That means in the general case, servers would need to echo the origin back, which is generally frowned upon for good reason. But in IIIF's consensual cross-site scripting exploit world, is that an acceptable compromise to gain cross browser, cross domain adaptive bitrate support to access controlled video from arbitrary clients?

[edsilv]

@tomcrane let's make a 3d auth demo :-)

[LlGC-szw]

All issues will be triaged for further investigation or closure by the 28 September 2023. If your issue is still relevant and would like for it be investigated further please comment by 14 September 2023.

[thattonBL]

We have a temp in-house workaround for this but this is still active.