IIIF
Login services required on unprotected image
The redirect pattern (3.2, and implementation notes section 5) where intervening 302 responses are not seen means that the final public info.json needs to have the authentication services of a different, protected image. This is a little bit strange from a resource orientation perspective as the login service does not really apply to the public image, and should be called out as a gotcha to avoid.
Suggest a clarification in 3.2 in Auth 1.0.1
Should Auth 2.0 provide a different way of providing the service? Something else in the resource model? Or is that going to confuse even more?
Editorial clarity in next version - don't extend the model. Keep this in mind while looking at other options for Auth 2, but if this is the simplest then keep it.
https://github.com/IIIF/api/commit/5cb7d246f96d6e18953008ae17c33e382865b78f and subsequent commits introduce and refine the idea of a location property in the probe service as the mechanism for pointing a client to the URI of a resource they can see.
Request the probe service for a resource (which may be the info.json), using the token that stands a proxy for your credentials to the resource, and the response status code will never be 30x but may be a 403. The location property is the URL of a variant of this resource that you can see.
If this approach works, it removes the hand-wavy assertion of the services for the protected resource on the redirected open resource.
