LEGAL

Introduction

Scrive is a service for signing and storing contracts electronically. We help our customers lower their costs, increase their profits and reduce frustration. The following mateials shall only be seen as a description of Scrive as a company and service. The material is under no circumstances intended as legal advice.

Legal objective

Scrive's legal objective is to provide the best possible framework to maximize legal security, minimize risk exposure, and minimize the number of unpleasant surprises for our users.

When a conflict occurs as to whether a document has been signed or not, it is important to show independent proof that the document has been signed by the involved parties. This is often tricky, since a proof vacuum is created when a contract is signed, and the only proof is the signed document itself. In the worst case, the only proof is an e-mail or SMS conversation to work from. If one party claims that it does not have access to any proof material(s), problems will occur for the other party when showing that the proof material put forward is genuine, and has not been created retrospectively. This situation could easily lead to a broken business relationship, and in worst cases to a trial in court. When such a conflict is brought to court, the burden of proof usually falls on the party claiming that the contract has been signed by other parties. When that party fulfills its burden of proof, it is the other party's burden to prove the opposite, and so the trial will continue until the court finally judge upon the presented evidence Whether the document is valid or not.

Scrive's aim is to be a useful tool for both parties in all steps of the process. By witnessing the transaction, collecting proof material and storing it, Scrive serves as an independent third party that easily shows all important actions commited by the involved parties, and thereby functions as a tool for preventing conflicts from evolving. In this way, Scrive helps to minimise the friction between parties at an early stage of the conflict. In rare cases where conflicts are tried in court, Scrive aims to provide the party claiming that a document was signed the best proof material possible to strenghten the party's position in court.

Independent position

To maintain the credibility of its service, Scrive is always Independent. Scrive never takes, and will not take the position of one side signing the contract regardless of who is the paying customer. Our purpose is to generate the best proof material possible to strengthen the fact that a document has been signed by the parties. We do everything we can to protect the integrity and quality of the proof material generated by Scrive, and making it as useful as possible for the customers.

User philosophy

Documents are signed in many different ways and different situations. Therefore, our customer's needs are very different from one customer to another, especially in the spectra usability-security. We do not believe in limiting the user's possibilities, but that the user wants a comprehensive solution that works in most situations where document signing is needed. Because of this, we choose not to commit to a single method for signing and storage, but to provide a carefully selected set of tools to fill the whole spectra usability-security.

We admit that this flexibility of choice may increase the risk for the user as the user is able to select a signing tool that for the situation is not optimal from a risk point of view. We believe, however, that the simplicity of the service generally reduces the individual risk for the following reasons:

1. As we generally make it easier to sign documents and thus reduce the number of insecure agreements (e.g verbal agreements).
2. As we generate and secure high-quality proof material in advance, instead of the most common case today: That historical evidence is found retrospectively, when the conflict already has emerged and large parts of the evidence material may have been destroyed or become useless.
3. As we do our best to inform the user in every step of the process to promote well-informed decision-making.

Key legal considerations

Swedish law prevails in free assessment of evidence. This means that litigants may present any evidence to support his claim, and that the presented evidence that supports different positions are considered against each other This applies in trials concerning signed documents. In cases where Scrive is used, this means that not only evidence generated through Scrive could be used as proof, but also evidence produced by the parties outside of the service e.g. phone conversations, text-message conversations and e-mail conversations. Scrive can obviously only increase its legal mission within the context of the service, and will never, explicitly nor implicitly, take any responsibility for the user's actions outside of the context of the service. The following factors are the most important ones within Scrive's area of control affecting the strength of the evidence generated when using Scrive:

1. Verification of identity
2. Document signing process
3. Data generation
4. Data storage

Verification of identity

Swedish law rarely regulates the form of signatures used. The main rule is that an agreement is legally binding, regardless of how it was confirmed (e.g. through a hand-shake, a statement, a written signature, or an e-mail). The big difference between different kinds of agreements is not in the legal part, but rather the possibility to prove if an agreement exists at all, the content of it and who is involved in it. The reason for this is that different kinds of agreements generates different quality and quantity of evidence. Today, Scrive only offers e-mail and e-ID as methods of identifying parties when signing. Scrive plans to expand the number of methods provided to make the service even more user-friendly. Below, a description of the two methods provided today are presented.

E-mail

Application area:

In transactions with low risk, where companies have their own registered domains and domain-specific e-mail addresses (e.g. PersonName@CompanyDomain.com), e-mail is a suitable solution for signing, considering the simplicity of e-mails and its strong incorporation with other business processes, and because everyone uses e-mail on a daily bases.

Method of verification:

There are three main parts of the verification. One active part, one passive part and the IP-address. In the first step, we send an e-mail containing a unique link that the user has to click to sign a document via e-mail verification through Scrive. In the second step, when the document has been signed by all parties, a confirmation is sent to all parties by e-mail. Omission to react if a user for some reason incorrectly receives a confirmation can be used as evidence arguing for that the confirmation was, in fact, correct. We also collect the IP-addresses that the parties uses when they sign. IP-addresses are generated dynamically, and indicate, among other things, where the user is located. This can be used to strengthen if a person has been at the sight of the signing when the document was signed or not.

