Information Technology Reference
In-Depth Information
Let me give a few examples. “Co-sign” is in place and it sees that you have added a
new user to your organisation. “Co-sign” immediately generates digital signature keys; it
certifies those keys and does everything that is necessary to set up this user's ability to
digitally sign these transactions, documents, etc. We see that one of your users got
married and changed her name, but she is still a valid user in the system, so we
automatically re-certify her certificate. “Co-sign” sees that you have moved a user from
one organisation or unit to another, so we automatically re-certify the certificate. We see
that the user has been around for a year so he should re-certify himself, but he is still a
legitimate user in the system and the system automatically re-certifies him. We see that
you have fired one of your users or that one of your users has left the organisation, so we
automatically make sure that this particular user will not be able to sign again by
disabling the keys. So the administrator continues managing the users in the exact same
way that he has always done and we are able to infer from these operations the key
management that is required to allow these users to sign.
What does it look like from the user experience? What does the user see in such a
system? The user performs a log-on operation in the same way that he always logs on to
the system. I do not try, as I did in the past, to persuade an organisation to use a certain
authentication mechanism. The organisation has to think about the authentication, about
how to allow people to log on to the system, regardless of whether or not they deploy
digital signatures. Let us think about the authentication problem because people have
access to various network resources, various databases, various systems. You have to
authenticate people and it has nothing to do with digital signatures, so let us not tie the
two problems together.
So, we wait for the user to log on. Once he has done so, we use the log-on credentials
to allow the user to sign, and so, what does it look like from the user's point of view?
The user logs on to the system, brings up his Excel spreadsheet, does whatever he does
with Excel, presses a button for signing, and the document is signed. From the user's
perspective, I have solved a business problem. The document is signed and can now be
sent to anyone else either inside or outside the organisation. When that person receives
the document, he knows two things; he knows who signed it and he knows that the
document was not changed since the moment it was signed. That is what is important.
The user does not realise that there was a digital signature key; he does not know or care
what size the key was, if it was a CAN or a RAM or any other “mumbo jumbo” digital
signature terminology. He can actually seal this document, press a button and the
document is signed; he can log on from wherever he logs on and he has the ability to
sign. From the digital signature point of view, the problem has become extremely easy
for the user to see.
6.
CONCLUSIONS
We can basically claim that by providing such a solution we make the digital signature
transparent - transparent to the administrator, transparent to the user community. Because
it is transparent, it is easy to deploy, easy to use and also cheap, or should I say cost
effective and inexpensive. To summarise, what I have tried to show is that it is possible
to take what seems to be a difficult and complex problem, certainly a difficult and
complex one to solve over the past 15 years or so, and make it completely manageable
and very easy to integrate with different applications and very easy to install and use.
Search WWH ::
Custom Search