Auth and Rights

[jpstroop]

Current spec says:

Note that while there is widespread agreement that the limitation of WWW-Authenticate to Basic and Digest authentication in the current HTTP specification, there is no standard way to indicate appropriate redirection to a login screen, or convey a URI template to insert a return URI.

Which doesn’t make sense so needs correction. Also would be good to discuss practical issues of how auth is being done. Once authenticated it seems that authorization cookie tokens are the means all(?) implementations use to grant access. This happens automagically in the browser but should perhaps specified so that mediated or non-browser applications know to expect to have to get and keep cookies.

Scenarios.

1. Everything open, no auth: Normal info.json, specifies all info about images available, no login
2. Nothing available without auth: Access to info.json or any image URI is denied with 401, redirect to auth (can’t use login in info.json??)
3. Better access with auth: Base info.json has information about available images/tiles without auth, has login information, client will know to request only stuff that is available but can display login link. If client does auth then will get redirect to new info.json with different prefix and possibly different identifier. The new info.json will have all appropriate image information accessible with the new credentials.

Implementation logic (possible):

• Viewer either gets 401 or it gets info.json with “login” url (suggesting there is possibly a higher quality image available)
• It can offer the user a possibility to login
• It displays login url (in an iframe or new browser window)
• It re-request the info.json for all the opened images from the server
• Either it is redirected (HTTP) to a new location (iiif prefix)
• Or the info.json is changed (possibly new width / height, etc).

See this gist for how the new info.json might look.

[azaroth42]

Proposed text in http://image-auth.iiif.io/api/image/2.1/#authentication

[zimeon]

Discussed at GWU meeting last week and agreed that approach described above will not work, have created #463 and #464 to explore other options

[zimeon]

As a result of #463 and #464 we have explored, prototyped and agreed to go with this authorization-service approach, in a separate specification, and thus this issue can be closed

[azaroth42]

Auth has been replaced by lots of more specific issues and has been written up. Rights are in image API now as well, so this issue can be closed. -- Eds