Signature question type

[janagombitova]

Overview

The ‘signature’ question type enables users to place their electronic signature in a form. An e-signature is any ‘mark’ made by the person to confirm their approval of the document, information, or transaction.

Note: There are two terms commonly used for electronic signatures. An electronic signature is any signature in electronic form, as a scanned image of one’s ink signature, a mouse scribble, a voice signature, etc. A digital signature, which is actually a subset of electronic signatures, goes further in terms of proving who could have made the mark. Akvo FLOW signatures fulfill all requirements for electronic signatures, which are legally binding in almost all countries. Akvo FLOW records the time when the signature was taken, the name of the user, as well as the ID of the device for confirmation.

We cannot fully implement non-repudiation, as we don't have access to digital identities (as digital signatures do). Implementing a digital signature which has stronger legal ground in comparison to electronic signature is more complex and there are existing tools which provide such functionality. We have decided to provide a functionality that is commonly used in survey tools, and fulfils requirements of an electronic signature. The legal limitations of electronic signatures need to be explicitly added to the FLOW documentation.

Links to documents

Links to the functional design documents https://github.com/akvo/akvo-product-design/blob/master/FLOW/Features/117---SIgnature-question-type/Functional%20design%20document.md

[janagombitova]

[muloem]

@ichinaski @jonase @janagombitova @iperdomo @mtwestra

Requirements review notes:

General Notes:

• The signature given is a user provided form of confirmation by the user that either a specific response or statement or the entire set of responses given in the form are accepted or considered true.
• The signature shall be provided via a canvas on which the user is able to sign. For the case of a phone the canvas would likely appear horizontal to use the screen space better. For webforms, the canvas should enable using the mouse pointer to sign from desktop.
• The signature pad will typically appear at the end of a set of responses (or immediately after a question,?) or next to a statement to which the signature is associated.
• To mimic the appearance of paper, the signature pad will appear white and should show a line (however, this does not need to be included in the image of the signature that is finally stored).
• Additionally, the name of the person signing should be filled in below the signature
• Signatures should be shown in preview when browsing data collected on the dashboard

Implement signature feature as a question or an element in a survey?

• In the case we implement as a question some implications:
  • Questions usually have dependencies or are dependent on other questions. how should signature question behave? (initial thinking was we should not allow dependencies but after discussing it, its perhaps an idea to leave that up to the form designer)
  • Signature response would have to be stored just like any of the existing responses. For the current image responses, we store the image name and upload the image to S3. however, given we are talking about signatures, we felt this is risky storing them on S3. Suggestion from @jonase to store the images as base64 encoded strings.
  • We cannot allow data cleaning of signature responses
  • Since exported report still needs to indicate that approval was given, this can include the name of the person who signed
• In case we do not implement as questions but instead as a survey element:
  • We would need to have some new entity for the datastore and all the associated data storage and retrieval implementation.
  • @muloem proposed the possibility to have signature feature as an attribute associated to a form or to a question rather than a question type of its own.
  • @ichinaski pointed out that the current flow is all prepared for question types and we should take advantage of it and having the signature as an attribute means old versions of the app would completely ignore it + we could not take advantage of current question flow. Given the proposed time to implement the feature, taking another approach makes that deadline difficult to meet

Other questions to be followed up:

• Should we include the signature in the report?
• What is done with the signatures after they are gathered?
• Look into more detail regarding the difference between agreeing with a statement or with a question response.
• Should the signature line also be shown in the preview of data collected?

[janagombitova]

@muloem Thanks for sharing the notes. On the questions:

Should we include the signature in the report?

Yes, as we discussed on Friday, in the reports we will show the name of the person who signed. This name field will be a default setting on the signature and must be added in order for the signature to be saved. So the user will scribble in his/her signature and type in his/her name before saving the signature. I suggest we use in the report the format: Signed by:user name

What is done with the signatures after they are gathered?

An email was sent to partners for more clarification, however, I think we can proceed further based on the decisions we have taken for the first implementation.

Should the signature line also be shown in the preview of data collected?

Tools that solemnly provide digital signature support do and do not include the line. It is more a matter of personal preference. We have agreed not to add the line preview.

[iperdomo]

@muloem @jonase

however, given we are talking about signatures, we felt this is risky storing them on S3. Suggestion from @jonase to store the images as base64 encoded strings.

