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.

In previous posts, I spent some time describing a protocol design for negotiating independent channels over a shared connection of sorts. That’s all well and good, but it does beg the question what purpose channels serve. In the abstract, it is just what I just wrote, a mechanism for conducting multiple parts of a larger communication in parallel, and independent of each other. But while that description is apt enough, it also leaves a lot of questions open.