Legal reflection:

E-mail identification should be seen as a strong method of verification when it is applied on domain specific e-mail addresses such as PersonName@CompanyDomain.com. There are two reasons for this:

1. It is impossible to be an anonymous domain owner. Thus, the domain oner is always known.
2. The domain specific addresses are not accessible by anyone, but access are distributed and certified through relationships within the organisation. This makes the identification of the user very strong.

Therefore, the connection between identity and domain specific e-mail address is relatively strong. The strength in domain specific e-mail addresses are not to be confused with e-mail addresses hosted by open e-mail providers, such as Gmail or Hotmail, where anyone can create an account with any name and identity. Since the identification of the user is nonexistent when creating such an account, other evidence is required to connect a signed document to a person, such as an e-mail conversation a phone conversation or something else. Today, Scrive does not have any methods for collecting such information, thus, this lies outside of Scrive's domain of control. Therefore we recommend our user not to use e-mail accounts provided by open distributors when signing a document. The vast majority of private e-mail users use this kind of open e-mail providers, therefore we discourage Companies and private persons from using the e-mail verification in the service if not all parties have accesses to domain specific e-mail addresses such as work e-mail, school e-mail or alike.

E-ID

Application area:

This method is suitable for all kinds of documents that require extra high security, and for signing between parties who do not have domain specific e-mail addresses (e.g. private persons). An example may be comapnies who sign documents with private persons, companies who sign extra important documents, or documents with specific requirements on formalities.

Verification by e-ID is done additionally to the e-mail identification. The e-ID verification is compleated in three steps.

1. The first step of identification is when the user obtains his e-ID by logging in at his online bank. To be able to log in at the bank, you first have to get an account in the bank and identify yourself using your ID or legal guardian.
2. Where the person installs his e-ID on the computer, he is asked to select a strong password for identification when using the e-ID. When a party are about to sign a document with the e-ID, the e-ID client is opened on the computer, and the party identifies himself by writing the strong password selected previously. To confirm the party's identity, the e-ID client Communicates with the e-ID provider's server that confirms the party's ID.
3. In the last step, Scrive compares the party's e-ID with the personal info given by the creator of the document. If everything matches, the signature is accepted by Scrive.

Legal reflection:

Swedish law equates qualified signatures with ordinary hand-written signatures (though there are some few exceptions, e.g. testament, property purchase and marriage). E-ID is based on PKI technology, and therefore belongs to the category qualified signatures. E-ID is thereby, by law, equivalent to hand-written signatures. However an e-ID signature is more complex and harder to forge than a hand-written signature, and should therefore provide an even stronger evidence of agreement than a hand-written one. Only to add even further to the strength of the evidence, the document is also signed by e-mail verification. Therefore, we can draw the conclusion that this method of verification is exceptionally strong.

Identification of fraud

A controversial part of the discussion about electronic methods for identification deals with whether the integrity of the verification tool can be guaranteed: how to prevent contracts to be signed by an intruder if an e-mail account has been hijacked or the verification code for an e-ID has been stolen? Unfortunately the answer cannot be resolved by Scrive, since this is outside of Scrive's domain of control. Before drawing any conclusions from this one should as oneself: what is really the difference between today's hand-written signatures and the electronic signatures provided by Scirve? How well does a hand-written signature answer to the very same questioning? As far as we know, no stolen passwords or technical knowlage is required to forge a hand-written signature, only a paper and a pen is needed, and how secure is that? Our conclusion is that electronic signatures by default is one step more secure than hand-written ones, since the technology itself forms a barrier to intruders and allows Scrive to witness the transaction by storing proof e.g. IP-adresses and advanced surveillance systems for preventing frauds. Scrive uses IP-registration and is considering implementing the advanced surveillance systems mentioned above.

Document signing process

User interface

A condition, according to Swedish law, for a signature to be valid is that the signing party understands what is signed. If this is not the case, the contract should be considered invalid. We have developed the following steps to ensure that all parties involved understand that they are signing, and what they are signing:

Step	User	Legal reason
1	Sender	The sender creates an account online in Scrive, communicates with another user who is invited to an account, or creates an account in the last step of a signing process through Scrive in which it was a signatory. The sender is assumed to understand the service.
2	Sender	The sender recives an e-mail with a welcome message containing information about the service and an activation link.
3	Sender	After clicking the link, the personal information is filled into Scrive, and the Terms Of Service are ridden and accepted.
4	Sener	When the sender is inviting the other party, it follows a three step process. First, a document is uploaded. Second, information about the counterpart is filled in and fields are that the counterpart is supposed to fill in are defined. In the last step, the sender signs the document by clicking "Sign".
5	Sender	When the sender clicks the button "Sign", a pop-up shows where the sender is asked if it s really sure about signing the document. When "Sign" is clicked, an invitation is sent by e-mail to the involved Counterparts, and the sender is informed that the document has been signed and sent.
6	Recipient	The recipient receives the message which contains an invitation to sign the document with the parties xyz, and information about how to proceed with the signing process.
7	Recipient	When the recipient clicks the link in the e-mail, a view inside Scrive appears where the recipient is informed that it should read the document carefully, and the associated contact information.
8	Recipient	To ensure that the recipient reads the who document, it has to scroll down to the bottom of the document to sign.
9	Recipient	When the recipient has scrolled through the whole document, he clicks a button with the text "Sign" if he wants to sign.
10	Recipient	When the recipient presses the button "Sign", a pop-up shows where the signatory is asked if it really wants to sign the document.
11	Recipient	Finally, when the document has been signed, an informative text appears, telling the recipient that the document has been signed.
12	Recipient & Sender	When all parties have signed the document, Scrive stamps it with the document information and a qualified signature. The document is then sent out to all involved parties by e-mail, telling them that the document has been signed, and that it is legally binding for all signatories.

