Access control and stuff

[dp...@metro.org]

Hi folks,

Before I go deeper into this question/ideas, a tiny statement: Archipelago was made with Open access in mind and as such was not developed nor architected to be "closed", "restricted" nor serve the idea that knowledge, content, etc should be put behind closed doors/silos under seven keys. OK, now that we have that out let's speak about Access Control and some needs (including user privacy) that we will start developing to serve some community (valid) use cases:

A few months ago I started this Github ISSUE to explain some ideas behind access control we may want to implement. https://github.com/esmero/strawberryfield/issues/82 Its a long one but if anyone is interested in the larger technical description/ideas please give it a look 

This is not about "no access" at all to a DO, for that Drupal has enough tools already.

The "What" first:

1.- Metadata filtering based on Rules:

This is a first approach. Allowing Curators to apply, per Digital Object rules that exclude certain JSON keys (and via that also files) for public access. There are many levels where this can be applied and the implementation itself seems not that complex (its night already so I may be optimistic-tired). Probably reusing Rules (and in our case Access Control Lists/ACLs) seems the better approach instead of having a node by node setting. This may affect affect a few operations like View/Edit and API representations of ADOs (implies delete/update too). Filtering may also mean "obscuring partially" or replacing with nice words.

2.- File access based on rules. Same as Metadata (and file access can eventually be done directly on the metadata side to make things simpler) This may affect affect a few operations like View/Edit/Download and even, if needed size restrictions. The filters here may be Metadata tag of a certain file, mime type, size, etc. Also, removing/hiding machinable and needed EXIF data that may expose user/contributors privacy is something we may explore.

3.- IIIF level (backend/media serving?) 

All this opens a question of "discoverability" v/s "obscurity" and I feel maybe we should exclude from filtering the actual being able to find data. For totally 

The when and how:

1.- IP based embargo. This may serve the need of local VPN access/campus wide access. IP based embargoes are "hackable" and any good hacker/kid with access to google may learn how to tamper this eventually. Still we may need it

2.- Session based embargo (finer in detail that simple User/Role). This mechanic is the same as login into Archipelago but we may want to apply this to the "what"

3.- Time based. Oh (sigh) the scholarly publishing industry. Yep. we may want that. This ones should probably not be handled at an ACL level (which is like a recipe that should be stable) but more based on actual metadata found in each asset. (So driven by the content itself + logic)

4.- Inheritance based. A given Collection (without copying its rules to its child objects) may set rules that are enforced by the whole family

5.- New one. Alternative based. Let's say you have Object A, super full of rich metadata and incredible secret PDFs. Let's say you can't (someone told you nope) publish it, yet. We need to allow also an Object B, similar, maybe less rich or totally different to be a placeholder for Object A. Once A goes live and out of the airport security zone, it should replace B. This may sound similar to 1. But filtering does not allow to tell the same story differently sometimes.

So. These are the standard restrictions we plan. Any others you feel are needed for your own local needs? Control Digital lending is not something we are going to code as part of Archipelago Core, but can be done via Open Source software. (different thread, not today). Also. How do you all imagine UI/UX interfaces to allow you to apply this rules? (e.g ACLs are normally JSON files with resources/permissions/operations and agents, not cool as UI/UX). Finally, thinking back on opening closed things, how would you like to the inverse? E.g tagging these ACLs so all of a certain type can be "revoked" in a single click? Or, what if you want to give a certain user a special, time based, link to bypass the restrictions?

Anyhow. I hope anyone can share their needs/use cases or thoughts so we can focus on what is more urgent, without affecting performance and ease of use. (no worries, "all open" will be a single switch/default too!)

Thanks

Diego