Access Control

To expand upon Simple Signed Records which only losely outlines verification of signed requests, there should also be some form of configurable access control. The following example is tailored for the immediate use case of a dispatch and delivery system, but in theory could be refashioned for other uses cases like a collaborative blogging, etc. whereby multiple types of users can interact with records.

Types Of Keys

In order to better handle responses to various submissions, check that keys are black/whitelisted. Assuming there is a key type of record stored in a collection (called keylist perhaps) with values like:

{
   
  "identity": "CLeFY1R9zVCoG30hsW4jFUVGNI13sE1up7zd/gciVto=",
  "user_types": ["orderer"],
  "status": "trusted",
  "parent": "",
  "signature": [
      "signer": "KJebY2R3zVCoG30hsW3oFRVGNI13sB3rQ7zd/e4dg42=",
      "sig": "I6WQtPqVi+9Lm1aaVMKirVgUUu9cItDN9EBNNGnbwNjZuVA5mpnphwvdGpjXeo7X+yFiiDogLFKJOeTWv2toDA=="
   ]
}

The user_types list could contain the following types:

• orderer - one placing initial order
• shop - the person or place which the item is ordered from
• deliver - a person who moves the item from different places

Since keys (or identity) as we are using them could have all three types of access. Figuring out how to escalate (or build trust) to a given key is needed.

Allowed Actions

Assuming Shipment records have a status field with numerically ordered values like:

1 placed
2 incomplete
3 cancelled
4 collecting
5 collected
6 transit
7 delivered
8 problem

A range of actions should be available to different types of accounts (or in our case, crytographic keys) to update the Shipment record as needed by three types of keys Orderer, Shop, Deliverer.

Record Owner

By default a record created by an Orderer (keyO) should always be able to view the record and perform delete or some types of updates to that record. This case focuses on the shipment.status field for our specific delivery use case.

• keyO allowed to /info/123 for all status values
• keyO allowed to /delete/123 when status is placed|incomplete
• keyO allowed to /update/123 when status is placed|incomplete|problem

The only cases where keyO should not be allowed to update the record are where another type of user is interacting with the record- in our case, a Shop packing the items or a Deliverer handling the shipment.

• keyO NOT allowed to /update/123 when status is collecting|collected|transit

Non Record Owners

The need for Shops (keyS) and Deliverers (keyD) who need to update a record created by keyO are contextual and explained here:

• keyS allowed to /update/123 when status is placed|incomplete
• keyD allowed to /info/123 regardless of status values
• keyD allowed to /update/123 the status field with collecting|collected|transit or higher

The system also needs to protect against Evesdroppers (keyE) from viewing, editing, or deleting records.

• keyE NOT allowed to /info/123 no matter value of status

Beyond these superficial actions bound by user_type the question is how do an Orderer and Deliverer agree to interact with a given record. In the example above,

For instance, we don’t want to allow keyD2 to view or edit a record owned by keyO unless agreed upon by keyS|keyD|keyO.

Perhaps some sort of hash chain of linked records seems in order here???

NOTES:

Server: The current architecture of this doc and codebase assumes all users interact with a single trusted server. It would be great to expand upon this and allow federating or synchronizing of orders between different server, but is out of scope of this document and scheme.

Admin: Simple Signed Records and the access control system proposed assume the server is maintained by an “admin” type of user.