| daniel edited the task description. (Show Details) |
EDIT DETAILS
* Make a hash of* Create a normalized serialization of the Statement's main snak and qualifiers (excluding rank and references, with normalized field order, escaping, whitespace, etc)
* Make a sha1 hash of this serialization (the claim hash)
* Compose a human readable text (yaml?) of the following:
** the claim hash
** the subject's revision ID (plus possibly the language codes of labels and descriptions that were used to establish the subject's identity)
** the objects revision ID (if the main snak points to an item). (we may also need this for the objects of qualifiers)
** the signer's identity (as given in the signer's certificate)
** the main snak and qualifierscurrent date and revision IDtime
* sign this hashtext with GPG
* add the hashsigned text as (part of) a reference to the original statement
Things to keep in mind:
** The hash of statements linking to items should include the revision ID of the linked item to allow checking against changing the identity of the linked item.
* adding or changing references does not break the signature
* adding or changing qualifiers does break the signature
* changing the label and description of the subject (or the object) does not break the signature, but is detectable (by comparing against the revision ID included in the signed text). If the label or description was changed, a warning should be triggered, since changing the identity of the subject changes the meaning of the statement.
Story to sign:
* enable "sign statement" gadget
* click "sign this" icon next to a statement
* see a popup with the follwing text fields:
** the serialized claim
** the text to sign
** perhaps also the labels and descriptions of the subject and any objects, in the user's languages (as in the term box)
* optionally, visually verify the serialized claim, and verify that it matches the sha1 hash provided for signing.
* use copy & paste to sign the text with GPG.
* copy the signed text back into the field that originally contained the text to sign.
* click a button to save the signature
Story to verify:
* click the "signature" icon next to a statement
* see a popup with the same text fields as for signing, but with the signed text in a read-only field.
* use the same steps as for signing to manually verify.
We can of course also verify on the server side, or with JS in the browser. But that can easily be faked. The hash of statements linking to items should include the revision ID ofonly way for the linked itemuser to allow checking against changing the identity of the linked itembe sure is to verify manually.
...
One possible way to do this:* Make a hash of* Create a normalized serialization of the Statement's main snak and qualifiers (excluding rank and references, with normalized field order, escaping, whitespace, etc)
* Make a sha1 hash of this serialization (the claim hash)
* Compose a human readable text (yaml?) of the following:
** the claim hash
** the subject's revision ID (plus possibly the language codes of labels and descriptions that were used to establish the subject's identity)
** the objects revision ID (if the main snak points to an item). (we may also need this for the objects of qualifiers)
** the signer's identity (as given in the signer's certificate)
** the main snak and qualifierscurrent date and revision IDtime
* sign this hashtext with GPG
* add the hashsigned text as (part of) a reference to the original statement
Things to keep in mind:
** The hash of statements linking to items should include the revision ID of the linked item to allow checking against changing the identity of the linked item.
* adding or changing references does not break the signature
* adding or changing qualifiers does break the signature
* changing the label and description of the subject (or the object) does not break the signature, but is detectable (by comparing against the revision ID included in the signed text). If the label or description was changed, a warning should be triggered, since changing the identity of the subject changes the meaning of the statement.
Story to sign:
* enable "sign statement" gadget
* click "sign this" icon next to a statement
* see a popup with the follwing text fields:
** the serialized claim
** the text to sign
** perhaps also the labels and descriptions of the subject and any objects, in the user's languages (as in the term box)
* optionally, visually verify the serialized claim, and verify that it matches the sha1 hash provided for signing.
* use copy & paste to sign the text with GPG.
* copy the signed text back into the field that originally contained the text to sign.
* click a button to save the signature
Story to verify:
* click the "signature" icon next to a statement
* see a popup with the same text fields as for signing, but with the signed text in a read-only field.
* use the same steps as for signing to manually verify.
We can of course also verify on the server side, or with JS in the browser. But that can easily be faked. The hash of statements linking to items should include the revision ID ofonly way for the linked itemuser to allow checking against changing the identity of the linked itembe sure is to verify manually.
TASK DETAIL
EMAIL PREFERENCES
To: daniel
Cc: T.seppelt, Aklapper, daniel, Zppix, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, TheDJ, Mbch331
Cc: T.seppelt, Aklapper, daniel, Zppix, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, TheDJ, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
