dsb: DID-authentication based storage server

dsb is a PoC of storage server based on the didcomauth library, providing on-disk persistence of data sent by authorized peers.

Usage and building

dsb provides the standard DID-based authentication endpoints, as well as:

• a protected /protected/upload/{id} endpoint, where authorized peers upload data via POST form - the dsb admin can decide whether a DID can upload to a given id by means of the cmd/dsb-add-didres software,

• an unprotected /get/{id} endpoint, where users can retrieve data contained at id.

• an unprotected /add endpoint, where users can add new resources/DID pairs remotely, in a manner similar to cmd/dsb/add/didres.

To use the /add endpoint, just do a POST request to http://localhost:9999/add with the following headers:

• X-Resource, resource to protect behind DID authentication
• X-DID, DID to associate to the resource

The standard procedure described in didcomauth applies to dsb too: DID-authenticated upload resources must be referenced under the /protected/upload/ prefix (authorizing the abc resource means authenticating /protected/upload/abc)

See cmd/dsb-do-upload for a request example.

The resource/DID mapping is held either in a Redis instance or in a in-memory map.

To build dsb, the standard Go procedure must be followed:

$ go build -o dsb -ldflags="-s -w"

Configuration

Environment variable	Required	Default	Meaning
DSB_STORAGE_PATH	no	./dsb	path where dsb will save data
DSB_LOG_PATH	no	./dsb.log	path where dsb will save its logs
DSB_DEBUG	no	false	enables debug output
DSB_REDIS_ADDR	no	localhost:6379	Redis host for caching and storage
DSB_CACHE_TYPE	no	0	cache/storage type, 0 for Redis, 1 for in-memory map
DSB_JWT_SECRET	yes	none	JWT secret used to sign didcomauth tokens
DSB_COMMERCIO_LCD	no	http://localhost:1317	commercio.network LCD REST server used for DDO resolution