Verifiable Credentials for Fine Grained Access Control

If you are familiar with public key certificates, you would probably understand Verifiable Credentials (VC). VCs are json formatted credentials that are cryptographically verifiable by itself. It consists of 3 major attributes: an issuer, a claim called credential subject, and a proof. The issuer is the entity which creates and signs the VC. The credential subject is a claim, for example, stating that this entity is over a certain age, or that this entity graduated from a certain university. The proof is the signature saying the credential subject holds true and is cryptographically verifiable.

One interesting application of this credential format is to use it for access control. Suppose there is a service named Telemetry Gateway or TG that accepts billions of incoming messages of devices from an insecure network. If all messages of the devices hold cryptographic proof saying that "this message is authorized to get consumed by TG", TG does not need to maintain its own access control list. It just need to rely on the messages themselves, making the service more scale well.

Another interesting scenario is when an entity, it can be a person, a company, or a thing, wants to send a specific command to a device. How would the device authorize the command without creating a complex identity and access management that needs to scale to billions of devices? The entity can embed a VC to the command telling the device that it is authorized to send this command by some other trusted party. Below is an example of VC used for access control:

{
  // define terms
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://iot-exchange.equinix.com/2018/contexts/iot/access-control/v1"
  ],
  // specify the identifier for the credential
  "id": "https://iot-exchange.equinix.com/credentials/1872",
  // the credential types, which declare what data to expect in the credential
  "type": ["VerifiableCredential", "IoT","AccessControl"],
  // identifier for the entity that issued the credential
  "issuer": "did:ion:937d47150f824b3da043ea13c5881530",
  // when the credential was issued
  "issuanceDate": "2020-01-01T19:73:24Z",
  // claims about the subjects of the credential
  "credentialSubject": {
    // the subject of the credential is the entity to which the IoT Exchange
    // is granting access.
    "id": "did:ion:ebfeb1f712ebc6f1c276e12ec21",
    // assertion is the rights grant for access, including the DIDs of the IoT
    // devices
    "accessRequest": {
       // DIDs for the IoT devices
       "ids": ["did:ion:c276e12ec21ebfeb1f712ebc6f1", "did:ion:8916e7a9f62d47988ceb6980e0bffd58"],
      // schema for requested data.
      "schema": "https://iot-exchange.equinix.com/schemas/42",
      // start of the data reporting
      "start": "2019-07-21T17:32:28Z",
      // end of the data reporting
      "end": "2019-08-12T08:10:35Z",
      // how frequently to report (hrs:min:sec)
      "period": "00:10:00",
      // Any post processing steps
      "postProcessing": ["privacyPreserving"],
      // where to send the data
      "dataSink": "https://www.stanford.edu/traffic-management-institute/dataStore",
      // do we need any other attributes?
    }
  },
  // digital proof that makes the credential tamper-evident
  "proof": {
    // the cryptographic signature suite that was used to generate the signature
    "type": "RsaSignature2018",
    // the date the signature was created
    "created": "2017-06-18T21:19:10Z",
    // purpose of this proof
    "proofPurpose": "assertionMethod",
    // the identifier of the public key that can verify the signature
    "verificationMethod": "https://example.edu/issuers/keys/1",
    // the digital signature value
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

The credential subject contains attributes on how the device would allow the user to access it. Device would use the proof to validate the authenticity of the whole document, by verifying the digital signature against the _verificationMethod_, usually made of the public key or the DID of the party who signed it.

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