Status List: file_path is currently required, requiring an additional service/volume mount to serve the list

[TheTechmage]

Current behavior

The status_list plugin requires file_path (or STATUS_LIST_FILE_PATH) to be set at startup. If it is missing, the plugin raises a ConfigError and refuses to load:

acapy-plugins/status_list/status_list/v1_0/config.py

Lines 58 to 63 in 28f0af8

	if not public_uri:
	raise ConfigError("public_uri", "STATUS_LIST_PUBLIC_URI")
	if not file_path:
	raise ConfigError("file_path", "STATUS_LIST_FILE_PATH")
	return cls(list_size, shard_size, public_uri, file_path)

This means that even if an organization would prefer a different approach, every deployment must provide a persistent volume and a separate HTTP server to serve the published files.

What we'd like to discuss

The underlying bitstring data already lives in the ACA-Py wallet (Askar) as StatusListShard records. The plugin could expose a public route (something like GET /status-list/{tenant_id}/{list_number}) that assembles and serves the status list on demand with no file system involvement.

This would make file_path optional, allowing:

• Deployments that want static file serving (e.g. for CDN caching) keep the existing publish flow unchanged
• Deployments that prefer simplicity get a working status list endpoint out of the box, with no volume mount or sidecar required

It also opens the door for controllers to handle publishing themselves. A controller would be able to call the publish endpoint after a revocation event and store or forward the result depending on the way their infrastructure is setup, rather than being forced into the file-based path.

Proposed change

1. Add a public GET /status-list/{tenant_id}/{list_number} route that generates the status list JWT on the fly from Askar shard records
2. Make file_path (and the publish-to-file flow) optional rather than required
3. public_uri would point to either the new built-in route or an external server, depending on the deployment

Questions for the community

• Is the file-based requirement intentional for a specific reason we're missing?
• Any concerns with serving directly from ACA-Py (performance, security)?
• Would this be a welcome contribution?

Tagging @timbl-ont. @PatStLouis mentioned your team was using this in production. If we could get your input on this, that'd be great!

[timbl-ont]

@weiiv can you take a look at this issue.

[timbl-ont]

The primary concern is security. The ACA-Py API endpoints are for internal functions - admin, issuance etc.. The public routes should be separate. The OID4VC plugin has the functionality that you are looking for. This plugin maintains a separation between public and private routes - #1971

The publishing support is for security and scalability reasons especially in large enterprise deployments.

Looking into making the file_path and URL optional.