As we described (e.g., in a paper [Bonatti et al. 2017]), one type of technology that helps people (the providers of personal data) and companies (the users of that data) to keep track of the contracts between them is a system based on public ledgers. The ledgers, in this case, are online databases that store data about transactions. They need to be, among other things, secure, verifiable without disclosing more information than needed, long-lasting, accessible, tamper-proof yet modifiable to correct errors, and interoperable. The software platform that we are building tries to fullfill these requirements.
A working group of W3C, called the ‘Verifiable Claims Working Group’, started in April 2017 to try and develop a standard model and vocabulary for the exchange of proofs. The work started with the need to produce proof of payment for an online purchase, but it became much more general. A proof is a signed statement that somebody possesses some right. It can be many things: A person has a valid drivers license, has paid for a certain service, has a ticket for some train ride, has a contract with some company, etc. The model expresses the general idea that somebody can make a claim (‘I own this data’, ‘I am a citizen of the European Union’, ‘I am over 18 years old’) and can produce a statement signed by a relevant authority that says that the claim is true, without disclosing anything else.
The model does not deal with the actual contents of the claims, only with their common aspects: An ‘entity’ (person, organisation) makes a ‘claim’ about a ‘subject’ (another entity). An ‘issuer’ is an entity that creates a claim, a ‘holder’ an entity that stores a claim. The holder may be a third party, but a subject may also be the holder of claims about itself. A claim becomes verifiable by means of an electronic signature. A ‘revocation’ allows a set of claims to be invalidated.
The model provides a concrete syntax in JSON (based on JSON-LD) with standard fields for each part of the model and room for arbitrary data for each claim. As long as there is a way to encode a claim in digital form, it can be stored inside this model, exchanged, signed and thus verified. A claim doesn't necessarily have to be in JSON-LD, it could be in XML or RDF, e.g., but there has to be a way to translate it to JSON-LD.
This standard syntax should eventually allow for more interoperability between different ledgers and between the programs that access them. Although the stored data (contracts and personal data) can differ, the operations on it are often very similar and the JSON format with standardized names for common fields should allow re-use of software libraries and even re-use of parts of user interfaces.
The working group published its first draft specification in August. It is still incomplete and will probably change in many ways, but it already shows some concrete examples of what the final model will be like. The group hopes to have a specification ready for implementation in February 2018 and, after testing, make it an official standard in December of that year.
The architecture that SPECIAL decided on for its own software platform also uses JSON-LD for the exchange of data between the various parts. The exact form of that JSON data hasn't been decided at this point, but the Verifiable Claims vocabulary is something that has to be looked at.