Blockcerts and Open Badges signature alignment

by Kim Hamilton Duffy (with input from Philipp Schmidt and Nate Otto)

Note on terminology

(alternatives welcome)

This uses the term "document" to refer to a credential being issued to a recipient. This is to avoid confusion with terms that already have precise meanings in the Verifiable Claims data model. Note that the existing Open Badges/Blockcerts formats roughly correspond to a set of Claims and Identity Profiles in the VC definitions.

Context

Blockcerts is a certification infrastructure that puts recipients in control of their achievements and accomplishments. It consists of open standards and open source libraries enabling blockchain issuing and verification of documents. Blockcerts is Open Badges compliant, and is working with the Open Badges Initiative (OBI) to contribute blockchain extensions back to the Open Badges standard, enabling blockchain verification for the broader OBI community.

Why we have not used CA-based PKI approaches, and why RWoT

There are 2 aspects to why we have avoided CA-based PKI approaches:

Scalably enabling trustless verification

Blockcerts uses blockchain, as opposed to traditional PKI techniques, to scalably enable trustless verification. The verification process requires a reliable timestamp at which the transaction occurred. This, combined with public key(s) (with or without expired dates) claimed by the issuer, are used to ensure the transaction happened at a time when the issuer claimed ownership of the key. This is essential for alowing issuer rotation of keys without invalidating previously issued, but valid documents.

With blockchain approaches, the timestamp (and contents) are tamper proof by construction. We considered PKI type approaches, but there are a range of technical and philosophical issues, ranging from needing to rely on a timestamp authority server, trust in the certificate authority, and potential barriers to entry this would impose.

Integration of decentralized identification approaches in the Blockcerts ecosystem

The Blockcerts project intentionally does not address identity -- participation requires only cryptographic keys. Yet, identity is a critical aspect of a deployed Blockcerts system. And while it will never be part of the Blockcerts core, we are researching best practice approaches for our deployments and as recommendations for the community.

RWoT's efforts on decentralized identity are well aligned to our goals of enabling open participation and recipient control. We are also interested in other efforts promoted by this group: - Verifiable Claims (and general alignment of OBI with VS data model) - JSON-LD signatures - Proof of publication

Rebooting Web of Trust Spring 2017 Topics (summary)

Our near-term goal is to align the Blockcerts/OBI signature formats and standards with those of Verifiable Claim, JSON-LD signatures, etc, specifically:

This is a small, but feasible set of topics for Spring 2017 RWoT. Subsequently, we will pursue the following topics (which currently require elaboration).

Topic 1: Aligning signature schema and techniques for blockchain-issued documents

Blockcerts signatures

Blockcerts uses Merkle proofs and JSON-LD signatures for issuing and verification. JSON-LD normalization (canonicalization) is a critical element, used to predictably format a json-formatted input document.

The Blockcerts signature schema is heavily inspired by specifications generated by RWOT and Verifiable Claims groups, including:

Blockcerts currently uses Chainpoint V2 merkle receipt format, with plans to enable other formats, e.g. Peter Todd's Open Timestamps. 

"signature": {
    "type": ["EcdsaKoblitzSignature2016", "LinkedDataEcdsaKoblitzSignature", "Extension"],
    "merkleProof": {
      "type": "ChainpointSHA256v2",
      "merkleRoot": "68f3ede17fdb67ffd4a5164b5687a71f9fbb68da803b803935720f2aa38f7728",
      "targetHash": "c9ead76a54426b4ce4899bb921e48f5b55ea7592e5cee4460c86ebf4698ac3a6",
      "proof": [{
        "right": "7fef060cb17614fdfddd8c558e102fbb96433f5281e96c80f805459773e51163"
      }],
      "anchors": [{
        "sourceId": "8623beadbc7877a9e20fb7f83eda6c1a1fc350171f0714ff6c6c4054018eb54d",
        "type": "BTCOpReturn"
      }]
    },
    "created" = "2017-03-24T21:48:24Z",
    "creator" = "ecdsa-koblitz-pubkey:1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER",
    "signatureValue": "OGQzNGVkMzVm4NTIyZTkZDY...NmExMgoYzI43Q3ODIyOWM32NjI="
  }
}

Problems with JSON-LD signatures for blockchain-issued documents

Some aspects of JSON-LD signatures are not an ideal fit for blockchain verification, which has resulted in some duplication and ambiguity in our schema. Per VC discussions and this thread, there is interest in aligning JSON-LD signatures with JOSE/JWS, but we also have some concerns with this. (Note that, per Manu's email, details are emerging soon, and my concerns may be out of date).

Clarification and generalization of the JSON-LD signature standard (and/or its evolution with JOSE/JWS) would help express blockchain signatures. Some concerns include:

Other questions - Any interest in revisiting Proof of Publication? - Standardization of a JSON-LD signature approach to dropped fields during JSON-LD normalization - Blockcerts addresses this through use of the '@vocab' keyword to detect fields not present in any JSON-LD context - Ideally verifiers could adopt a standard convention to flag such attempts to alter a claim

Topic 2: Recipient Strong Claim of Ownership

In the absence of an existing recipient DID, are there best practices for future proofing a credential via an embedded recipient public key, enabling subsequent mapping of the public key to a DID?

Because we cannot yet assume existence of DID for recipients, Blockcerts embeds the recipient's cryptographic key in the document issued on the blockchain. This allows the recipient to make a strong claim of ownership (by signing a message). For that reason, we plan to include (as an OBI extension) a public key that the recipient owns in the document. The current Blockcerts schema has added publicKey field to a recipient object, and reserved id on this object for future expression as a DID.

Are there any better approaches?

Note that in the Blockcerts model, the credential recipient provides their own public key (in advance of issuing) to the issuer. As mentioned above, the notion of identity is external to the Blockcerts project. It is assumed (and enforced in various ways in implementations) that the issuer and recipient have a separate means of establishing identity and transferring keys.

Reference

This is a technical summary of the Blockcerts approach, for reference:

Blockcerts Issuing

The resulting Blockcert contains the original document and the signature/merkle proof. JSON-LD normalization, along with merkle proof allows predictable verification of the issued document

Note that the last JSON-LD signature step is unnecessary. Because each document is sha256 hashed and placed into a merkle tree, issued on the blockchain, and the issuer signing key is the one performing the blockchain transaction, the separate signatureValue is actually unnecessary.

Blockcerts Verification

Inputs:

Steps: