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 this article, I’ll explore the meaning of key concepts of access control in a distributed system, as well as outline some high-level requirements deriving from that. Following articles can then …

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.

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. As I briefly discussed previously, authorization tokens can last a fairly long time (but should not last infinitely), and we can query for revocations quite carefully.

This attempt to eliminate authorization …

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 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. Adrian, my first freelance collaborator, is going to focus on conflict-free replicated data types. How precisely that fits into the Interpeer Project, I will write about later.
• Second, it’s a step forward into doing this full-time, which I wanted to do when I set out to do it. Not immediately, …

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.

I have a few answers here, and they all go back to where this inspiration for channels comes from. The answers, then, don’t exactly match up 100% with each other, but I consider each of them entirely valid. Let’s just …