Authentication Wrapper

[metasean]

No description provided.

[amark]

Ultimately has to be probably something like PGP or pub/priv cryptography. Necessarily starting at a p2p/decentralized case, which should work for federated and centralized.

[amark]

@Annorstades continuing here. Also #48 is a good thread to check out.

Some ideas: What if we create keys based on somebody's public key? So if we do var person = gun.get('user/PUBLICKEYHERE') then that would be there data. This would be enforced by a module (the authentication wrapper) that plugs into gun and REJECTS incoming updates that don't work with the public key. Then all you have to do is make sure your app has that module and then you get what you wanted in #115 . This module has to be built though.

The downside of the gun key has the public key in it... is that keys don't enforce context. What do I mean by that? Well, let's say we have a friend, and on the friend object we have some field property that points to a user. The pointing to the user uses the UUID (or soul) of the user, not the key. So if we arrive on a user via a different path than the key, then we don't know how to enforce updates. Which is obviously bad.

So another idea is that every object has an immutable "public key" property field on it. That way every object has a context of who "owns" it. This is enforced by some module which understands that schema. Aka "Every object has to have a pub field, and reject any changes to it. New objects must be assigned a pub field." and then that module uses the pub field to authorize all incoming updates, rejecting those that do not match.

However, I'm not a security expert. Did I just misrepresent how signing works? Is what I mentioned even possible?

There are other down sides... does that allow for shared objects that multiple people can update? How do you deal with revoking access? What if a private key is compromised and you need to restart everything?

Also, all this complexity isn't needed IF you are running a centralized service (which gun can be used to build as well). If you are running a centralized service, some server can just do the authentication.

Any ideas of your own?

[emilv]

I think having a public key attached to objects would be the right way to go. That is what https://github.com/substack/swarmlog does.

Let me explain our use case: We are building a tournament system which handles scoreboards, brackets and matches. Tournaments are typically physically isolated events with unreliable Internet connections. If the connection goes down it would be awesome if the event could continue to run based on a WebRTC-synchronized database (we're keeping our eyes on the gun-rtc project). Gun fits our use cases in this regard.

Here's the problem then: Ideally everyone would use the same database, organizers, visitors and fighters. We want as many devices as possible to act as a database store. But only some of these people can be trusted, so each message must be signed with a private key and checked by other devices using the public key.

We have no trouble setting up another channel for key distribution, so we are confident that only trusted users have the private key(s).

[amark]

@emilv hey! Welcome aboard. Thanks for commenting. Yes, attaching the public key sounds like the correct way to go - please fill us in with any other thoughts/ideas that you have (since we aren't security experts the more collaboration the better).

And yes, the gun-RTC project is not dead! It is just on hold while we get our performance almost stable release out first.

Sounds like a great system! Make sure you use a CRDT counter then, something like https://github.com/amark/gun/wiki/Snippets-(v0.3.x)#counter .

Yes, as always, key distribution is the hardest part :P.

[amark]

We're getting pretty close with this, especially with AJ's OAuth3, and I have a P2P crypto example coming up soon. But because gun core won't handle this directly, this should be moved to https://github.com/gundb/feature-requests , so people know this isn't a "bug" in gun - although indeed it is a highly demanded feature! We're definitely working on it. :) Closing!