TF-Graphs-UC/Digital Signatures

This is a detailed example illustrating a use case from TF-Graphs-UC.

This is the example in TRiG format:

_:bnode1
   rdf:type foaf:Person ;
   foaf:name "Manu Sporny" ;
   foaf:homepage <http://manu.sporny.org/> .

This is the example in JSON-LD format:

{
   "a": "<foaf:Person>",
   "foaf:name": "Manu Sporny",
   "foaf:homepage": "<http://manu.sporny.org/>"
}

One could sign the graph above by adding a few triples to the graph...

The example in TRiG format:

_:bnode1
   rdf:type foaf:Person ;
   foaf:name "Manu Sporny" ;
   foaf:homepage <http://manu.sporny.org/> ;
   sig:signature [
      rdf:type sig:JsonldSignature ;
      sig:signer <http://manu.sporny.org/webid#key-5> ;
      sig:signatureValue "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk=" . ] .

The example in JSON-LD format:

{
    "a": "<foaf:Person>",
    "foaf:name": "Manu Sporny",
    "foaf:homepage": "<http://manu.sporny.org/>",
    "sig:signature: 
    {
        "a": "<sig:JsonldSignature>",
        "sig:signer": "<http://manu.sporny.org/webid#key-5>",
        "sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
    }
}

However, nobody else could sign that graph without introducing ambiguity as to who signed the graph first. That is, the second signer couldn't sign the initial signer's signature. Therefore, having the concept of a graph snapshot which can be annotated in the same way that triples are annotated becomes very useful. The first signature could be performed like so:

The example in TRiG format:

G1 {
_:bnode1
   rdf:type foaf:Person ;
   foaf:name "Manu Sporny" ;
   foaf:homepage <http://manu.sporny.org/> .
}
G1 sig:signature [
   rdf:type sig:JsonldSignature ;
   sig:signer <http://manu.sporny.org/webid#key-5> ;
   sig:signatureValue "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk=" . ] .

The example in JSON-LD format:

{
   "@": 
   {
      "a": "<foaf:Person>",
      "foaf:name": "Manu Sporny",
      "foaf:homepage": "<http://manu.sporny.org/>"
   },
   "sig:signature: 
   {
      "a": "<sig:JsonldSignature>",
      "sig:signer": "<http://manu.sporny.org/webid#key-5>",
      "sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
   }
}

The example above separates the signature from the data that is being signed, which is good design. The second signature could be performed like so:

The example in TRiG format:

G2 {
   G1 {
   _:bnode1
      rdf:type foaf:Person ;
      foaf:name "Manu Sporny" ;
      foaf:homepage <http://manu.sporny.org/> .
   }
   G1 sig:signature [
      rdf:type sig:JsonldSignature ;
      sig:signer <http://manu.sporny.org/webid#key-5> ;
      sig:signatureValue "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk=" . ] .
}
G2 sig:signature [
   rdf:type sig:JsonldSignature ;
   sig:signer <http://authority.payswarm.com/webid#key-873> ;
   sig:signatureValue "kMzVmMVDIyOWM32MzI4ZDY3NjI4mQ3OOGQzNGNTIyZTkQzNmExMgoYz=" . ] .

The example in JSON-LD format:

{
   "@": 
   {
      "@": 
      {
         "a": "<foaf:Person>",
         "foaf:name": "Manu Sporny",
         "foaf:homepage": "<http://manu.sporny.org/>"
      },
      "sig:signature: 
      {
         "a": "<sig:JsonldSignature>",
         "sig:signer": "<http://manu.sporny.org/webid#key-5>",
         "sig:signatureValue": "OGQzNGVkMzVmMmQ3ODIyOWM32MzQzNmExMgoYzI4ZDY3NjI4NTIyZTk="
      }
      "dc:date": "2011-02-26T22:18Z"
   },
   "sig:signature: 
   {
      "a": "<sig:JsonldSignature>",
      "sig:signer": "<http://authority.payswarm.com/webid#key-873>",
      "sig:signatureValue": "kMzVmMVDIyOWM32MzI4ZDY3NjI4mQ3OOGQzNGNTIyZTkQzNmExMgoYz="
   }
}

Note that a "dc:date" has been associated with the initial signed graph. Using this technique, one could verify that:

1. The initial graph was signed by a primary author.
2. The initial graph w/ signature was annotated and signed by a secondary author.

This is useful when dealing with web-of-trust issues such as trusting graphs which have been cached by third parties. This happens when product listings are cached by companies like Google and then proxied by 3rd parties. You want to ensure that the initial product listing is valid per the asset owner, and that the state of the cache has been verified by Google. This prevents a nefarious proxy of meddling with the information that will be used to perform a financial transaction.