-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Digital signing of each resource to create a web of trust without centralisation. #307
Comments
This is very interesting. We have been looking at something like the proposed JWS/CT (JSON Web Signature/Clear Text) specification which combines JWS with canonical formatting of JSON (producing JSON in a standardised format that allows comparison). |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I think we should look at this now as it can be a minor release addition with no breaking changes. I have a proposal for this based on things you mention above from JWS/CT and either canonical formatting or scoping the contents of what is signed. |
The proposal is to utilise JSON Web Signature (https://www.rfc-editor.org/rfc/rfc7515) and RFC 8785 JSON Canonicalization Scheme (https://tools.ietf.org/html/rfc8785) to digitally sign the content of a message. This will allow the recipient to verify the integrity of the message. Add a new property, called 'signing', to the meta object. The property is OPTIONAL. We extend icarMetaDataType (https://github.com/adewg/ICAR/blob/ADE-1/types/icarMetaDataType.json) with the following:
And then defined digitalSignature as the following:[
We utilise the JWS Compact Serialization format (https://tools.ietf.org/html/rfc7515#section-3.1) to represent the signature. The JWS Compact Serialization format is a string consisting of three dot ('.') separated base64url encoded strings in the form Header.Payload.Signature. The only semantics differ slightly in that the JSON object to be signed is constructed by taking the values of the JSON keys specified in the propertyList and creating a new JSON object with those keys and values. This object is then serialized to a string using the JSON canonicalization algorithm (https://tools.ietf.org/html/rfc8785#section-3.1) and then signed. Implementation note: There are many libraries for doing the JSON Canonicalization For exmaple: go https://github.com/cyberphone/json-canonicalization |
This is a proposal / idea for ensuring data quality and true declaration of source of origin. So, this idea is inspired by some thinking going on in distributed social media tech platform space. Notably by facebook and their bluesky project, but also some conceptual work done at MIMIRO.
The basic idea is that each system that creates data resources, or publishes them to others, has a private public key pair (potentially many in order to allow for rotation over time). For each entity a system publishes, it creates a hash of the JSON content, then signs that hash with its private key. Both the hash and a link back to the publishing services' public keys is then included in the resource representation (in the meta data section).
Any service receiving an entity can look at the metadata and the claimed originator and if in doubt about the origin it can retrieve the public key and validate that hash has been signed by the owners private key and that the hash is correct for the payload.
This would create a web of trust without a single block chain or other single source of truth. Technically it is not hard to implement.
The text was updated successfully, but these errors were encountered: