1. The world is everything that is the case [...] 1.13 The facts in logical space are the world — Wittgnstein, Tractatus Logico-Philosophicus
Content itself doesn’t have an implicit owner. Instead, let’s consider the space of all content. It has an X-axis — the types of content. It has a Y-axis — the range of elements of that type to be conferred. And it has a Z-axis — the depth or variety of rights you have over the other dimensions.
This authorization space includes all possible resources that can be addressed. In fact, UCANs themselves are entities that live in the authorization space, as well as their contents.
Judgements about the authorization space are constructive. While it’s technically possible to express concepts like negation, we generally limit ourselves to making true statements and present positive facts.
A resource is a pointer (e.g. URI, CID, address) that represents a thing to be acted on. Examples include:
The potency are the rights on some resource. Each potency type has its own elements and semantics. They may by unary, support a semilattice, be monotone, and so on. Potencies may be considered on their own — separate from resources — and applied to different resources.
APPEND is a potency for WNFS paths. The potency
OVERWRITE also implies the ability to
On the other hand, email has no such tiered relationship. You may
SEND email, but there is no ”super send”.
An authorization scope is the tuple
resource x potency. Scopes compose, so a list of scopes can be considered the union of all of the inner scopes.
You can think of this as ”scoping” the total rights of the authorization space down to the relevant volume of authorizations.
Inside this content space, can draw a boundary around some resource(s) (their type, identifiers, and paths or children), and ther capabilities (potencies).
As a practical matter, since scopes form a monoid, you can be fairly loose: order doesn’t matter, and merging resources can be quite broad since the more powerful of any overlap will take precidence (i.e. you don’t need a clean separation).
Proofs are existing facts. Typically these are UCAN chains, leading back to a self-evident origin token.
The originating UCAN contains no proofs. It is merely a UCAN signed by the private key associated with the corresponding account’s DID. As such, the proof is the signature itself. We call these ”self-evident” or “origin” UCANs.
Logical or self-evident facts are a related form of proof. A statement of fact may be the inclusion of a CID in a Merkle tree , or a statement about the input to a hash.
As a simple example:
SHA256(”hello world”) = 0xa948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447
Perhaps nonintuitively, signing a challenge string also constitutes a fact: that you know the private key associated with some public key, despite not giving away the actual private key.
UCANs allow agents to delegate some (or all) of their rights to other agents — i.e. to act on their behalf. These form chains going all the way back to the resource originator/owner. Delegation (output) is always a subset of the proofs (inputs).
As mentioned earlier, scopes can be merged (set union). If merging the inputs (proofs), the output scope is a subset of the proof union. While this relationship commutes, it needs to be emphasized that if any proof of a certain input scope is given, it may be included in the output authorization scope.
There is no way to provide a proof that negates another inside a UCAN. UCANs can be negated at the whole-UCAN level only. Please see the revelant section for more.