3 ms·

This was my experience as well. We built a decentralized authz/authn system that used signed tokens had a lot of trouble with revocations. In the end, we had to

by iends 11y ago

This was my experience as well. We built a decentralized authz/authn system that used signed tokens had a lot of trouble with revocations. In the end, we had to give up decentralization to get quick revocation right.

EGreg 10y ago
What exactly is hard about revocations in a distributed authentication system? You have an "owner" that is authenticated (in whatever way) with the distributed system. They have a private key and a certificate, say. Now, you have a "conversation" or some other activity, which is a growing append-only merkle tree, ie everyone can "append to" a node on their copy of the tree, signed with their HMAC / certificate, and broadcast the result to whoever they want to know about it. It's a merkle tree because if I append to node X, I can prove what state the tree was in when I appended. So now, one of the operations can be granting/revoking access. The owner starts with the root of the tree and can grant access to others who get the tree to perform some operations. Later on, the owner can revoke some access in any given subtree, by posting this revoke operation on the appropriate node. It is true that a group can fork the tree and disrespect the owner, and go rogue. This is like forking the blockchain in Bitcoin. This is by design. But if all clients have a dispute resolution procedure (eg use the longest blockchain, or in this case, don't ignore the wishes of owner of the tree) then the rules are enforced. A particular conversation participant may perform an operation "after" its access has been revoked, but when it tries to broadcast it, the other clients will see its vector clock is "later" than the owner's, and reject that operation (something the rogue client will discover itself when it tries to pull updates to the conversation). An even easier way is to have each conversation have a centralized authority that must be consulted for every action. The authority can have mirrors in case it goes down. But that doesn't mean the AUTHENTICATION has to be centralized, only the authorization to post TO A PARTICULAR CONVERSATION.
- iends 10y ago
  This is all new to me. Can you recommend some further reading?
  - EGreg 10y ago
    I am not sure about the scholarly works... the main ideas are: In a distributed environment, the concept of "after" changes from a linear one to a tree one. The idea that a client can't post "after" you revoked their permission needs to be revised. If you want to maintain linear order of messages, each node in the tree has to be owned by someone. So for example I own my own comment and if someone responds to my comment I have to accept it and broadcast in what order that happened. But that doesn't require the authentication to be centralized, nor the publishing. However, there is a central authority for each node in a tree. In addition, you now have to solve the byzantine generals problem so that the servers don't say different things to different people. To be honest this same problem exists with a centralized authority, and distributed servers can be held to account better, because they don't have a monopoly.

by iends 11y ago

EGreg 10y ago

What exactly is hard about revocations in a distributed authentication system? You have an "owner" that is authenticated (in whatever way) with the distributed system. They have a private key and a certificate, say. Now, you have a "conversation" or some other activity, which is a growing append-only merkle tree, ie everyone can "append to" a node on their copy of the tree, signed with their HMAC / certificate, and broadcast the result to whoever they want to know about it. It's a merkle tree because if I append to node X, I can prove what state the tree was in when I appended. So now, one of the operations can be granting/revoking access. The owner starts with the root of the tree and can grant access to others who get the tree to perform some operations. Later on, the owner can revoke some access in any given subtree, by posting this revoke operation on the appropriate node. It is true that a group can fork the tree and disrespect the owner, and go rogue. This is like forking the blockchain in Bitcoin. This is by design. But if all clients have a dispute resolution procedure (eg use the longest blockchain, or in this case, don't ignore the wishes of owner of the tree) then the rules are enforced. A particular conversation participant may perform an operation "after" its access has been revoked, but when it tries to broadcast it, the other clients will see its vector clock is "later" than the owner's, and reject that operation (something the rogue client will discover itself when it tries to pull updates to the conversation). An even easier way is to have each conversation have a centralized authority that must be consulted for every action. The authority can have mirrors in case it goes down. But that doesn't mean the AUTHENTICATION has to be centralized, only the authorization to post TO A PARTICULAR CONVERSATION.

iends 10y ago
This is all new to me. Can you recommend some further reading?
- EGreg 10y ago
  I am not sure about the scholarly works... the main ideas are: In a distributed environment, the concept of "after" changes from a linear one to a tree one. The idea that a client can't post "after" you revoked their permission needs to be revised. If you want to maintain linear order of messages, each node in the tree has to be owned by someone. So for example I own my own comment and if someone responds to my comment I have to accept it and broadcast in what order that happened. But that doesn't require the authentication to be centralized, nor the publishing. However, there is a central authority for each node in a tree. In addition, you now have to solve the byzantine generals problem so that the servers don't say different things to different people. To be honest this same problem exists with a centralized authority, and distributed servers can be held to account better, because they don't have a monopoly.