| daniel added a comment. |
In T138708#2426913, @JanZerebecki wrote:Why omit the revision ID of the predicate/property?
In T138708#2426549, @daniel wrote:In T138708#2424766, @JanZerebecki wrote:Why use a sha1 instead of inlining the normalized serialization in the text to sign?
Because that doubles the size of the serialization of a statement.
Would that part need to be stored?
I would suggest to store it. It's also possible to reconstruct it.
If the sha1 is used how do you reconstruct what it was composed of?
By normalizing the serialization of the statement of the revision in which the signature was added.
Why add the current date and time?
For completeness. It's nice to know when something was signed, I think.
Why is the one in the GPG signature not sufficient
It is sufficient I think.
Why add the signer's identity?
It should be visible *somewhere*, right?
Why is the one in the GPG signature not sufficient?
It might be sufficient, but it's typically an email address. We may want something more meaningful - maybe even an ItemId.
How do you revoke a signature?
By removing the snak that contains the signature.
Then how do you counter replaying the signature?
The revision ID in the signed text would mismatch the revision in which the signature was added.
However, maybe we don't want to counter this. If someone vandalizes the item by removing the statement, or even just the signature, we want to be able to restore it, I suppose.
Or by revoking the key.
What to do about all the other signatures that the signer wants to convey they think are still true?
I didn't think about revoking individual signatures when I wrote this proposal... Maybe it would be possible to include a token in the signed text, and the signer could maintain a (signed) list if valued resp of revoked tokens in a well known location? Maybe the token is a URL that resolves to a (signed) "valid" or "invalid" response? How do other systems solve this?
How do you guard against being able to send the user only a selective part of the signatures?
Can you elaborate?
If you carefully select only some true statements will a conclusion based on them change in your intended way?
It's theoretically possible to construct a misleading data set from cherry-picked signed statements. I don't think this method could be used to make it appear that a signer asserted something they did not intend to assert. Do you have an idea how such a situation could be constructed?
How do you verify what a revision contains and that the revision wasn't changed?
By signing parts of that revision. I don't currently have a solution for labels and descriptions, except copying them into the signed text.
Why only parts? How would that be done, by inlining or hashing and chaining or something else?
Right, we should probably include the hash of the entire revision in the signed text. That's probably the easiest way, we even have that pre-computed in the database.
Cc: jayvdb, Scott_WUaS, tfmorris, Spinster, TomT0m, Denny, Eloquence, JanZerebecki, 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
