You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently dDID verification is done in the verify() method, which takes a DID (string) and a timestamp. To succeed, the timestamp must match that found in the header of the Bitcoin block containing the transaction that embedded the root ION DID.
Now we want to replace the passing of an arbitrary timestamp with a configured root event date, plus a short confirmation code, which together uniquely determine the root DID (and hence its Unix timestamp).
This API will change, because the recognised root DIDs will be known in advance, as they are uniquely determined by the configuration parameters entered by the user. Therefore the root timestamps are also known in advance and should not be passed as an argument to the verify method.
But we want to design the new API in such a way as to support:
a vector of root configurations (i.e. support multiple recognised roots)
transparency on mobile (visibility of the verification bundle for the root DID, for direct PoW validation via the SPV node; this is in contrast to a single FFI call - that instantiates a Verifier instance and then calls the above verify method - which performs the verification locally but without transparency for the user)
efficiency on mobile (avoid fetching the root bundle on every dDID verification)
offline verification on mobile (provided we also have caching of intermediate dDIDs, having the root DID's verification bundle stored on device would enable entire chains to be verified offline; we would have to be careful about revocation status in this case, but that will always be an issue when attempting offline operation).
Currently dDID verification is done in the
verify()
method, which takes a DID (string) and a timestamp. To succeed, the timestamp must match that found in the header of the Bitcoin block containing the transaction that embedded the root ION DID.Now we want to replace the passing of an arbitrary timestamp with a configured root event date, plus a short confirmation code, which together uniquely determine the root DID (and hence its Unix timestamp).
A similar change has already been implemented on
trustchain-mobile
: alan-turing-institute/trustchain-mobile#26.The text was updated successfully, but these errors were encountered: