Verifiable credentials and libp2p

Implementers and Contributors
1

Hi - we’re looking into libp2p as a network stack for our application and exploring how we could integrate verifiable credentials (https://w3c.github.io/vc-data-model/) infrastructure. A basic use case is that of a node being challenged to provide some specific credential to join the network. The bootstrap node handling the incoming connection should verify the credential with the issuer and complete the connection/bootstrap or terminate it.

Wanting to implement the scenario above, can we intercept the bootstrap connection on the receiver node and inject our verification logic? And what is the best way, for a node, to send some extra blob of data representing a VC?

We just started looking into go-libp2p and any pointer into the right direction would be greatly appreciated.

PS: I originally posted this as an issue here https://github.com/libp2p/libp2p/issues/78 but I only discovered this forum since.

2

You could accept streams from all peers that want to join the network, and execute custom authentication protocol on top of it. Then you reset any stream that did not pass authentication.

Also look at ConnManager component.

3

Thanks for replying - we managed by implementing the ConnectedF callback and by setting a stream handler:

host.Network().Notify(&inet.NotifyBundle{
	ConnectedF: func(n inet.Network, c inet.Conn) {
		// Open stream and read auth challenge and remove remote peer if failed
		stream, err := nn.Host.NewStream(nn.ctx, c.RemotePeer(), MyProtoID)
		// read challenge from stream 
		// do checks and close connection if necessary
	},
})

nn.Host.SetStreamHandler(ProtoID, func(stream network.Stream) {
	// write challenge to stream			
}

The main problem I see in this approach is that the security checks are performed when the node is already connected (ConnectedF). The node is disconnected only after the checks have failed.

I don’t see how ConnManager helps preventing the connection to be accepted if the incoming node isn’t authorised… It feels like as if we have to extend the nodes’ authentication handshake OR maybe we have to use a transport upgrader to intercept the connection creation (here we may have to use a separate socket channel to exchange secrets etc)

Thanks in advance for any other pointers you may be able to share.

1 Like