IIIF Authorization Flow API 2.0

[glenrobson]

Links

• Original Issue: Auth 2.0 Tasks api#2202
• Pull Request: Auth 2.0 release api#2225
• Preview: https://preview.iiif.io/api/auth-2-milestone/auth/2.0/

Background and Summary

There have been a number of changes in the way browsers work with third party cookies which has caused issues for version 1.0 of the Authentication specification. This has meant looking into a better way this could be handled which will be less brittle with respect to changes going forward.

Version 2 also adds in the facility to authenticate AV resources and brings the specification so that it is compatible with IIIF v3. The name has also been changed to better reflect the purpose of the specification on controlling the authroization flow rather than a authentication specification similar to OAuth.

There is a working demo of the new Authorization flow with a simple web client available at:

https://tomcrane.github.io/iiif-auth-client/?collection=https://iiif-auth2-server.herokuapp.com/collection.json

Proposed Solution

The Authentication TSG would like you to approve the release of the IIIF Authorization Flow API 2.0

[julsraemy]

I think it would be nice to have a line/paragraph on the specification stating that it has been renamed.

[tpendragon]

It looks good. I do wish there was some pattern to access control manifests as a whole, but I was able to parse the intention and flow really well from this document.

[tpendragon]

I appreciate @tomcrane's comments that presentation manifest access controls are well understood as typical access scenarios and that's why this draws a line as not supporting manifests, but I do wonder how that correlates with the documented multi-volume-work use case where a manifest is a resource (a IIIF collection with viewingHint of multi-part?) What I think is still unclear to me is how do I tell users that Volume 3 is in copyright but you could view it if you're part of this class and log in? I'm not blocking this review here, but I do think that MVWs are a big part of my work and rarely supported. For now I can continue having my own out of band iFrame that manages authorization external to this specification.

[tomcrane]

@tpendragon I do think that there could (maybe even should) be an agreed protocol (likely a particular profile of OAuth2) that the IIIF community can agree on, for access control of IIIF API resources like Manifests and Annotations, but that spec is complementary and adjacent to this Authorization flow spec, rather than part of it, especially for this v2 release. I can see the work of the Auth TRC continuing along those lines.

[zimeon]

Re. @julsraemy's #112 (comment) I think we might address the renaming in the change log comment

[glenrobson]

Issue 112 (IIIF Authorization Flow API 2.0)

+1: 21 [akrishnan15 cubap eliotjordan glenrobson hadro ioanrichards irv jpadfield jtweed julsraemy kirschbombe ksclarke markpatton markpbaggett mikeapp nfreire regisrob robcast tpendragon triplingual zimeon]
0: 0 []
-1: 0 []
Not TRC: 0 []
Ineligible: 0 []

Result: 21 / 21 = 1.00

Super majority is in favor, issue is approved