Meadowcap
Status: Candidate (as of 17.01.2024)
Meadowcap is a capability system for use with Willow. In this specification, we assume familiarity with the Willow data model.
Overview
alj: TODO
Parameters
Like the Willow data model, Meadowcap is generic and needs to be instantiated with concrete choices for the parameters we describe in this section.
Meadowcap makes heavy use of digital signature schemes; it assumes that Willow uses public keys as NamespaceIds and SubspaceIds.
A signature scheme consists of three algorithms:
- generate_keys maps a seed to a public key and a corresponding secret key.
- sign maps a secret key and a bytestring to a signature of the bytestring.
- verify takes a public key, a signature, and a bytestring, and returns whether the signature has been created with the secret key that corresponds to the given public key.
An instantiation of Meadowcap must define concrete choices of the following parameters:
- In owned namespaces, all valid capabilities stem from knowing a particular secret key of the namespace_signature_scheme.A signature scheme namespace_signature_scheme consisting of algorithms namespace_generate_keys, namespace_sign, and namespace_verify. The public keys have type NamespacePublicKey, and the signatures have type NamespaceSignature.
- An encoding function encode_namespace_pk for NamespacePublicKey.
- An encoding function encode_namespace_sig for NamespaceSignature.
- Users identities are public keys of the user_signature_scheme. Further, SubspaceIds must be public keys of the user_signature_scheme as well. In communal namespaces, all valid capabilities stem from knowing a particular public key of the user_signature_scheme.A signature scheme user_signature_scheme consisting of algorithms user_generate_keys, user_sign, and user_verify. The public keys have type UserPublicKey, and the signatures have type UserSignature.
- An encoding function encode_user_pk for UserPublicKey.
- An encoding function encode_user_sig for UserSignature.
- A function is_communal that maps NamespacePublicKey to booleans, determining whether a namespace of a particular NamespaceId is communal or owned.
- Limits on the sizes of the Paths and their Paths that can appear in capabilities:
- A natural number max_component_length for limiting the length of individual Components.
- A natural number max_component_count for limiting the number of Components per Path.
- A natural number max_path_length for limiting the overall size Paths.
A Meadowcap instantiation is compatible with Willow ifalj: TODO defref styling is broken in the preview of campatible for some reason
- the Willow parameter NamespaceId is equal to the Meadowcap parameter NamespacePublicKey,
- the Willow parameter SubspaceId is equal to the Meadowcap parameter UserPublicKey, and
- the Willow parameters max_component_length, max_component_count, and max_path_length are equal to the Meadowcap parameters max_component_length, max_component_count, and max_path_length respectively.
Throughout the Meadowcap specification, we use these pairs of parameters interchangeably.
Capabilities
Intuitively, a capability should be some piece of data that answers four questions: To whom does it grant access? Does it grant read or write access? For which Entries does it grant access? And finally, is it valid or a forgery?
We define three types that provide these semantics: one for implementing communal namespaces, one for implementing owned namespaces, and one for combining both.
Communal Namespaces
A capability that implements communal namespaces The kind of access this grants. The namespace in which this grants access. alj: fix marginale renderingRemember that we assume SubspaceId and UserPublicKey to be the same types.The subspace for which and to whom this grants access. Successive authorisations of new UserPublicKey, each restricted to a particular Area.}The access mode of a CommunalCapability cap is communal_mode_cap.access_mode.
The receiver of a CommunalCapability is the user to whom it grants access. Formally, the receiver is the final UserPublicKey in the delegations, or the user_key if the delegations are empty.
The granted namespace of a CommunalCapability is the namespace for which it grants access. Formally, the granted namespace of a CommunalCapability is its namespace_key.
The granted area of a CommunalCapability is the Area for which it grants access. Formally, the granted area of a CommunalCapability is the final Area in the delegations, or the subspace area of the user_key if the delegations are empty.
Validity governs how CommunalCapabilities can be delegated and restricted. We define validity based on the number of delegations.
Every CommunalCapability with zero delegations is valid.
For a CommunalCapability cap with more than zero delegations, let TODO
