Digital Trust Protocol Verifiable Claims
DTP Verifiable claim is part of the Digital Trust protocol
A verifiable claim message is a relatively small piece of data with a flat data structure that is self-provable authentic and defines a single value issued to a subject. After a claim message is created, a hash ID is calculated and then signed by the issuer. Usually, the timestamp is added by the DTP server. A claim message needs to contain at least the issuer signature and a timestamp, for other DTP servers to verify that the received claim message is valid.
The self-provable authenticity feature of a claim message enables decentralization without the need for a central authority, as servers can use peer-to-peer communication and still be able to verify all the data they receive, without having to trust the sender.
Claim messages can be of any type, and therefore the DTP protocol specifies a basic set of claim types for standardization purposes.
When issuing and signing claims, the signature can be base on a simple private/public key algorithm principle, or it is also possible to provide a script with multiple signatures for the claim. It is also possible to provide any custom non-standard script/type if needed, but then this has to be supported by any DTP server that serves the claim in its web of trust graph.
The value part of the claim defines a statement towards a subject. The value is what the issuer thinks of a subject. For simplifications, it is not possible to add more than one value per claim. Issuing multiple values to the same subject is done by issuing multiple claim messages. The single value per claim enables the system to update or replace individual claims with new ones as the need occurs. Updating or removing claims happens by issuing new claims messages to the same target with a new value or an empty value to simulate removal. The package that contains the claims, features techniques to enable single signing and templating for mitigating the bloat of having to issue multiple claims of the same type towards the same subject. It’s possible to extract individual claims out of the package and add them into new updated packages and still keep the proof of authenticity with each claim. This way old replaced claims can be discarded and existing and new claims a combined into new packages before sharing.
It is possible to add a signature to the subject part of the claim message, proving that the issuer is also in control of the subject. This enables the DTP servers to change the behavior of the search algorithms used for finding trusts and enable features like tunneling for key management. The claim message can have an activation and expiration date, enabling them only to be active at certain times. A use case would be that the trust is used as a ticket system or to provide secure access to systems for a limited time. Claim messages contain a scope property for limiting the context of the claim, as the claim given to specific web platforms may not be relevant on other platforms. This is very beneficial to limit the amount of trust hosted on a DTP server. A claim message is hosted in a package when submitted or transported around.
Example of a claim package
{
"algorithm": "double256.merkle.dtp1",
"id": "xSJLFeSNTYn4AHjvbz4rCh7AFz1ZJyFwZW1M8GJy3g4=",
"created": 1548757308,
"claims": [
{
"id": "Lp2+ebZ9U0LRv/Z/xnx8pPVhbkRdoyscsdcY+n+StaI=",
"created": 1548757166,
"issuer": {
"type": "secp256k1-pkh",
"id": "1LRNDp2HfVKc1FsCJwbJwMhtssXL8fdTx2",
"signature": "H0+9PhNSxm6ySMShlkuC1ZCTuYdbxSHquP1KCmb/M4LxZwOSFoHUy+fHcZiiI/zjheVJvrQbM/1X4Eg6+wTx3N0="
},
"subject": {
"type": "name",
"id": "TrustProtocol"
},
"type": "binary.trust.dtp1",
"value": "true",
"scope": "twitter.com"
},
{
"id": "3atbj7U7RMSfL8OQFaGDzYlpGRbpnm3kHItMzFXLjMk=",
"created": 1548757166,
"issuer": {
"type": "secp256k1-pkh",
"id": "1LRNDp2HfVKc1FsCJwbJwMhtssXL8fdTx2",
"signature": "ICWN+jH6Gn8+c7FJ0rSk3SPRmRI97FiXVtEdnm2S0utJOpZaE+WqNDII1RhHwLDlgVxlyNFpkp7w3K+WCBJXhPg="
},
"subject": {
"type": "id",
"id": "1NKtqyDndSvQ87ANAHsWR5XGL66pXkZxc8"
},
"type": "binary.trust.dtp1",
"value": "true",
"scope": ""
},
{
"id": "QlbmdW4R1Ctth4Ah4xIVNzcflhlyr4oFaZFtIASi9HA=",
"created": 1548757169,
"issuer": {
"type": "secp256k1-pkh",
"id": "1LRNDp2HfVKc1FsCJwbJwMhtssXL8fdTx2",
"signature": "IPe6xOj4ofy1QWSB646AHvKPa7a7mk3ko6D/dKdk15jkVZ4wLt5ci1eCJrj2j4uWSM+JYFlVy+Z1Sa8LHMDNK8U="
},
"subject": {
"type": "id",
"id": "1NKtqyDndSvQ87ANAHsWR5XGL66pXkZxc8"
},
"type": "alias.identity.dtp1",
"value": "Digital Trust Protocol",
"scope": "twitter.com"
}
],
"timestamps": [
{
"blockchain": "btctest",
"algorithm": "secp256k1-double256.merkle.dtp1",
"source": "xSJLFeSNTYn4AHjvbz4rCh7AFz1ZJyFwZW1M8GJy3g4=",
"registered": 1548757308
}
],
"server": {
"type": "secp256k1-pkh",
"id": "1LCGKp8zkmU3jBSdsRNfLzqsJH3qSzSxyk",
"signature": "IBtutLOpiB5rcpgvSxdNbvB5OpVM5yp8t1dO3FVWvgPWdX+EvM3eQrfyBNeOQYil7K/xuzsgXYNYE7XjR/byhBo="
}
}In the example above, three claims have been created and added to a package. The claims trust a subject named “TrustProtocol” and a subject with an ID “1NKtqyDndSvQ87ANAHsWR5XGL66pXkZxc8” and its alias of “Digital Trust Protocol.” These three claims are trusting the same entity on Twitter, where the entity has the public key “1NKtqyDndSvQ87ANAHsWR5XGL66pXkZxc8”, but also the twitter name “TrustProtocol” is trusted. Finally, an alias claim issued to the public key, connecting the key with an alias. Note that the scope property is empty for the claim that trusts the ID; this is because the trust is global and not limited to a scope. The server property in the package is created and signed by the DTP server receiving the claims from the client. This way, other DTP servers can identify the source of the package. Lastly, the DTP server timestamps the claims by use of a publicly available blockchain to ensure that claims can prove their time of existence.
Package
When DTP server shares claim messages with other DTP servers, they use a package to contain the claim messages; this enables them to create an array of claim they have received from users and timestamp them all at once by using a Merkle tree algorithm. DTP servers also sign the package with their own identity, enabling other DTP servers to be able to verify the origin of the package. By having DTP packaging and signing claims, it helps to confirm the existence of the claims, further enhancing the proof of the existence of the claims, because the claim message has now been seen by at least one DTP server and shared in a package signed by the server. The package includes a template property to reduce the storage needed by providing shared templates for claims to use. Even key signing is supported within the template. It is possible to add multiple claims to a single package and sign the package once. The signature is based on the id calculated from a Merkle tree of all the id’s from the claims, and the timestamp works in the same way. This enables claims to be separated from their original package and added to other newer packages, but still be able to be self-provable authentic. The Merkle tree id feature enables repackaging of the claims into new packages as individual claims to get replaced, avoiding having to keep old replaced claims data with still active claims.
Conclusion
DTP protocol defines a simple piece of data called a claim message. The claim message data is designed to be self-provable of authenticity by use of private/public key algorithms and the blockchain timestamping feature, and this ensures that nobody else will be able to issue the same claim message without the private key used to sign the message. The timestamp feature ensures that the claim can prove its existence at a specific time, thereby preventing backdating claim messages.
