This page has three main sections. (Note that the listings could be empty.) moreā€¦ Tip: Remember the back-button! And don't click the number on the left.

  1. The first item displays a term, URL, text or picture.
  2. Followed by a (still unordered) listing of statements about this subject. (for details follow ">"-link)
  3. Separated by a horizontal rule a "reverse" listing of statements referring to this item in object position.
1887 is a > Concept
1889 description >

Access Control & Capabilities

Access control management must be encoded in the contracts code. The core idea of Askemos is however to assert that capability management is incorruptible.


Every message passed among places has a list of capabilities attached. This list contains at most all capabilities attached to the sending place.


Non-empty list of Tokens. Tokens are OID's (by convention; convenience: can use the document to describe the purpose).

Equivalence: either identical or "public" matches "public" and "private" matches "private".

Notational convention: slash-separated list, two special names "public" for public-oid() and "private" for my-oid() .

For documentation we replace OID's with capitalized name in fixed font here.

Test Predicate

To test a capability against a challenge (a.k.a. protection ) the lists representing the capability must match the challenge from either end. Access is allowed when the list are equal or the capability is either a prefix or a suffix of the protection. (Note that there there is no empty capability since this would match any challenge.)

Example: great to transfer ownership. Bob sets protection of the to-be-transfered place to Bob/Alice, now Bob can still take the offer back by changing the protection back to Bob . Alice may accept the place. To actually take ownership (i.e., exclusive control), she would set the protection to Alice only.

Initial Set

Many capability based systems assume some administrative magic for the initial capability distribution. We can not. In BALL all places are created with a certain (safe) set of capabilites attached.

  1. The topological capability: For user agents the list containing just the users OID, like Bob. For all other the list of the OID followed by the "private" OID of peer.

  2. The capability set from public: a list of the public-oid followed by the private OID of the peer.


Transfer of capabilities is restricted to transfer only strict sub-capabilities from the set attached to the sending agent. (Since we can so far only proof access control managements systems to be incorruptible if they obey the rule that there is no transitive passing of rights.) (See also RFC2693 section 4 assuming "no delegation".)

Thus Bob can transfer the capability Bob/Alice to Alice (or elsewhere), but never Bob itself. Thus Bob will always have the ability to "invent" new unique tokens having his personal prefix and nobody else ever can. (For philosophy how this is intended to model fact that human rights are inalienable see