Access-controlled adaptive bit rate AV

[tomcrane]

Recipe Name

Access-controlled adaptive bit rate AV

Use case

This was previously in the draft of Auth 2 but it should be a recipe, with this warning, rather than in the spec.

5.3.4 Probe provides a different resource location

• The status property value is 302, and the response JSON-LD includes a location property. This indicates that the client has the authorizing aspect required to see the content, but it MUST request it using the provided location URL rather than the published URL:

{
   "@context": "http://iiif.io/api/auth/{{ page.major }}/context.json",
   "id": "https://auth.example.org/my-HLS-video.m3u8/probe",
   "type": "AuthProbeService2",
   "status": 302,
   "location": {
     "id": "https://auth.example.org/1232123432123/my-HLS-video.m3u8",
     "type": "Video"
   }
}

Warning

The previous example potentially bypasses the intention of location as described in the table above. The client, presenting a token, has used the access token to discover the URL of an actual content resource, that might not require a credential. This use case may be helpful for streaming media services where the use of modified paths containing short-lived tokens as path elements is common. However, it is a fundamental change in the approach that IIIF Auth has taken up to now, where a malicious client application gaining access to the token doesn't grant access to protected resources. The client has used a token to get access to the protected resource, rather than only get access to information about the user's access to that resource.
{: .alert}