search

joule-labs / webln

Spec and client library for WebLN apps and providers
244 stars 27 forks source link

Digital Identities #21

Open hawkmauk opened 5 years ago

hawkmauk commented 5 years ago

There has been quite a bit of work on a standard way to interact with digital identities here: https://w3c-ccg.github.io/did-spec/

It would be good to build on this for managing identities as it extends to verifiable credentials so you could provide credentials that allow you to access content based on age/location etc.

I've been working on a draft of a lightning DID spec that might be a good starting point. https://github.com/runcrypto/did-ln

wbobeirne commented 5 years ago

This makes a ton of sense to leverage for identity, and definitely seems like the way to move forward on it. I'll do a little more reading on this and come up with a proper proposal.

hawkmauk commented 5 years ago

I've explored using lightning for identity quite a bit and even started a project during the boltathon to marry the two. The thing that we found during this was that the properties for identity were actually rooted in the bitcoin UTXO rather than lightning itself. We wanted to root the state of a credential in lightning channels (i.e. whether it was valid or not) but then the channel itself is just a smart contract which can be found using any blockchain explorer.

I've found that the best place to get started on this are a couple of primers from the W3C groups that can be found here:

DID Primer Verifiable Credentials Primer

There are a couple of implementations on the bitcoin blockchain already, the flagship appears to be BTCR

PierreRochard commented 5 years ago

the properties for identity were actually rooted in the bitcoin UTXO rather than lightning itself

Why can't it just be rooted in the private key that corresponds to the lightning node's pubkey? Essentially using your node's identity as a GPG key

hawkmauk commented 5 years ago

We wanted to root the state of a credential in the existence of a lightning channel, this could then be revoked by either party. A credential is a statement about the identity that has been countersigned by a third party, for example a drivers license, that can be revoked.

We thought that a lightning client would be a great way to handle signing, verifying and searching for channels but they're just not designed for that. It's quite easy to sign a message using LND but verifying isn't great so it makes it much easier to do it with any crypto lib rather than using a third party app. As far as channel state goes, you need to search the describeGraph output (hoping that your node knows about it) when you can just check that the output address of the channel funding transaction is in the bitcoin UTXO set (i.e. not be spent in a channel closing transaction). You can use any block explorer for that.

Using the lightning nodes public key as an identifier itself has the same privacy implications as using your IP address or national insurance / social security number. Identity has the same privacy requirements as Bitcoin transaction so you want to be able to make it as hard as possible to track you digital footprints and build identity profiles.

hawkmauk commented 5 years ago

You might want to check out this: https://github.com/decentralized-identity/ion

sidhujag commented 5 years ago

What you want is a merkle root hash of state updates stored on bitcoin or other highly secured ledgers and then resolvers can index those. I’m not sure conflating a payment system with an identity (where no double spend protection is required) is the right way to go. I do agree it should be part of the experience from UX POV but the infrastructure might separate the two. The main drawback with merklized proofs is that of data availability. I think the cloud works fine for that purpose though.