Picos are Internet-first actors that are well suited for use in building decentralized soutions on the Internet of Things. See this description of picos for more details.

Picos send an receive messages over channels. Each channel has a non-correlatable identifier, called an ECI. Because picos can have as many channels as they like, you can use them to prevent correlation of the pico's identity without the pico's participation.

When two picos exchange ECIs to create a relationship, we call that a subscription. Wrangler, the pico operating system, supports creating and using subscriptions. Subscriptions allow picos to use peer-to-peer, graph-based interaction patterns. From a given pico's perspective, it has an inbound channel to receive messages (the Rx channel) and an outbound channel to transmit messages (the Tx channel).

Decentralized identifiers (DIDs) are a "new type of identifier intended for verifiable digital identity." DIDs are used with blockchain-based resolution to create decentralized systems. The DIDs for Hyperledger's Indy Project (and consequently the Sovrin network) are derived from, and are thus uniquely associated with, a public-private key pair.

Sean George completed a project this past Fall semester that made modifications to the channel identifier code in the Pico engine to use DIDs as the channel identifier. Because a DID is derived from an associated private key, that means that each channel also has a public-private key pair. Sean's work uses the channel keys to support signing and encrypting channel messages (using Diffie-Helman key exchange).

When a subscription is created between two picos, each pico stores the DID and public key of the incoming Rx channel. Having the public key for the other pico in the subscription allows each pico to securely message the other. There is no way to access the private keys from within KRL to protect them from unauthorized access.

This document on the Pico Labs documentation wiki includes sample KRL rules to shows how to use the built-in engine functions to sign, verify, encrypt, and decrypt messages.

Future work will focus on making the use of these functions easier and more automatic. We will also be working on integrating the Sovrin network with the pico engine. Once the DIDs are registered on the Sovrin ledger, the ledger will be used to verify the public key and outside systems will be able to make use of these capabilities without storing the public key, so long as they know the DID.