Just for my understanding: What's the difference between store it in an object store (S3) or the GAE datastore? If we transform the image to some other representation, we'll need to decode it every time we want to see it? The image can go to another folder in the object store and not /images/*. Only authenticated requests can read them?

Storing binary objects as fields on a records is a long debate in RDBMS. We need to always think how this features and our technical decisions affect the new system.

[bjelkeman]

Akvo FLOW signatures fulfill all requirements for electronic signatures, which are legally binding in almost all countries. by @janagombitova

Could we have a reference for this statement? I have been trying to find information that gives an indication of what the requirements would be for electronic signatures.

I would be uncomfortable storing digital signatures which aren't encrypted, for example.

I think the term electronic signatures is miss-leading in this context, as this is often confused with digital signatures. A digital signature would for example be a document signed with PGP. I think a better terminology is to use a digital seal, which is also used in legislation [1].

[1] http://www.europarl.europa.eu/sides/getDoc.do?type=TA&language=EN&reference=P7-TA-2014-0282#BKMD-10

[janagombitova]

@bjelkeman - I based the research on: (1) tools that provide e-signatures. These two provide nice explanations on the difference between electronic and digital signatures and their legal limitations: http://www.arx.com/learn/about-digital-signature/digital-signature-faq/ and https://www.signinghub.com/electronic-signatures/ (2) And on these EU legislations - http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:en:HTML and its revised version http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG.

Requirements are specified more for advanced/qualified electronic signatures and digital signatures. The electronic signature is defined very vaguely at least from what I could find and is used as a more global term for multiple types of signatures signed electronically.

I agree that the vocabulary related to these signatures is very confusing and misleading. However, I find the term digital seal very user unfriendly. To be honest, if I were to add a signature to a form I was creating, 'digital seal' would not imply signature for me right away. Secondly, based on the regulations for electronic seals and electronic signatures (not advanced or qualified), the articles defining both in the regulation I read are identical.

I think we need to be very clear in the documentation on the difference between these types of signatures, the limitations of the signature type we provide in FLOW and state that they do not have the legal strength of digital signatures, advances electronic signatures and qualified electronic signatures. Moreover, each national law may have different regulations governing the use of electronic signatures

@muloem @jonase @iperdomo How can we ensure that the signatures stored safely also taking into consideration Thomas's comment on encryption?

[iperdomo]

@janagombitova based on the articles you linked, i'm not sure how as can claim that our proposed implementation has some legal binding. And i guess is not true the statement that accepted in almost all countries (specially on those where our partners operate).

Regarding @bjelkeman's comments, I think he has referring to actual digital signatures.

If we want to do it properly, the electronic signature needs to be bound, and be part of, a checksum together with the set of answers. If something changes, in the answers (e.g. data cleaning) that invalidates the signature.

[janagombitova]

Dear all,

I have made changes to the issue description based on your comments. Thanks for pointing that out.

What we understood from the research was that digital signatures require a secure signature-creation device, encryptions, public keys, qualified certificates and more deeper measures to ensure the signature complies with all existing rules. More complex and secure signatures are also known as advanced electronic signatures, qualified electronic signatures with different requirements. Electronic signatures are defined in a very simple way as data in an electronic form attached to other data with the purpose to serve as a form of authentication.

We have decided to implement the electronic signature (as shown in the box Ivan shared). FLOW is not a secure signature-creation device. The EU legislation talks about 'secure signature-creation devices' in connection with 'advanced' and 'qualified' signatures. From our understanding an 'electronic signature' does not need to be created by a 'secure signature-creation' device to have legal effectiveness (Article 5, point 2 - http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:en:HTML). This is yes, a less proper implementation (in terms of encryption and advanced security). There are multiple tools that provide 'digital signatures' and I think we do not intend to dive into that field.

Many survey tools also provide signature question fields and they also use the approach of 'electronic signatures'. However, we will provide additional confirmation about the signer of the form/question the signature refers to: date and time of form submission, device ID, name of signatory. It will not be possible to data clean or edit the signature.

I agree that data cleaning will invalidate the signature, and we need to eventually add an audit log to changes done on FLOW. This is a more broader issue tapping into other general workflows as well.

What we need to do is add a disclaimer to the documentation explaining the different type of signatures with references, which signature type we provide, that we are not a secure signature-creation device, that we store meta data (the name of the signatory, the date and time, device ID) to provide additional confirmation about the signature, and that we strongly advise our users to consult with a lawyer on the legal conditions and requirements for using such signatures as they depend on national legislations.

[muloem]

What's the difference between store it in an object store (S3) or the GAE datastore? If we transform the image to some other representation, we'll need to decode it every time we want to see it? The image can go to another folder in the object store and not /images/*. Only authenticated requests can read them?

While discussing the issue, storing on S3 left us all uncomfortable because images are currently stored under a publicly accessible prefix. Its true that we could store the signatures using a different prefix path (we didn't consider this alternative) but while discussing we thought signatures will be relatively small in pixel dimensions and only black and white and so would not take up too much space even as an encoded string. Either way the main concern was that they are not publicly accessible. and give the last few comments in the thread we should probably add that they should be encrypted somehow.

@iperdomo

[janagombitova]

@ichinaski here is the revised mock up for app provided by @loicsans

[ichinaski]

Cool, that goes in-line with what I had in mind. I would also suggest that the question response is incomplete/invalid unless both fields are filled in. Otherwise the regular warning icon is shown, and the form cannot be submitted.

[janagombitova]

Another note:

The signature question cannot be used as data point name, thus we will not even provide this option in the dashboard when adding this question type to a form.

[janagombitova]

We have agreed to add a checksum to the signature response which will help us show whether the form that holds a signature answer has beed changed or not. Due to the timeframe of the December release, we have came to the conclusion to add this checksum in the following implementation in January.

[janagombitova]

Finished in the 1.9.4 release