| Signature Structure | Sub-key registration |
Least/Less Authority
Before we end this deep-dive series with a discussion on the creation and revocation of attenuated authority keys, we are going to discuss the principle of least authority. The Principle Of Least Authority (POLA) is a system design philosophy, geared towards robustness, that aims to provide any sub-system with exactly the amount of authority it needs and nothing more. The most fundamentally POLA system possible today is a system build on the basis of so-called Object Capabilities.
Now before you get exited thinking coinZdense will give you some sort of Object Capability system, let me start off by bursting that bubble. We won't, we can't. But what we can do is try to come as close to the Principle Of Least Authority as the technology allows us without sacrificing on the design goal prioritization of the project.
The first thing we need to realize before discussing authority, is that the bar for what composes authority is pretty low for POLA. When thinking about signing keys and blockchain transactions, if you know about the three privilege levels for keys in HIVE (the platform I'm posting these deep-dive posts on), you might think POSTING key privileges, granting low-level operation signing rights is probably the lowest level of authority. Well, it isn't, not by far. For one, these operations being stuck in a group not being further decomposable or attenuatable isn't exactly POLA. Secondly, the operation authorities are often partially disjunct from the thing they actually apply to. For example, if on HIVE you are reading this post in the first week after I posted it, your POSTING key gives you the authority to upvote or downvote this post, ANY post, actually. So even if the authority could be decomposed, what it applies to can not.
At this level, coinZdense won't be able to offer 'least' authority. It shall do it's best however to offer blockchain projects using it the choice to opt for 'less' authority. It does this by offering them the possibility to compose a singly-rooted authority tree for their project. It's a static authority tree for blockchain operations, so no object level decomposition or object capabilities or anything close, but still a chance of using fine-grained authority for derived keys.
But least authority doesn't stop there. It also applies to resources. As we already discussed in the post on index-space, system entropy is a resource that can be exhausted. That's why coinZdense doesn't rely on system entropy other than for seed creation and wallet password seeding. Hash-based signing keys in a fundamental way are a resource, too. Each level key can sign only so much digests before it gets exhausted and needs to be replaced. And last not not least, on-chain information storage is a resource. coinZdense relies on on-chain information storage for every owner key and every attenuated authority key.
This last part is important when we look at why coinZdense chooses to not let attenuated authority keys live in their own index-space even though they live in their own (although derived) master-key space. We do our best to avoid any kind of amplification from taking place, so if an owner key has the potential to allocate a certain amount of resources, and an active key is derived from that, that active key, apart from an attenuated part of the authority will get a subsection of the potential for resource allocation. Creating sub-keys should never lead to the resource allocation potential of the owner-key and all the sub keys to outgrow the initial resource allocation potential of the owner key.
These are quite fundamental choices for coinZdense and choices that make writing the parameterization of coinZdense in a blockchain RC file quite a challenge, as writing the RC file becomes a resource allocation problem to a huge extent. Index-space is the most obvious resource here, but remember, where least, or even less authority is concerned, the 'being a resource' part is very important, and fundamentally hash-based signing keys are all about signing capacity being a resource in the first place.
So far, this post has probably been the least deep-dive post in this deep-dive series, and a more philosophical one, but I think it is a critical part of the design decisions made for coinZdense, that need to be understood for this deep-dive as a whole to make sense.
So summarizing, coinZdense aims for being a less authority, rather than a least authority solution, because being what it is, it's the best we can do. It is known that in the past least authority systems have been build on similar foundations, so it might be possible for others to built least-authority or even capability based systems on top of this less authority foundation.
In the next two posts, we are going to look a bit at the blockchain side of the resource discussion, sub-key registration and sub-key revocation. Hopefully in those two posts, you will recognize what we discussed in this post here today.
| Signature Structure | Sub-key registration |
|
|
|