Using Proof to Verify the Controller of a Decentralized Identifier

In Sidetree, the owner of the DID is the only . Concretely, only the public keys of the DID Document being processed can verify who can perform operations on the DID Document, such as DID Document modification or revocation. But the DID specs defines that we can delegate another entity that can do DID Document operations on behalf of the owner, by adding a _controller_ attribute. Furthermore, we can also add an optional _proof_, a signature generated by either the owner or a controller! A controller signing the proof means that a third party entity (the controller) is attesting the integrity of the DID Document. Below is a sample of a DID Document persisted to the Sidetree network. The proof is signed not by the owner but by a controller whose DID is did:example:bcehfew7h32f32h7af3. 

 {
  "@context": "https://www.w3.org/2019/did/v1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3",
  "publicKey": [{
    "id": "#keys-1",
    "type": "Secp256k1VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
  }],
  "proof": {
    "type": "LinkedDataSignature2015",
    "created": "2016-02-08T16:02:20Z",
    "creator": "did:example:bcehfew7h32f32h7af3#keys-1",
    "signatureValue": "QNB13Y7Q9...1tzjn4w=="
  }
}

Here is a simple scenario: Suppose you received a telemetry message somewhere from an insecure network. The message is telling you that it this is the GPS location of a certain person around this time. The message is signed by some specific device DID and is also saying that the message is coming from IoT Exchange Telemetry, a well known trusted telemetry service. How would you know that the message is not tampered? How will you prove the authenticity of the device DID? 

First, you use the device DID to resolve the DID Document from any Universal Resolver. You use the public key from the DID Document to verify the signature of the message. Valid signature means you have proven the ownership of the message. Now you want to know if the device is really from IoT Exchange Telemetry. You check the device DID Document again and look at the proof attribute. You see that the _creator_ is the DID of IoT Exchange Telemetry, a publicly published trusted DID. You verify the _signatureValue_ in that proof against the _creator_. You do this by resolving the DID Document of _creator_ DID and use the public key to validate _signatureValue_.

Comments

Post a Comment

Popular posts from this blog

The Sidetree Protocol

Blockchain scalability is a non-trivial problem, but there is now a promising strategy for scaling blockchain-based systems known as ‘Layer 2’ protocols, or L2s, for short (example: Bitcoin’s Lightning Network). L2s achieve scalability through deterministic processing and transaction schemes that take place ‘above’ the blockchain, with zero or minimal consensus requirements beyond small points of interaction with the underlying chain. For decentralized identity to become a reality, it requires a system that operates at massive scale, while still delivering on important features, such as deterministic state resolution and differential persistence. Using blockchains for anchoring and tracking unique, non-transferable, digital entities is a useful primitive, but the current strategies for doing so suffer from severely limited transactional performance constraints. Sidetree Entities is a Layer 2 protocol for anchoring and tracking entities across blockchains. Sidetree Enities, and nod...
Read more

On the IoT Exchange - DID integration

One of the challenges of introducing Decentralized Identifiers (DID) into Internet of Things (IoT) is the proprietary nature of the IoT ecosystem. Most IoT devices use proprietary technology. The ideal way of integrating DIDs is to put the keys and some cryptographic operations directly into the device. The assumption here is (1.) the manufacturer themselves can either generate and embed the keys from a secure or "offline" environment or (2.) manufacturer can embed cryptographic logic into the device and the device would generate the keys themselves, given that the device has enough power to execute the operations. If we are going create a service from DIDs and we do not have any access to the device manufacturing process, we may need to generate and maintain the keys elsewhere, but we need to make sure the pathway from that "elsewhere" to the device is _secure_, and how that secured pathway is implemented is *out* of the scope of this post. That "elsewher...
Read more

Smartkey Overview

Whenever we write applications, we need to keep our _secrets_ in a single central secure place. These secrets can be your password to your database, your api key, or your cryptographic keys used for signing messages. There are two major reasons why we want to do this. The first one is we want these secrets to be fetched by multiple instances of the application from a single place, instead of duplicating or hardcoding them in the application. This secure place may be a keystore stored in a directory in a file server, but making it reachable across different environments, specially when dealing with software development in the cloud, ultimately becomes a challenge. Nowadays, this is implemented as a service, where it expose endpoints easily accessible to applications for fetching the secrets themselves. Aside from key access, these type of services often offer key management solutions such as key rotation and key revocation. These solutions are sometimes referred as key management servi...
Read more