After six steps through which the sender (step 1-5 and 12) and the recipient (step 6-12), each are informed that they are using a service to sign a document, they should reasonably understand:

1. That they are signing a legally binding document.
2. The contents of the document they are signing.
3. That they may only sing the document if they are the right person to do so.

Proof material

Stable software

To be able to generate strong proof materials, it is important that the system does not generate incorrect information, and that it does not have gaps in the system that allows it to be Manipulated in undesired ways. By thorough routines and stable technology, we ensure that the service Scrive is powered by stable and secure software.

Haskell:

The service Scrive is built upon the technology is Haskell, which is counted as one of the most stable and reliable software technologies ever developed. One of the reasons for this is that Haskell is developed to minimize human error in the software development by using something called "strong type checking". Strong type checking means that no code may be implemented into the system without first being accepted as logically compatible with the rest of the system through strict automatic tests. Because of this, some problems just cannot occur when programming in Haskell, and the probability of some other types of problems arising are much smaller than when using other technologies.

Rigorous tests:

To further secure the quality of the software, we follow a strict software update routine in several steps to ensure that secure that the software is tested thoroughly before being launched publicly Before being finally accepted, the software is end-tested through at least 10 steps following a protocol that guarantees that every part of the service is end-tested at least 3 times before being launched.

Encrypted communication:

All communication with our users and our partners are encrypted pursuant to the highest security standards to protect all data from distortion. For more information, please read the part entitled "Security".

Staff and security:

To protect the highest quality of the proof material possible, it is also important to protect the system from internal attacks.

1. We limit the number of individuals with access to the core of the system. Only our CTO and another two carefully selected technicians have access to make changes in our servers. Therefore, changes can only be made by a small, and carefully selected group of individuals.
2. All employees have to sign strict contracts regulating what is allowed within the context of the work, and all employees are examined thoroughly before being employed at Scrive.
3. The system logs all activities of our our servers. We register all changes, when they occur, and who preforms them. Thereby, all changes in the system are traceable.

Securing evidence

Evidence does not only have to be generated in the right way, but also has to be stored in a good way to prevent distortion and to maintain the credibility of the evidence in a possible court trial. To secure our evidence, we create a so-called "hash" from it, and stamp the hasch with a qualified signature. This guarantees that the evidence is qualitatively secured, and cannot be changed. Moreover, we take the security of evidence storage even one step further. After being stamped, the material is stored in high-security classed computer centers that does not allow material to be extracted, distorted and put back in again. The following types of material are stored in the way described above:

1. Selected parts of our logs (daily)
2. Our service, the software itself that generates the signed documents (after each system update)
3. Our service, how it looks from the user's point of view when he/she signs a document (after each system update)
4. All of our test documents (after each system update)

Handling of signed documents

Stamping

When all parties have signed a document, we encrypt it and send it to TrustWeaver where it is supplied with a qualified signature. The qualified signature is impossible to impair, and the document is thereby protected against distortion after stamping. The qualified signature is controllable when using, amongst others, Adobe Reader.

Storage

Without access to the original document, it is hard to prove the content of the document. Through experiences shared by our customers, we know that there are many different situations that can result in lost documents. One could believe that this is not the case when dealing with more important documents, such as investment contracts worth millions, but our studies have shown that more important documents are lost almost as often as less importunate ones. Because of this, we recommend our customers to select an appropriate storage for their documents. We offer two carefully selected types of storage with different levels of security:

1. TrustWeaver:

   As described in the security part of this document, TrustWeaver is our top security solution for storage. Except for the technical aspects described under Security, TrustWeaver differs from other storage solutions mostly in the way the documents are stored:
   1. To qualify as a TrustWeaver user, one has to go through rigorous controls to prevent users from endangering other user's data security.
   2. The service was created in a way that makes it impossible to remove a document and then put it back in. Therefore, the integrity of the document is further secured in addition to the stamping with the qualified signature.



2. Amazon:

   This storage alternative is hosted by the world leading cloud based storage solution, Amazon S3. As TrustWeaver, Amazon S3 is certified according to the SAS 70 II standards, and follows a strict data security policy. Despite this, Amazon is not able to provide the rigorous user controls and guaranties supplied by TrustWeaver.