I did read over the blog post you mentioned, and I do apologize, but this is the first time I have heard of the company you mentioned, we probably would not be considered direct competitors. Again, I can’t comment on other solutions, but to give an idea of eOriginal and our solutions; we have been in the marketplace for 15 years, eOriginal participated in the drafting and standards support through the American Financial Services Association (AFSA), the Accredited Standards Committee (ACS) X9 committees establishing the standard for eContracts and chairing of the AFSA ACS X9 Transfer of Location of Electronic Contracts (TOLEC) standard committee, and the Mortgage Industry Standards Maintenance Organization (MISMO), including the eVault standards committees, and other organizations which deal with document security. As well as being the only company recognized by top ratings agencies to provide eContracting services that are rated as the same as wet ink on paper for securitizing, pledging, pooling, etc. in the secondary marketplace.

With regards to encryption and storage; Files stored in our Trusted Repository are digitally tamper sealed and encrypted on a doc by doc basis and if necessary any multimedia files (voice signatures, biometric data) attached to the documents are also treated with the same security and actually all actions taken against documents are completed on the server side which means greater security and control of eSigned documents, so – no hard drive is involved. Our trusted repository is a guarded facility with only privileged physical access.

Role based permission is not really security, it’s a means of authenticating and individual or group of individuals who have access to certain documents; I would be more than happy to explain, but I would say its hardly smoke and mirrors, as it is important to know who has access to what documents, and the ability to track and record that information.

I hope the information provided helps, but please feel free to contact me and we can dive a bit deeper. http://www.eoriginal.com

“basic requirments (sic) for e-signatures, which most providers fail to even meet” and

“My company has had me look into e-signature providers for a while now, and although most providers have decent products, they unfortunately still fall short”?

http://blog.docverify.com/2010/04/27/understanding-e-sign-concepts-and-requirements/

As for security, it is extremely important to make sure the e-signature solution provider you decide to go with isn’t just full of smoke and mirrors.

Yes, I agree SAS 70 Type II data centers is important, SSL, as well as encryption, but as a user you should always ask the provider to explain to you what that really mean when they say encryption.

Encryption at rest in most cases means files are encrypted on a disk level, and if someone walks off with a hard drive it’ll be encrypted, but what if one of their employees who has access to those same drives… can he/she copy your sensitive data and walk away with it. The answer is probably most definitly, yes. As for role based security… smoke and mirrors.

I wouldn’t even consider going with a provider unless they could prove that each and every document or file is individually encrypted. This can be extremely costly to the provider, but it’s currently one of the most secure ways of protecting files, and it should be your requirment. We’ve all heard about identity theft.

My company has had me look into e-signature providers for a while now, and although most providers have decent products, they unfortunately still fall short, except for one maybe two. I personally have locked on to DocVerify http://www.docverify.com, and they not only fit the bill, but they are far and above the most secure from what i’ve seen so far. They encrypt each file individually, and according to NIST it would take a hacker over 2 trillion years to crack each file. Also, they seem to be pretty knowledgable about e-signatures, its legality, and issues.

But whichever provider you end up going with, you should always ask the right questions.