IIIF
Support authentication for content search services for restricted content
Use case:
- I have access-restricted IIIF-delivered resources that have an auth service associated with them
- Which has associated content (e.g. OCR-generated text) that can presented as annos in responses from a search service
- Given the nature of the content (e.g. privacy concerns, legal restrictions, etc.), I need to ensure that only authenticated users/clients can issue queries against and get results from the search service
Examples (more for my/Stanford folks' reference):
- University Archives - faculty senate records
- Restricted oral history transcripts
Not a spec suggestion (I don't think) but an observation.
The current Auth spec is opinionated that it doesn't care how your access control works for jpegs, mp4s and tiles from image services. These are general web resources that might be behind any sort of auth layer, perhaps your institution's SSO. And typically they aren't requested by script, they are "requested" by img and video tags, so have different security considerations.
The auth spec only comes in for the permitted leaking of information to a client - how clients ask for service descriptions and token iframes. That's the only place IIIF-specific protocol lives in the Auth spec.
But annotation JSON resources live in IIIF-world. A client making requests for them is already bought in to IIIF, and if it wants to access protected videos or images, has to implement IIIF Auth to bridge the user to whatever access control system is in use.
So - while we don't want to mandate an auth protocol for simple content resources that need to work in non-IIIF contexts, is it OK to have a specific IIIF access control protocol for JSON-LD resources like manifests and annotation pages? E.g., "you will use JWTs to ask for protected annos and you will use them like this..."
Not sure how these are connected yet but it feels like they could be - https://github.com/IIIF/iiif-stories/issues/138
Is the mechanism for info discovery the same as the one for authed JSON resources? Current spec insists that its protocol only "protects" resources of no value, such as the info.json for the service (as opposed to the pixels you want from that service).
ACTION @tomcrane to ask question on W3C privacy CG issues about sending cookies with fetch() and what the future of that is wrt third party cookie elimination.
TSG decision on 2022-01-11 call to defer working on this until there's a direction for the Auth work within IIIF, as it's a necessary dependency.
This is really an example for the general case of Auth for IIIF Resources that is not covered in Auth 2.0.
