Open tomcrane opened 1 year ago
For both IIIF-Browser (#43) and Manifest Editor, interaction with the repository will need to use cookies for the MVP, as CRKN can ensure the user is logged in.
In the MVP, the Manifest Editor and the IIIF Browser will rely on the fact that the user is already logged in and has a cookie on the same domain as the Manifest Editor and the Storage Service, and that the storage service can validate this cookie (probably by sending the value to some service) to authorize the API request (whether it’s a PUT, POST or GET).
In the long run the Manifest Editor should participate in the OAuth2 flow Authorization Code Flow with Proof Key for Code Exchange (PKCE) to acquire Access Tokens for the storage service. A simpler explainer.
Our eventual IIIF storage spec needs to describe this interaction sufficiently so that the Manifest Editor could go up against any implementation of the storage service and successfully obtain an access token. That can come later, as it would potentially also provide an extension to the IIIF specification itself.
For MVP assume that cookies are present, and that the Manifest Editor has a flag to send cookies when interacting (GET, POST, PUT) with particular domains. The onus is on the storage service to issue these cookies correctly.
We can have config in the ME like:
{
"auth" : {
"iiif-repository.crkn-rcdr.ca": "cookies",
"future-repo.example.org": "oauth2-pkce"
}
}
If there is a #184, then there must be access control.
This could be at the network level - the repository is not exposed to the internet at all, or it is restricted by IP, but if you can see it you can read and write.
However it's likely that more fine-grained access control will be required; the Manifest Editor will need to be able to acquire and use tokens to interact with the storage API. And it's likely some users will be able to read, some to read and write, and even that differing levels of access to different resources are required.
The Manifest Editor needs to be able to acquire access tokens for the storage API using OAuth2. We don't need to (and shouldn't) specify what's going on inside those tokens - e.g., a likely implementation would use JWT but the Manifest Editor as a client doesn't need to know that and regards any tokens as opaque.
The token is a matter for the token issuer and the token consumer (the storage API).
However, the storage spec can be opinionated about the OAuth2 exchange, so that the Manifest Editor can be a client of any implementation of the storage spec. (Note how this is completely unlike IIIF Auth, because it's a direct API consumption, not an indirect media consumption). That is, there is a particular profile or pattern of OAuth2 that the Manifest Editor and the Storage Server implement.