Blockchain Extensions for Linked Data Signatures

by Manu Sporny, Harlan Wood, Noah Thorp, Wayne Vaughn, Christopher Allen, Jason Bukowski, and Dave Longley

A White Paper from Rebooting the Web of Trust III

Introduction

The term Linked Data is used to describe a recommended best practice for exposing, sharing, and connecting information on the Web using standards, such as URLs, to identify things and their properties. When information is presented as Linked Data, other related information can be easily discovered and new information can be easily linked to it. Linked Data is extensible in a decentralized way, greatly reducing barriers to large scale integration.

With the increase in usage of Linked Data for a variety of applications, there is a need to be able to verify the authenticity and integrity of Linked Data documents. The Linked Data Signatures specification added authentication and integrity protection to linked data documents through the use of public/private key cryptography without sacrificing Linked Data features such as extensibility and composability.

Recently, there has been interest in extending Linked Data Signatures to support new use cases surfaced in the Blockchain and Verifiable Claims ecosystems. These use cases include:

This whitepaper explores various extensions to the Linked Data Signatures specification that are designed to support the use cases listed above.

Support for secp256k1

Support for Bitcoin-style secp256k1 signatures would result in a signature block that looks like the following:

"signature": {
  "type": "sha256-ecdsa-secp256k1-2016",
  "created": "2016-09-22T22:38:03Z",
  "creator": "bitcoin-address:1LGpGhGK8...rP4xWER",
  "domain": "example.com",
  "nonce": "ba9e0b95",
  "signatureValue": "IKwTJ...E37UsLgs="
  }

This signature would require the creation of a new Linked Data Signature Suite specification defining the following parameters:

There are a few open questions that need to be discussed at Rebooting Web of Trust:

Support for CamLys

Support for Camenisch-Lysyanskaya style signatures would result in a signature block that looks like the following:

{
  "@context": "https://w3id.org/anoncreds/v1",
  "homeState": "Virginia",
  "signature": {
    "type": "CamLys2016",
    "created": "2016-09-22T22:38:03Z",
    "creator": "https://blue.example.com/keys/1",
    "claimDefinition": "https://blue.example.com/definitions/drivers-license",
    "revocationTails": "https://blue.example.com/tails/set-32893",
    "revocationTailsHash": "urn:sha256:43903bab3b4b2b3b4b4b2bb2b8384ad457",
    "accumulator": "https://blue.example.com/accumulator/set-32893",
    "domain": "example.com",
    "signatureValue": "IKwTJ...E37UsLgs="
  }
}

This signature would require the creation of a new Linked Data Signature Suite specification defining the following parameters:

Blockchain Anchoring

Blockchain anchoring techniques are used to prove that data existed at a specific point in time. These techniques cryptographically embed data in a blockchain by publishing a hash of the data in a blockchain transaction. By comparing the hash embedded in a blockchain with the hash of a set of data, it’s possible to verify that the data existed at a specific time.

Merkle trees are often used to store and hash the data, enabling large volumes of data to be stored into blockchains like the Bitcoin blockchain. These mechanisms, such as Chainpoint and OpenTimestamps, are currently in the experimental standardization phase. It is possible to merge approaches like Chainpoint with Linked Data Signatures. The Linked Data Signatures Proof of Publication specification is one such approach, where the blockchain receipt may be embedded in the Linked Data Signature without any modification to the LinkedDataSignature2016 signature suite.

Included is an example of a Proof of Publication style Linked Data signature:

"signature": {
    "type": "LinkedDataSignature2015",
    "creator": "http://example.com/i/pat/keys/5",
    "created": "2011-09-23T20:21:34Z",
    "domain": "example.org",
    "nonce": "2bbgh3dgjg2302d-d2b3gi423d42",
    "merklePublicationProof": {
      "@context": "https://w3id.org/chainpoint/v2",
      "type": "ChainpointSHA256v2",
      "targetHash": "bdf8c9b...cb8e85ef2",
      "merkleRoot": "51296f46...6581a7a",
      "proof": [
        { "left": "bdf8c9b...e85ef2" },
        { "left": "cb0dbbed...2e49faf" },
        { "right": "cb0dbb...2e49faf" }
      ],
      "anchors": [{
        "type": "BTCOpReturn",
        "sourceId": "f3be82...fadee"
      }]
    },
    "signatureValue": "OGQzNGVkMz...ODIyOWM32NjI="
}

There are a few open questions that need to be discussed at Rebooting Web of Trust:

JSON Normalized Clear Text Signatures

The JSON Web Signatures (JWS) specification defines how one may perform digital signatures on a block of JSON data. While ideal for a number of use cases that require digital signatures, the approach is not a good fit for other use cases that require digital signatures. For example, data signed using JWS, called JSON Web Tokens (JWT), are base-64 encoded. This creates a number of problems for developers:

Linked Data Signatures were originally designed to sign Linked Data and overcome the shortcomings of JWTs above. There have been several requests over the years to support clear JSON signatures, resulting in a signature block that looks like this:

"signature": {
   "type": "JsonSignature2017",
   "created": "2017-01-02T12:11:54Z",
   "creator": "https://example.org/keys/123",
   "domain": "example.com",
   "nonce": "ba9e0b95",
   "signatureValue": "IKwTuQqTwz...IEBAE3sLgs="
 }

Doing so requires a new JSON Normalization Algorithm specification and a Signature Suite with the following properties:

There are a few open questions that need to be discussed at Rebooting Web of Trust:

JWT-style Linked Data Signatures

It has also been postulated that JWT-style digital signatures could be encapsulated in Linked Data Signatures producing a signature format that looks like the following:

"signature": {
    "type": "Jwt2017",
    "signatureValue":    "
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2Rtdi\n
CJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJkaWQ6ZWJmZWIxZjcxMmVi\n
YzZmMWMyNzZlMTJlYzIxIiwiZW50aXR5Q3JlZGVudGlhbCI6eyJAY29udGV4dCI\n
6Imh0dHBzOi8vdzNpZC5vcmcvc2VjdXJpdHkvdjEiLCJpZCI6Imh0dHA6Ly9leG\n
FtcGxlLmdvdi9jcmVkZW50aWFscy8zNzMyIiwidHlwZSI6WyJDcmVkZW50aWFsI\n
iwiUHJvb2ZPZkFnZUNyZWRlbnRpYWwiXSwiaXNzdWVyIjoiaHR0cHM6Ly9kbXYu\n
ZXhhbXBsZS5nb3YiLCJpc3N1ZWQiOiIyMDEwLTAxLTAxIiwiY2xhaW0iOnsiaWQ\n
iOiJkaWQ6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwiYWdlT3ZlciI6Mj\n
F9fX0.LwqH58NasGPeqtTxT632YznKDuxEeC59gMAe9uueb4pX_lDQd2_UyUcc6\n
NW1E3qxvYlps4hH_YzzTuXB_R1A9UHXq4zyiz2sMtZWyJkUL1FERclT2CypX5e1\n
fO4zVES_8uaNoinim6VtS76x_2VmOMQ_GcqXG3iaLGVJHCNlCu4"
  }

Doing so would require new JSON Normalization Algorithm specification and a Signature Suite with the following properties:

This would raise the following open questions that would need to be discussed at Rebooting Web of Trust:

Next Steps

In this paper, four extensions to the Linked Data Signatures specification have been introduced. The authors of the paper would like to explore each extension in more detail at the Rebooting Web of Trust III Workshop and produce one or more W3C-formatted specifications that summarize the state of findings during the course of the workshop.