Feat: Programmable ACLs support

[JAG-UK]

I have taken on productisation of PR #536 - Programmable ACLs support.

This Issue covers the full suite of decisions and actions needed across the Filecoin Universe to land this feature at production quality. It does not recreate all the detailed information and discussion around it. For that, review the original PR, the Notion design page, and the gas discussion.

Scope

Services

This feature is limited to FWSS only: although it touches Curio and could relatively easily expand to other developer surfaces we will not put any effort into those (eg Storage Manager, Filecoin Pin, raw Synapse).

That said, I would strongly consider reusing it for other services where access control is an unmet requirement, such as any retrieval market.

Legacy auth

We do not plan to remove the legacy Session Key Registry: if the Authorizer contract is unset then existing SKR functionality survives.

Impact

Adding this feature brings great benefits and an essential feature to FWSS: no sensible operator - Enterprise or solo dev - will embrace storage without a notion of access control. Having programmable, per-dataset control is a real step forwards and a table-stakes feature that makes sense to invest in ahead of tested customer demand (although we also do have customer demand too, which is nice).

The downside to this feature is that it adds a lot of gas cost to FWSS operations which need to be swallowed in the SP's operation cost. I believe the impact has been evulated and considered just about acceptable, but if this feature gains significant traction we should look at optimising it. Note that the feature itself (the extension point to allow programmable access control) doesn't add much gas at all: it's the user's access control Authorizer contract that does that.

Gating decisions

1. Gas cost: the initial Authorizer contract we expect to launch with is a P256 WebAuthn Passkey verifier. Very cool, very compelling, very expensive. Adds 100M gas. PR Optional dataset-level programmable acls #536 does include a total gas cap but it's high.
2. Given that we have a gas cap, do we need to have some kind of whitelist registry of Authorizers or can we leave it as designed, a free-for-all where clients can either deploy supplied standard ones or write their own? Griefing is capped and our own use cases effectively max it out already. But other safety issues, DOS etc are real.

Full suite of PRs

This feature requires several PRs to land properly. This is an all-or-nothing set: if we decide to reject 536 then we abandon all of them.

• The main one: Optional dataset-level programmable acls #536
• A small housekeeping one: feat: programmable ACLs support #560
• Curio companion to 560: Bump extradata size limits to accommodate richer auth (programmable-acls) filecoin-project/curio#1391
• Curio implementation of optional Authorizer allowList: Feat/programmable acls whitelists filecoin-project/curio#1446
• Initial sample Authorizer contracts: Feat/p256 authorizer #587
• Dev docs: Feat: programmable acls docs synapse-sdk#905

[JAG-UK]

Another thing that niggles me a bit about the current design is that the Authorizer takes over all auto decisions including ignoring a direct signature by the data set payer.

I can see why that may be desirable in some circumstances but it also feels wasteful that every authoriser has to special case this (or demand always using a delegated key or something) when in reality the payer can always do everything, and do so on the fast and cheap signature path.

I do wonder if 536 shouldn't be amended a bit to check if caller == payer first, and always let that through, before checking Authorizer and then Session Key Registry.

NB I've left a comment to this effect on the main PR

[JAG-UK]

During my testing I wanted to have a single dataset with 2 different kinds of delegation for the same dataset:

• Machine actors with raw signatures for things like agents or CI
• Human actors with passkeys for web auth

Because the design and PR propose only a single contract address as the dataset authorizer, such complexity gets pushed down into the Authorizer contract, with its client liability, tight gas limit and so on. And to support both these paths on a single dataset I had to write an Authorizer that understood both types of authentication and switched on a flag buried in the COSE structure.

Realistically this limits the power or scope we can give to these authorizers or in other words it limits how much fine control one can have on a per-dataset level. And on the other hand it encourages clients to write more complicated smart contracts that might fail.

QUESTION: Are we happy to live with this 'feature'? I was able to do what I wanted inside the limit so I think it’s fine but it's not as neat as I'd hope for.