Previously, I’ve been writing about how to perform task delegation with a distributed authorization scheme. While that article managed to outline the principle well enough, it left a few things not yet covered. The summary was that if we find a generic scheme for treating a resource as a series of changes, then we can encrypt and authenticate each change separately, leading to a kind of distributed authorship of resources – which is what we really want in a distributed system.

In my previous post, I was discussing how distributed authorization might be facilitated. Today, I want to discuss what effects such authorization tokens can have if we relay them, effectively achieving delegation. “The first runner in a relay - kindergarten Sports Festival.” by MIKI Yoshihito. (#mikiyoshihito) is licensed under CC BY 2.0 Distributing authorization has the immediate effect that it (mostly) eliminates authorization servers. In practice, there always needs to be a machine to issue such tokens, of course – but it does not have to be consulted for every imaginable action someone takes.

Whenever I don’t write much here, I feel like I’m not producing anything of value. Just to make myself feel better, I want to start with a quick update on what’s been happening. I was awarded a grant by the Internet Society Foundation for research into next generation internet technologies. This, for me, has a few major effects. First, it means I could hire some help in doing this R&D work with me.

There’s something rotten in the state of FOSS, and it’s not the software. It’s the community – or more precisely, the communal spirit. This post deviates a little from the regular topics. I do not intend to write a lot on this topic here, unless you, dear reader, provide me with feedback that it fits your interest. Consider it an experiment while work continues on implementing the protocol suite as usually discussed here, and there are fewer technical updates to write.