"physical-lock": Interfaces, server and client implementations

This CL adds the interface for a lock server, an implementation
of a server object that exposes those interfaces, and a command-line
client for communicating with the server.

The server does not rely on any external service. It acts as an identity
provider and mounts itself in a local mounttable server that advertises
its location using MDNS.

Clients discover servers through the neighborhood. Clients are
authorized by a server only if they present a specific blessing rooted in the
server's identity provider. This blessing is handed out by the server at
the time of initialization.

A server can be initialized exactly once on a first-come-first-served
basis.

MultiPart: 1/2
Change-Id: I2cb4716b97fdd2036d4aef0a4b26b4e48d97b4be
17 files changed
tree: d5be8a63ed5c1b136849bc25e3e52f848470e51a
  1. go/
  2. .gitignore
  3. AUTHORS
  4. CONTRIBUTORS
  5. LICENSE
  6. PATENTS
  7. README.md
  8. VERSION
README.md

Physical lock

This is an example application built on the Vanadium stack.

Development

Features to add to the Lock server:

  1. Auditing: This is one of the strong features of our model, so I‘d imagine that we’d want a: AuditLog(startTime, endTime time.Time) []AuditLog | error type AuditLog struct { Blessing string Action LockStatus Timestamp time.Time } We'd also have to work out how to control access to this AuditLog. One option is to use caveats - so when “making” a new key one can choose to insert the “noadmin” caveat?

Features to add to the Lock client:

  1. “makekey”

makekey makekey creates a key for the specified lock and principal. is the name of the lock object for which ‘key’ should be created, and is the public key of the principal to which the minted key must be bound to.

  1. “sendkey” sendkey sends a key for the specified lock and any principal with the specified who is current running “recvkey”.

Deployment