You are reading content from Scuttlebutt
@andrestaltz %ZqSf2KPzjOYiSwRcJgHEw0zEzHN7FAw0bwm38tKANGs=.sha256

Request for feedback

SSB Room Broker Auth

A month ago, I shared a proposal called tokenized aliases. At the same time, I've been thinking on how apps (e.g. owned by the same person) communicate with each other, and that has been the A2A proposal, but A2A is probably not going to work, because of details in various operating systems that I explained here.

Now I found a way of unifying all of those things and came up with a new proposal called Broker Auth, and I'm quite excited about it! It's a simple and flexible system that builds on top of the idea of tokenized aliases.

Link :arrow_right:


@andrestaltz %YHlPvpKDmU3cgwjAgfOuUst3EiFkUP/LCpEJj6482Fc=.sha256

@arj found a big vulnerability with this, and I described it in this issue and already drafted a solution for it. Also multi-use tokens.

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@farewellutopia %uDvsdl+65e6D7IwrScUFOb08WNfoBnWsXM1DdcxJ/Qc=.sha256

@Matt Lorentz wrote:

I could imagine a world in which my app connects very freely with peers around me, but is much more discriminating about whose posts I give to whom.

Why would you want to be discriminating about whose posts you give to whom? Isn't the beauty of ssb:feeds protocol that messages can be propagated freely, while crypto ensures we don't get counterfeit posts and nobody can read messages we don't want them to read?

For the ssb:blobs protocol I see good reasons not to host blobs from or for people we don't trust (i.e. to set the sympathy level to 0 for non-followees).

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@cel %GYDyfVMT5jcNYoxfYMg8qUpZfza10p6G6lfxbKH0F54=.sha256

I don't know if I would use this functionality, because I don't really use rooms currently.
Given the end-to-principle of decentralization, I would think it would be preferable to move functionality to the end-nodes, peers, rather than to add functionality to rooms, for what I understand to be an authorization protocol. If it is a concern of DoS, perhaps a special provisional or restricted mode could be added for new connections from unknown peers, where RPC is limited until the user approves the connection/request or the connecting peer authenticates with their token (i.e. the doorknock idea in %j2EJzTS... ). Limiting resource usage use for a connected peer at the socket level should be possible by limiting the receive buffer, i.e. just not reading from the TCP socket. This may mean reworking the stream modules, since the ssbc/muxrpc implementation currently reads continuously and buffers unboundedly. The case where I could see a need for third parties to broker authorization claims would be for privacy: to accept a SHS connection, you must confirm/reveal your public key to the client as part of the handshake; while if you reject during the handshake, it looks the same as if the connection failed because of a wrong public key or network key. In the context of rooms, I'm not sure if this privacy possibility would be realized or useful, since the room might already be claiming that the peer is in the room, and/or the peer might already be publicly self-identified with the room.

@andrestaltz %S/ADFSekasYV4IA/FtZ8ZY0/JZmzYTS8W3X1xUhsU6s=.sha256

I updated the document now to address the token exposure problem. Turns out we don't need query params, there would be just two cases:

  • https://{alias}.{domain}#{token}
  • https://{alias}.{domain} plus permissions sent via muxrpc

No need to put the permissions in the query params. I also added encryption and signatures to the muxrpc arguments, so that the room cannot pluck some argument and replace it. If it tampers them, then the alias owner will notice it.

Join Scuttlebutt now