Registers got announced at Sprint 16. I’ve been part of the team working on them.
So what are they?
Authoritative lists. Each list has a reason to exist (ideally because a law was made which requires such a list to be maintained – this make it nice and clear why such a list exists).
But we already have them!
We do. But they aren’t in any standard format. They can be published in PDFs and website pages which doesn’t help people build services which consume the data. They also go stale. If we define a Register as holding the minimum amount of data and provide a mechanism to point at some data in another register, hopefully the data won’t go stale – for instance, the food hygiene ratings register doesn’t need to store an address, just the rating and a pointer to the address in an address register.
What’s the value-add?
We want to ensure the following 3 things:-
- Is the register valid?
- Does this data exist in the authoritative register?
- Is the data in the register from an authoritative source?
To enable this, we’re writing a specification to allow you take the source data and generate a Merkle Tree across all the data. If the root hash that you’ve calculated matches ours, then you’ve independently verified that the register is valid. You can check if the entry you’re checking is in the Merkle Tree to ensure the data item is in the authoritative register. And if we sign the key with a private key, then you can be confident that the data is from us (if we ignore the key distribution problems for now).
Sounds interesting – is anybody using it?
The end-game is to allow departments to create registers which conform with the API specification, and not for us to create all the registers for all the government departments. We’re creating small registers such as the Country Register to aid in user testing and demonstrating the potential.
Show me your technical stack!