Open nt-gt opened 3 years ago
Adding some context:
Our current POC-to-be of the electronic transfer of title at DCSA consists of modelling an endorsement chain as follows:
We assume we have document (a BL) either as a binary blob or a structured document (json). Each time the title is transferred, simply append a signed "endorsement chain link" to it. In practice we would thus build up a collection of files, with the first file being the BL and the subsequent files being endorsing signatures of all the previous files concatenated. This is in essence a replication of the current paper-based process as-is.
Just to confirm, is it the same underlying document in the chain? As in, do we view it as a O || S1 || S2 || ... || Sn
(where O is the original document, and the S1
etc. are signatures and ||
being a binary concat operation)?
If so, I think we need to answer the following questions:
O
) and the signatures start (S1 || S2 || ... || Sn
), so I can read the original document (e.g. PDF readers and Json parsers will reject files with the trailing signatures).S1 || S2 || ... || Sn
, how do I split it into a list of [S1, S2, ..., Sn]
such that I can validate each part of the chain? (Alternative variant can be how do I reliably pop a signature from that string as you always want to read it right-to-left if you validate signatures)The first item is required to read the actual document, so they know what the document says. The second is required to validate the chain of endorsement.
Assume that
T
owns the transport documentDoc
and wants to sell it on toE
. In the physical world,T
andE
both signs the back side of theDoc
and thenE
takes the document with them.The question is how this to be reflected in the digital world?
T
modifyDoc
to state thatE
is the new owner and then sign that?T
sign some form of statement "I knownDoc
and have agreed to passe it on to E on date X"?Either way, how do we reliably restructure the Endorsement chain so we can tell that
E
is the true owner of the contents (and thatT
did not sellDoc
twice)? I think we are missing some concrete format that is covered by a signature but still machine readable to ensure it can be validated easily.Proposal:
I think we should look at this from two angles that should be supported side by side.
Both variants need to be signed.
The structured Endorsement chain link format need to assert:
endorsement_datetime
)If the endorsee also needs to sign the link, then we need to study this in more detail. Also, there is an open question if / how notary services play into this.
Currently, we only have one public key per party and no "link" from the signature to the public key that signed it.
If you do not replace the public key on the party object and instead create a new party object with a distinct UUID, then references by Party ID will keep using the old key even after it has been rotated (i.e. you have to tell every one to stop using the old Party ID as the party will not be using the public key related to that party).
Public keys will be based on X.509 certificates. The standard is well known and ensures we know which signature algorithm is used for signing (as X.509 includes a signing algorithm).
Note this assumption cannot be invalid if "technology agnostic" also covers the public key/signature algorithm. However, in that case, the spec is inadequate for use in practice (as it does not cover key expiry, key rotation, key revocation, signature algorithms). Anyone implementing that spec would either de facto be forced to use something like X.509 or "invent their own crypto" (which is the top item on the list of "Do not ever do this if you want this to be secure")