Support IP-based and related forms of authentication

[tomcrane]

Auth 1.0 assumes that the user's relationship with access-controlled resources is decided by credentials carried by cookies.

Even in Auth 1.0 this is not an absolute dependency; the server is basing an access control decision on some aspect of a simple web request, such as that caused by an image tag, or a GET from opening a resource in a new tab. Usually that aspect is the credentials carried by cookies. But it could be any aspect of the request, such as origin, IP range, or some other information, that can be seen by the protected resource, and sometimes also the token service.

The auth interaction pattern doesn't need to change to accommodate this (although it might change for other reasons) - and it could help generalise the applicability of the spec.

A flow based on IP range would look the same to the client, but the probe aspect of the request could return a 200 immediately (where probe includes the current info.json request, see #1290). Or, a clickthrough pattern could show the user something in a clickthrough tab (its "cookie" service), but not set a cookie. The external pattern could allow token acquisition based on any aspect of the request, not just its cookie content.

Other patterns could emerge that involve a "cookie" service that doesn't set a cookie. The "cookie service" could be renamed to... something else. It's still most likely to be cookies, but a change in language (without being too obscure - we still assume cookies are the most likely use) could help people understand different mechanisms, including custom clients (access based on user agent, for example).

If it's IP-based, why is it even in scope for IIIF Auth at all?

• Because this allows for people who aren't in the permitted IP range to see some useful messages, rather than broken images. IIIF Auth is about managing the user experience.

[tomcrane]

Auth call - this is about changing the language of the spec to support more scenarios

[tomcrane]

See https://github.com/IIIF/api/commit/b4cae0ac9ed5954895f7d490e9e56a6a48363e0e and later commits. The spec language in https://github.com/IIIF/api/pull/2127 uses the term "aspect of the request" rather than cookies; the presence of a cookie is an aspect of the request, but so is the origin IP, or the time of day. Similarly the "cookie service" is renamed "access service" - the place you go to acquire the aspect of the request.

You might acquire this aspect of the request by logging in, and thereby gaining a cookie. You might already have this aspect of the request (you're coming from an IP address that suggests Australia, or "it's Thursday"). The flow doesn't distinguish between these two scenarios and still takes you to the Access Service.

This may be desirable, to not leak implementation details.

NB the spec already accommodates a flow where you don't have to visit the access service: the External pattern could be used for IP restrictions quite nicely - the aspect of the request has already been acquired externally, e.g., by virtue of you being in Australia.

[zimeon]

Resolved with publication of Auth 2.0. The IP address scenario is highlighted as one possible authorizing aspect, see e.g. https://iiif.io/api/auth/2.0/#terminology