Note: Descriptions are shown in the official language in which they were submitted.
CA 02266141 1999-03-18
. .
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
.,
Method For Controlling The Application Of Digital Signatures To Electronic
Documents Based On Electronically Represented Business Signing Rules
Field of the Invention
The present invention relates generally to the field of electronic commerce
and
specifically relates to a method for controlling the application of digital
signatures
to electronic documents based on electronically represented business signing
rules.
Background of the Invention
The authority to commit a business to a purchase or a contract by handwritten
signature is a right granted only to a trusted few. Businesses typically take
reasonable precautions to preclude the abuse of this authority by requiring
multiple trusted signatures for higher value obligations and involving several
individuals in the processing and routing of such documents.
With the advent of electronic business ("eBusiness") and electronic commerce
("eCommerce"), handwritten signatures are no longer a viable means to verify
the
authenticity and/or evidence the existence of electronic documents, including
electronic financial instruments such as electronic checks, electronic
contracts,
electronic purchase orders etc. In order to replace handwritten signatures, it
is
already known to create a digital signature or electronic signature which can
be
associated with the electronic document to assist in verifying the
authenticity of
the electronic document. [Such a digital signature can be created by running
the
electronic document through a hashing operation which generates a unique fixed-
length hash. The hash is then converted into a digital signature by encrypting
the
hash using an encryption key private to the document author. This digital
signature is then attached to the electronic document and the document is sent
to
the recipient. The recipient can then recover the hash by decrypting the
digital
signature using a public decryption key complementary to the private
encryption
key. The authenticity of the document and the identity of the document's
author
can be verified by using the hash and the hashing algorithm.
Page 1 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
As businesses move toward "eBusiness" the need for improved control over the
application of the digital signatures to documents in electronic form is
expected to
increase.
Another example of prior art which has attempted to overcome these and other
problems is 'Electronic Funds Transfers Instruments' - U.S. Patent 5,677,955
assigned to The Financial Services Technology Corporation ("FSTC"). 5,677,955
provides a method of creating an electronic instrument for effecting a
transfer of
funds from an account of a payer in a funds-holding institution to a payee,
the
instrument including an electronic signature of the payer, and appending, to
the
electronic instrument, digital representations of a verifiable certificate by
the
institution of the authenticity of the account or the account holder. However,
5,677,955 does not address the problem of applying multiple digital
representations of a verifiable certificate, (also known as an "electronic
signature"
or a "digital signature") where multiple approvals are required.
Further, the prior art currently does not address other problems such as:
1. How to provide a flexible way for businesses to express their rules
relating to
the processing and signing of business documents recognizing the variety in
signing rules for analogous paper documents
2. How to provide a flexible way for any business, small or large, to
establish
reasonable access security over setting or editing the signing rules.
3. How to provide an efficient interface for an Administrator to establish the
signing rules and to review the rules that have been set.
4. A method for using the rules to control the processing of a document.
5. A method for businesses to express appropriate rules for the different
forms of
documents that require signature: e.g. purchase, orders and electronic checks.
6. How to provide for approvals that are not applied to the document but are
related to the document.
Summary of the Invention
The present invention is directed to a method for controlling the application
of
digital signatures to electronic documents based on electronically represented
business signing rules which obviates or mitigates at least one problem not
addressed by the prior art.
For example, the present invention addresses the general problem of
establishing and applying rules for signing any electronic document or
electronic
financial instrument, not just an electronic check.
Page 2 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
The rules are expressed electronically and referenced by a computer, rather
than
an individual, to route documents and control the application of the digital
signatures. The computer can determine whether sufficient signatures have been
obtained to conform to the businesses signing rules. The invention includes
the
design of a user interface which allows an "administrator" to express signing
and
processing rules for multiple electronic documents and multiple signers at the
same time.
The invention facilitates the electronic processing of transaction documents.
It
enables businesses to automate much of the labor-intensive processing of these
documents.
In one embodiment of the invention, there is provided a computer-based method
for configuring a set of digital business signing rules for the processing of
electronic documents involving the application of a digital signature, said
document created by at least one user, said method comprising the steps of:
a) establishing an identity and verification protocol for at least one system
administrator
b) verifying the identity of one of said at least one administrator using said
verification protocol
c) establishing an identity and verification protocol for said at least one
user based on parameters provided by said verified administrator, and
d) establishing a set of privileges and authority levels associated with said
electronic document for each of said at least one users based on
parameters provided by said verified administrator
In a particular aspect of the first embodiment, there comprises the additional
step
of:
e) establishing at least one task for processing a batch of at least one type
of said electronic documents
In a particular aspect of the first embodiment, the electronic document is an
electronic financial instrument.
In another particular aspect of the first embodiment, the identity and
verification
protocol for said at least one user includes a smartcard
In another particular aspect of the first embodiment, the identity and
verification
protocol for said at least one user includes a digital signature of the
digital
business rules pertaining to that user.
Page 3 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
In another particular aspect of the first embodiment, said privileges include
the
ability to edit one or more created electronic financial instruments.
In another particular aspect of the first embodiment, said privileges include
the
ability to schedule one or more created electronic financial instruments.
In another particular aspect of the first embodiment, said privileges include
the
ability to unilaterally approve one or more created electronic financial
instruments.
In another particular aspect of the first embodiment, said privileges include
the
requirement that a created electronic financial instrument be co-signed by one
or
more users.
In another particular aspect of the first embodiment, said privileges include
the
ability to endorse a created electronic financial instrument.
In another particular aspect of the first embodiment, said privileges include
the
ability to authorize a created electronic financial instrument.
In another particular aspect of the first embodiment, said privileges include
the
ability to send a created electronic financial instrument.
In another particular aspect of the first embodiment, said privileges include
the
ability to hold a created electronic financial instrument.
In another particular aspect of the first embodiment, said privileges include
the
ability to print a created electronic financial instrument.
Page 4 of 38
In another particular aspect of the first embodiment, said privileges include
the
ability to create one or more different types of electronic documents.
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
In a second embodiment of the invention, there is provided a computer-based
method of applying a set of digital business signing rules for the processing
of
electronic documents, said method comprising the steps of:
a) verifying the identity of an authorized user using a predefined
verification
protocol;
b) determining a set of privileges associated with said authorized user;
c) creating an electronic document in accordance with said privileges and
based on inputs provided by said authorized user;
d) attaching a digital signature to said electronic document; and
e) transmitting said electronic document to an authorized recipient of said
electronic documents in accordance with said privileges;
In a particular aspect of the second embodiment, after the attachment of said
digital signature performing the steps of:
requesting one or more additional authorized users to perform additional
processing tasks said electronic document;
attaching additional digital signatures complementary to said one or more
additional authorized users upon fulfillment of said tasks of said electronic
document;
In a third embodiment of the invention, there is provided a computer-based
method of modifying a set of digital business signing rules for the processing
of
electronic documents, said method comprising the steps of:
Page 5 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
a) verifying the identity of at least one authorized administrator using a
predefined verification protocol;
b) determining a set of privileges associated with said verified at least one
administrator;
c) modifying and/or establishing an identity and verification protocol for at
least one user based on parameters provided by said verified at least
one administrator, and
d) establishing a set of privileges and authority levels associated with said
electronic documents for each of said at least one users based on
parameters provided by said verified at least one administrator.
Without limiting the generality of the terms used in the embodiments discussed
herein, processing and/or processing tasks may include authorizing, approval,
review, scheduling, cosigning, editing, transmission, printing, and/or
encryption.
Without limiting the generality of the terms used in the embodiments discussed
herein, electronic documents include electronic financial instruments such as
electronic checks, electronic contracts, electronic purchase orders etc.
While only specific combinations of the various features and components of the
present invention discussed herein, it will be apparent to those of skill in
the art
that desired sub-sets of the disclosed features and components and/or
alternative
combinations of these features and components can be utilized, as desired. For
example, while the embodiments discussed herein are directed to the
authentication of electronic financial instruments, it is contemplated that
the
present invention can be applied to other work-flow applications where a
document may be submitted electronically to another individual for approval,
where such approval is required by the addition of a digital signature. Some
examples of such an application could include engineering drawings requiring
the
approval of a professional engineer, or prescription approval by a physician.
Page 6 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
Release: 4.0
Version Date: 12 March 1999
Table of Contents
1 Product
Overview.......................................................................
..................................9
2
Configuration..................................................................
............................................10
2.1 Configuration Steps
...............................................................................
..............
10
2.2 Administrator Set-up
...............................................................................
.............13
2.3 Name Document-Batch Types
.............................................................................14
2.3.1 Supported Document Types
.........................................................................14
2.3.2 Document-Batch Types
...............................................................................
.14
2.4 Set Authority Levels
...............................................................................
..............14
2.4.2 Default Authority Levels
...............................................................................
.14
2.5 Name User
Groups.........................................................................
.....................15
2.6 Set Processing
Sequence.......................................................................
.............15
2.6.2 Automation of Tasks
...............................................................................
......15
2.6.3 Assignment to Groups
...............................................................................
...
15
2.6.4 Exception
Handling.......................................................................
................15
2.6.5 Processing Sequence UI
..............................................................................1
6
2.7 Define Default Roles
...............................................................................
.............16
2.8 Set User List, Access Controls and Grouping
......................................................
17
2.9 Set User Privileges
...............................................................................
...............18
2.9.2 User Privileges UI
...............................................................................
..........
18
2.10 Bank Account
Setup..........................................................................
...............18
2.11 Registering with Trading Partners
....................................................................18
2.12 Other Configuration
Options........................................................................
.....19
2.12.1 Disabling Edit
Functionality..................................................................
.........19
2.12.2 Default Assignment of Exception Handling
...................................................19
2.13 Reviewing the
Configuration..................................................................
...........
20
3 Operation
...............................................................................
....................................
21
3.1 Starting the Application
...............................................................................
.........
21
3.1.1 Access Security
...............................................................................
.............
21
Page 7 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3.1.2 Privileges
...............................................................................
.......................21
3.1.3 Activity Log
...............................................................................
....................21
3.2 elnvoice Creation and
Issuance.......................................................................
....22
3.2.1 Step 1: Data Entry (May be
automated)........................................................22
3.2.2 Step 2: Transmission (May be
automated)....................................................22
3.3 elnvoice Receipt and
Processing.....................................................................
....23
3.3.1 Step 1: Retrieve entail (May be automated)
.................................................23
3.3.2 Step 2: elnvoice Batch Creation (Automated)
...............................................23
3.3.3 Step 3: elnvoice Batch Scheduling (May be automated) 23
...............................
3.3.4 Step 4: elnvoice Batch Review & Approval
...................................................23
3.4 eCheck Creation and Issuance
............................................................................25
3.4.1 Step 1: Data Entry (May be automated)
........................................................25
3.4.2 Step 2: eCheck Batch Creation (May be automated)
....................................25
3.4.3 Step 3: eCheck Batch Scheduling (May be automated) 25
................................
3.4.4 Step 4: eCheck Batch Review and Approval
.................................................25
3.4.5 Step 5: eCheck Batch Signing
......................................................................26
3.4.6 Step 6: eCheck Batch Transmission (May be
automated).............................26
3.5 eCheck Receipt and Processing
..........................................................................27
3.5.1 Step 1: Retrieve entail (May be automated)
..................................................27
3.5.2 Step 2: Endorse and Deposit (May be
automated)........................................27
3.5.3 Step 3: Confirmation
(Automated).................................................................27
4 Application Programming
Interfaces.....................................................................
......28
4.1 CDF Import of
Data...........................................................................
...................28
4.2 CDF Export of Data
...............................................................................
..............28
4.3 Import
API............................................................................
................................28
4.4 Export API
...............................................................................
............................28
4.5 Operating as a Server to a Custom
Application....................................................28
4.6 Configuration
AP1............................................................................
.....................28
Page 8 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
1 Product Overview
This software product address the need for secure and private electronic
exchange of digitally-signed electronic documents between businesses for the
purpose of electronic business ("eBusiness"). For example, the software lets
you
transmit digitally-signed and encrypted electronic payments with attached
remittance information directly to your suppliers by email.
An API enables the import and export of data from/to other computer systems
such as accounting packages. For example, one could import check data directly
from an Accounts Payable system.
Supported electronic documents (eChecks and elnvoices) are processed in
batches in a familiar manner analogous to the processing of paper documents.
Users can:
~ enter data through a UI or automatically through an API
~ edit the data
~ attach a reference document in electronic form
~ assign and schedule tasks related to the processing of batches of electronic
documents
~ review and approve a batch of documents (a digital signature is calculated
for each document and entered into the database as a record of approval)
~ sign the batch (digital signatures are calculated for each document in the
batch and appended to the document and entered into the database as a
record)
~ encrypt and transmit each document in the batch over the Internet by email
User access to the application and to its functionality is controlled through
a
table of user privileges. Privileges can be set for each user by document-
batch
type. For example a user may have signing privileges for eChecks (Document
Type) General (Batch Type) but be restricted from any access to eChecks
Payroll. The application also supports setting and assigning limits on signing
authority.
The application is written in Java and provides a client interface to a server
database. The application interfaces to a smartcard reader or a high assurance
signing device to control access to approval or signing operations. Other
operations can also be similarly controlled or not.
The technological foundation for RDM's eBusiness solutions was developed by
RDM during its participation in the FSTC's Electronic Check (eCheck) Project.
1.1 Subject to change
This document is subject to change by RDM from time to time as RDM deems
appropriate to meet the perceived needs of its customer base. The software
produced by RDM may not be implemented exactly as set out in this document.
Page 9 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
2 Configuration
2.1 Configuration Steps
There are a number of steps required before the application can be used in
production. The term "configuration" will be used here to refer to both the
application settings and the setting of user privileges.
The configuration process may seem like an onerous task but it is simplified
in
several ways:
There are default or recommended settings for every option. In many cases
you may just need to review and confirm the default settings.
~ Settings can be made for multiple document-batch types and multiple users
or Group of users at the same time.
~ You can establish user privileges for a "role" once and simply assign those
settings to a user or a Group of users.
2.1.1.1 Step 1: Administrator Set-up
For security reasons, the first step after installation is to identify the
users that
will have Administrator Level Access and set limits on their rights.
Administrator
Level Access implies the right to view and change the application
configuration
(including the privileges of other users). During the post-install initial
configuration, you will also establish the number of Administrators required
to
make changes to the configuration. The recommended number is 2.
Once the Administrators have been identified and their rights established, the
Administrators can review the default settings for the following options and
adapt
or confirm these as appropriate to suit the operations of the company.
2.1.1.2 Step 2: Name Document-Batch Types
The application allows you to name several batch types for each electronic
document type. This enables you, for example, to establish one set of rules
for
processing eChecks to pay suppliers and another for payroll eChecks. Another
example would be approval of an eP0 (purchase order) relating to parts
inventory as opposed to an eP0 for a capital purchase.
2.1.1.3 Step 3: Set Authority Levels
Authority Levels are set for each Document-Batch Type. These levels are then
provided as a drop-down selection when setting a user's approval or signing
limit.
2.1.1.4 Step 4: Name User Groups
Since users are implicitly grouped by their signing authority levels and by
their
access to specified document-batch types, Step 4, involving an explicit
grouping,
is optional and the default is that there are no Groups.
While it is not necessary to group users, an explicit grouping can be used to
further differentiate users when defining the processing sequence for a
Page 10 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
document-batch type. For example, users may be grouped by department so
that a processing rule could be "Operations then Purchasing then Finance".
Alternatively they could be simply "A then B then C". This option allows for
the
expression of more complex rules than can be expressed on the basis of
document-type and signing authority alone.
2.1.1.5 Step 5: Set Processing Sequence
For each Document-Batch Type the Administrator defines the sequence of
processing tasks. Although a simple default sequence is suggested, there is
much variety in practice from company to company and hence it is likely that
the
defaults will need to be adapted to meet your requirements.
Tasks include:
data entry or import (batch creation)
scheduling (assignment of batch processing tasks)
review and approval (digital signature for internal record keeping)
signing (digital signature to be included in the transmission)
encryption (optional)
transmission (email)
exception handling (processing rejected documents or those on hold)
2.1.1.6 Step 6: Define Default Roles
This step is optional but recommended in cases where many users perform
similar roles. In that event, this step can greatly simplify the process of
setting
User Privileges. It can also be easier to define appropriate privileges in
terms of
a Role such as "eCheck-General Signer" or "eP0-Capital Purchaser". The
application suggests default user privileges for these and other Roles
associated
with document-batch types. The suggested privileges are based on separation of
tasks for security considerations. The default settings can be edited and
supplemented to suit your requirements.
2.1.1.7 Step 7:
Page 11 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
Set User List, Access Controls and Grouping
A table of authorized users is maintained by the application. In a preferred
embodiment, users of the application must either enter their User Name or
insert
a smartcard with their User Name. The name will be checked against the
authorized user list. In a preferred embodiment, the name must be unique. The
level of access control can vary. For users with limited rights, smartcard
access
control may not be necessary. If user Groups have been named (Step 4) users
can now be associated with those Groups.
2.1.1.8 Step 8:
Page 12 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
Set User Privileges
The final step prior to production use is to set privileges for each user for
each
document-batch type they will process.
2.1.1.9 Final Steps: Bank Account Setup, Registration and other Options
Finally the user enters information about the bank accounts) and send trading
partners the Public Key for information exchange.
Each of the above steps is reviewed in detail below.
2.2 Administrator Set-up
2.2.1.1 Warning: The first smartcard used with the application after
installation will have
access to the application configuration settings, including the Privileges
Table,
which controls the access and processing rights of each user. The initial
configuration of the application is carefully monitored because this will
establish
whether or not a single Administrator can make changes unilaterally. The
application has recommended or default settings for all options. The default
setting for the number of Administrators required to change the application
configuration or user privileges is 2. However, this setting can be reduced to
1
immediately after install which will effectively vest considerable control
over the
processing of digitally-signed documents in one individual.
2.2.1.2 Any number of users can be designated to have Administrator
privileges. It is
recommended that 3 or more persons be established as administrators
immediately after installation and that the number of Administrators required
to
effect a change to user privileges be set to 2. The application will then
allow any
administrator to input a set of changes but require that the changes be
approved
by a second administrator before the user access privileges are updated. All
administrators require smartcard and password level access control (see 2.8
below).
2.2.1.3 The first time a user with Administrator privileges uses the
application he/she will
be prompted to enter a password as a secondary control over edit access to the
Privileges Table. Henceforth when, the menu item Edit Privileges Table is
selected, the application will confirm that the user has Administrator level
privileges and prompt for the password corresponding to the Username before
providing access.
2.2.1.4 If an Administrator forgets hislher password, a second user with
Administrator
level privileges can deactivate the password control on the first's access,
enabling him to enter a new password when he next uses the application.
2.2.1.5 An Administrator can change his password after he has entered it, but
he cannot
deactivate the password control for his own Username.
2.2.1.6 In its standard shipping configuration, the RDM application restricts
persons with
Administrator privileges from having the rights to sign an eCheck, of any
value,
without a co-signer.
Page 13 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
2.3 Name Document-Batch Types
2.3.1 Supported Document Types
2.3.1.1 Supported Document Types are:
elnvoice
eCheck
eDeposit
2.3.2 Document-Batch Types
2.3.2.1 For each Document Type, the Administrator may designate multiple Batch
Types. All Document Types have a default Batch Type called "General".
Additional Batch Types can be designated in order to provide for separate
processing of confidential documents. For example, eChecks might be
designated the following Batch Types:
General (Default)
Payroll
Confidential 1
Confidential 2
2.3.2.2 The Administrator may set up to 4 Batch Types for each supported
Document
Type. However, there is no purpose in adding Batch Types beyond the default
"General" unless that type is going to be used for purposes of restricting
user
access.
2.3.2.3 This interface also allows the Administrator to specify a maximum
number of
documents per batch for each Document-Batch Type. This provides for the
automated distribution of volume among multiple authorized users.
2.4 Set Authority Levels
2.4.1.1 The application allows businesses to specify levels of authority for
approval and
signing for each Document-Batch Types. These levels are then used in
establishing signing limits for individual users and for separating batches
for
processing.
2.4.1.2 When Authority Limits are set, both for review and approval and for
signing,
these Authority levels are used.
2.4.2 Default Authority Levels
2.4.2.1 The application includes default settings for Authority Levels which
are as
follows:
Page 14 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
Level Default
1 Up 1,000
to
2 Up 10,000
to
3 Up 50,000
to
4 Up 100,000
to
Up 250,000
to
6 Up 1,000,000
to
7 Over1,000,000
The default settings can be edited by the Administrator. When a new Docurnent-
Batch Type is created, the default Authority Levels are assigned and the
Administrator is given the option of editing the Authority Levels for that
Document-Batch Type.
2.5 Name User Groups
2.5.1.1 This Step is optional.
2.5.1.2 The ability to associate users with particular groups (e.g. Finance,
Purchasing
and Executive or A, B, C) will be implemented for the next release.
2.6 Set Processing Sequence
2.6.1.1 For every document-batch type, the Administrator will select from a
drop-down
the tasks to be performed in processing that document-batch type in the
sequence in which they are to be performed.
2.6.1.2 This can be done for multiple document-batch types at once.
2.6.2 Automation of Tasks
2.6.2.1 For several tasks (such as Data Import, Scheduling or Transmission)
the
application allows the Administrator to specify whether a task will be
automated
(in effect assigned to the computer) or manual. While these tasks will be
automatically performed by the computer, the Administrator has the option of
assigning the task to a user or a Group. This allows for human intervention,
review, confirmation before proceeding to the next step.
2.6.3 Assignment to Groups
The application will automatically assign the task to an individual or
multiple
individuals (where co-signing is required) based on the user privileges set in
Step 8 for the document-batch type. However, the Administrator can control the
computer's options for assignment more specifically by specifying groups. This
can also be used for sequencing the tasks more specifically (see example
below. )
2.6.4 Exception Handling
2.6.4.1 As a batch of documents is processed, some documents may be rejected
for
invalid format or held by a user for clarification. These documents are
Page 15 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
automatically put in an exception batch. The processing of any exception
batches is automatically assigned to the default user or Group specified (see
Default Assignment of Exception Handling below). However, the default
assignment can be changed through this dialog.
2.6.5 Processing Sequence UI
2.6.5.1 The following is an example of what the UI may look like and an
example of a
Processing Sequence.
TBD.
2.7 Define Default Roles
2.7.1.1 The administrator can set privileges associated with a named role
rather than a
user. For example, the Administrator may identify a role as "check signer" and
associate privileges with that role. The administrator can then use these pre-
defined roles to simplify the task of setting up user. By clicking on the
"Role"
button the Administrator can associate these rights with one or more users for
one or more document-batch categories by simply selecting a role from the drop
down list of pre-defined roles.
2.7.1.2 A number of common roles will be pre-configured in the application.
These can
be edited, supplemented or deleted by the Administrator as needed.
Page 16 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
2.8 Set User List, Access Controls and Grouping
2.8.1.1 An Administrator enters the names of all users. If a user's access is
to be
controlled by a smartcard, the user name entered must be the same as on the
user's smartcard. Until a user is listed in the User List, they will not be
able to
sue the application for any purpose.
2.8.1.2 An administrator can enter the user names of all users and identify
how access
will be controlled. Options are:
No access control Access control is external to the
application or
there is none.
Password The user enters a password to gain
access to the
application.
Smartcard A smartcard must be present matching
the user
name and the user enters a PIN which
is checked
against the PIN number on the smartcard.
In this release, this level of access
control is
required for all signing operations
and the digital
signatures are calculated on the
smartcard.
Smartcard and This is recommended for Administrator
level
Password access.
2.8.1.3 A user in the user list can also be associated with a group. This is
optional.
Associating the user with a group allows the Administrator to include a group
distinction in the signing rules. For example, the check must be co-signed by
someone from Group A and someone from Group B.
Page 17 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
2.9 Set User Privileges
2.9.1.1 User privileges are assigned for each Document-Batch category.
2.9.1.2 Default rights are none. Therefore, no access is provided to any user
until the
Administrator designates the user's privileges.
2.9.2 User Privileges UI
2.9.2.1 The interface for setting User Privileges will look something like
this:
2.9.2.2 Limits can be associated with approval levels and signing levels. In
each case,
two limits can be set: an "Alone" limit and a "Co-sign" limit.
2.9.2.3 For approval signatures, the "Alone" limit defaults to zero and the
"Co-sign" limit
defaults to the lowest approval authority for that Document-Batch Category.
Both
fields provide drop-down functionality allowing the Administrator to select
another option from the Signing Levels set for that Document-Batch Category
(refer to 2.4 above).
2.9.2.4 For authorization signatures, both the "Alone" limit and the "Co-sign"
limit default
to zero. Both fields provide drop-down functionality allowing the
Administrator to
select another option from the Signing Levels set for that Document-Batch
Category (refer to 2.4 above).
Page 18 of 38
The same user privileges can be set for multiple users and for multiple
Document-Batch Categories simultaneously.
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
2.10 Bank Account Setup
2.10.1.1 Suggest RDM supply an applet that allows a bank to create and
maintain a file
on their web site which would contain generic account block info relating to
that
bank. The data would be digitally signed by the banks private key. The user
could just download that and it could update our application and register the
bank.
2.10.1.2 The bank will supply the information necessary to facilitate
transmission of
deposits. This information includes the email addresses to send registrations
and deposits (they may be different) as well as the bank's public key for
encrypting deposits for transmission. If the bank distributes the software to
its
customers this information may be pre-configured. The account information
itself
is contained on the smartcard and can be automatically included in any
documents the user generates.
2.10.1.3 If one wishes to make deposits to more than one bank, the foregoing
points
would also apply. The default will be the first account established unless
otherwise selected by the Administrator.
2.11 Registering with Trading Partners
2.11.1.1 In order for a business to send data (eg, elnvoices or eChecks) to
another
business it is necessary to know the recipient's echeck email address and
public
key for encryption. The application's database maintains a table of trading
partners that contains this information. This table is populated by means of
registration documents exchanged between the partners.
2.11.1.2 In general, any business that receives an eDocument registers with
whoever will
be sending the eDocument. For example, a business that wants to be paid by
echeck must register with each payer who is capable of sending echecks.
2.11.1.3 To begin the registration process, the receiver obtains the email
address of the
sender. This is done in an "out-of-band" process, eg., by telephone. Using the
Echeck application, the receiver then creates a registration document that
contains all the information that a sender needs to know in order to send the
receiver an eDocument. This is a largely an automated process since the
application already has access to all the information that will be included in
the
registration document. The document is then emailed to the sender using the
email address that was obtained previously (the receiver types in the
address).
This registration document is digitally signed and is sent unencrypted.
2.11.1.4 When the sender retrieves the registration document and processes it
using the
Echeck application, after verifying the signature the information in the
document
is extracted and saved in the database. Now, whenever the sender needs to
send an eDocument to the receiver he can simply select the receiver from a
list
of eligible receivers. The eDocument will be automatically encrypted for
transmission to the receiver using the receiver's public key and emailed to
the
correct email address. The sender never needs to be specifically concerned
with
the details of the transmission.
Page 19 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
2.12 Other Configuration Options
2.12.1 Disabling Edit Functionality
2.12.1.1 In situations where the data is input from an accounting system, one
may want
to disable edit functionality entirely, forcing the user to go back to the
accounting
system to make changes. This is a prime example of a constraint that may be
set once and enforced for all users. This can be set by Document-Batch
Category.
2.12.2 Default Assignment of Exception Handling
2.12.2.1 The application allows the Administrator to assign the Exception
Handling task to
an individual or a Group as a default. This can be done for all document types
or
for specific document types. This default will then automatically be set for
all
related document-batch types but can be modified for individual document-batch
types in Step 6, Set Processing Sequence.
Page 20 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
2.13 Reviewing the Configuration
2.13.1.1 Viewing User Privileges
User privileges can be viewed by user or by Document-Batch Type. The latter
would look something like this:
Page 21 of 38
The ability to view user privileges is itself a privilege set by the
Administrator.
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3 Operation
3.1 Starting the Application
3.1.1 Access Security
3.1.1.1 When the application is started, the user is prompted to enter a PIN
number. The
PIN number is matched against the PIN number on the smartcard in the
smartcard reader. If the smartcard is missing, an appropriate message is
displayed.
3.1.1.2 The Administrator can designate that certain activities, such as
scheduling, do
not require a smartcard, but simply a password.
3.1.1.3 Access to any signing activity requires a smartcard.
3.1.1.4 Access to certain activities, such as setting user privileges, are
restricted by both
PIN number and password.
3.1.2 Privileges
3.1.2.1 When a user logs into the application, his PIN number is checked
against the
smartcard in the smartcard reader. If this matches, the User Name from the
smartcard is used to look up the user's privileges in the Privileges Table.
These
privileges are then used to control the user's access and processing (refer to
2.8
above).
3.1.2.2 Each time the user selects an activity the application first confirms
that the
smartcard in the reader has not changed. If the smartcard is not present or
has
changed, the application removes any data from display and presents a dialog
for the user to log in or exit the application.
3.1.2.3 This will also happen if the application detects no activity for a
period of time (the
time period is configurable). The application will save any data and its
current
status before exiting.
3.1.3 Activity Log
3.1.3.1 Every action that results in a change to a document or the status of a
document
is logged along with the user's name and date/time.
Page 22 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3.2 elnvoice Creation and Issuance
3.2.1 Step 1: Data Entry (May be automated)
3.2.1.1 Manual entry of invoice data or automated input of comma delimited
file (CDF).
3.2.1.2 Document type detection
3.2.1.3 Database record creation
3.2.1.4 Payer IDs matched with email addresses
3.2.1.5 If CDF contains path of reference document this is included as an
attachment
3.2.1.6 FSML data validation
3.2.1.7 Invalid records rejected - goes to an exception batch for review
3.2.2 Step 2: Transmission (May be automated)
3.2.2.1 Valid invoices are digitally signed using the private key
corresponding to the
public key registered with the Payer. This can be automated.
3.2.2.2 Valid signed invoices be transmitted by an authorized operator or
automatically
transmitted. Operator processing only requires a single mouse click: "Send".
3.2.2.3 Each invoice is encrypted using the configured encryption routine.
3.2.2.4 The invoices are automatically emailed to the email address in the
invoice
record.
Page 23 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3.3 elnvoice Receipt and Processing
3.3.1 Step 1: Retrieve entail (May be automated)
3.3.1.1 entail retrieved
3.3.1.2 Messages decrypted, validated and database record created
3.3.1.3 entail that does not comply to FSML format forwarded to designated
mailbox for
review
3.3.1.4 digital signatures authenticated
3.3.1.5 invalid signatures given status "signature invalid"
3.3.1.6 all valid elnvoices given status "for payment"
3.3.2 Step 2: elnvoice Batch Creation (Automated)
3.3.2.1 Documents sorted by signing levels
3.3.2.2 Documents batched within signing levels, reference to max documents
per batch
3.3.2.3 Batches numbered for reference
3.3.2.4 Batch status "new"
3.3.2.5 Batch creation date associated with batch
3.3.3 Step 3: elnvoice Batch Scheduling (May be automated)
For each "new" elnvoice batch:
3.3.3.1 Set batch type (e.g. "general" or "payroll") - this will limit access
to those who
have access to that type
3.3.3.2 Schedule and assign review & approval task (may be assigned to
multiple staff
in sequence - application may be configured to automatically assign elnvoice
batches for review and approval)
3.3.3.3 Batch status "Scheduled"
3.3.3.4 Task status is colour coded white until it becomes active, red once it
is active,
orange if partially completed and green once complete
3.3.4 Step 4: elnvoice Batch Review & Approval
This task may be assigned to multiple staff in sequence: e.g. Jones then Smith
then Rushdie
3.3.4.1 Hold any invoice - it is removed from batch for review - a question
can be
entered
3.3.4.2 Approve invoice for payment - each invoice digitally signed and
signature stored
in payment record as a record of approval for payment
Page 24 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3.3.4.3 Batch status remains "approval required" until all assigned reviewers
have
approved, then status "approved"
3.3.4.4 Approval status is red if there are no approvals, orange if some
approvals have
been obtained but some remain and green if all assigned approvals signatures
are obtained
3.3.4.5 Once status is "approved" a corresponding eCheck batch is created and
elnvoices are included as attachments
3.3.4.6 ECheck batch is given the status new and the batch enters the Payer
eCheck
processing at Step 3
Page 25 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3.4 eCheck Creation and Issuance
3.4.1 Step 1: Data Entry (May be automated)
3.4.1.1 Manual entry of payment data or automated input of comma delimited
file (CDF)
3.4.1.2 Document type detection
3.4.1.3 Database record creation
3.4.1.4 Payee IDs matched with email addresses
3.4.1.5 If CDF contains path of reference document this is included as an
attachment
3.4.1.6 FSML data validation
3.4.1.7 Invalid records rejected
3.4.2 Step 2: eCheck Batch Creation (May be automated)
3.4.2.1 Documents sorted by signing levels
3.4.2.2 Documents batched within signing levels, reference to max documents
per batch
3.4.2.3 Batches numbered for reference
3.4.2.4 Batch status "new"
3.4.2.5 Batch creation date associated with batch
3.4.3 Step 3: eCheck Batch Scheduling (May be automated)
For each "new" batch:
3.4.3.1 Set batch type (e.g. "general" or "payroll") - this will limit access
to those who
have access to that type
3.4.3.2 Schedule and assign review & approval task (may be assigned to
multiple staff
in sequence - application may be configured to automatically assign batches
for
review and approval)
3.4.3.3 Schedule and assign signing task (application will indicated whether
one or two
signatures are required and may be configured to suggest assignments or
automatically assign)
3.4.3.4 Schedule and assign transmission task (may be automated)
3.4.3.5 Batch status "Scheduled"
3.4.3.6 Task status is colour coded white until it becomes active, red once it
is active,
orange if partially completed and green once complete
3.4.4 Step 4: eCheck Batch Review and Approval
This task relates to approvals required prior to financial approval and may be
assigned to multiple staff in sequence: e.g. Jones then Smith then Rushdie
Page 26 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3.4.4.1 Hold any payment - it is removed from batch for review - a question
can be
entered
3.4.4.2 Approve payments - each payment digitally signed and signature stored
in
payment record as a record of approval - this signature is not part of the
check
signature block
3.4.4.3 Batch status remains "approval required" until all assigned reviewers
have
approved, then status "approved"
3.4.4.4 Approval status is red if there are no approvals, orange if some
approvals have
been obtained but some remain and green if all assigned approvals signatures
are obtained
3.4.4.5 Once status is "approved" first signer given signing task
3.4.5 Step 5: eCheck Batch Signing
This task relates to financial approval - the signatures that would normally
appear on a paper check - and may be assigned to up to two staff in sequence:
3.4.5.1 Hold any payment - it is removed from batch for review - a question
can be
entered
3.4.5.2 Sign payments - each payment digitally signed and signature becomes
part of
signature block
3.4.5.3 Batch status remains "signature required" until all assigned reviewers
have
approved, then status "signed"
3.4.5.4 Signing status is red if there are no approvals, orange if some
approvals have
been obtained but some remain and green if all assigned approvals signatures
are obtained
3.4.5.5 Once status is "signed" transmission task is red
3.4.6 Step 6: eCheck Batch Transmission (May be automated)
3.4.6.1 Once batch signing status is green (signed) the batch can be
transmitted by an
authorized operator or automatically transmitted based on a transmission date.
Operator processing only requires a single mouse click: "Send".
3.4.6.2 Each payment is encrypted using the configured encryption routine.
3.4.6.3 The payments are automatically emailed to the email address in the
payment
record.
Page 27 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3.5 eCheck Receipt and Processing
3.5.1 Step 1: Retrieve entail (May be automated)
3.5.1.1 email retrieved and validated
3.5.1.2 messages decrypted, validated and database record created
3.5.1.3 email that does not comply to FSML format forwarded to designated
mailbox for
review
3.5.1.4 digital signatures authenticated
3.5.1.5 invalid signatures given status "signature invalid"
3.5.1.6 all valid echeck payments given status "for deposit"
3.5.2 Step 2: Endorse and Deposit (May be automated)
3.5.2.1 Attachments are removed
3.5.2.2 All payments "for deposit" are presented in a window for review (or
automatically
submitted to endorse module if application is so configured)
3.5.2.3 Each payment is endorsed (signed) using the private key of the
endorser
3.5.2.4 A deposit slip is created and signed using the private key of the
signer
3.5.2.5 The deposit is encrypted and emailed
3.5.2.6 eCheck record status is changed to "deposited" and the deposit slip
number and
date are also entered into the record
3.5.2.7 deposit status "sent"
3.5.3 Step 3: Confirmation (Automated)
3.5.3.1 Confirmation email accepted from Payee bank confirming receipt of
valid deposit
slip - deposit status updated to "receipt confirmed"
3.5.3.2 If deposit receipt not confirmed within configured time, operator
alerted or
deposit can be automatically resent
Page 28 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
4 Application Programming Interfaces
4.1 CDF Import of Data
The application will support the import of data corresponding to each
supported
file format in a comma delimited format. The cdf will include:
document type,
batch type, (may be blank in which case it defaults to "general")
batch number, (may be blank in which case the application will automatically
number it)
data fields
4.2 CDF Export of Data
The application will support the import of data corresponding to each
supported
file format in a comma delimited format. The data will be similar to that
listed in
4.1.
4.3 Import API (TBD)
A formal API for import of documents will be developed in consultation with
customers and providers of compatible software products, particularly
providers
of accounting software products. Specifications to be determined.
4.4 Export API (TBD)
A formal API through which integrators may access data in the application
database will be developed in consultation with customers and providers of
compatible software products, particularly providers of accounting software
products. Specifications to be determined.
4.5 Operating as a Server to a Custom Application
The application may be operated as an FSML processing server to another
application. Calls to the Software will be made through an API which will
expose
the function calls on which the RDM GUI is built. That would allow others to
create custom GUIs using the core libraries as an FSML processing engine to
implement the required functionality.
4.6 Configuration API
Control over the look and feel will be provided through configuration tools
and
control over processing functionality will be provided through an Application
Programming Interface (API) Toolkit. The Toolkit will make it possible to:
Page 29 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
4.6.1.1 Make the menus and toolbars document sensitive. For example, the
ability to
associate one menu/toolbar set with an echeck and another with an invoice so
that the user interface would change depending on the document being
processed.
4.6.1.2 Restrict the Software to processing of a subset of supported FSML
document
types. This would allow resellers to set a lower price point for a version
that
processed only echecks as opposed to one that processed echecks, invoices
and purchase orders.
4.6.1.3 Designate a language file to be used for the UI.
4.6.1.4 Designate the number of incorrect PIN number entries to allow before
locking
the Software.
Page 30 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
The following is another embodiment of the invention for the configuration of
a set of
digital business signing rules.
Digital Business Signing Rules: Description of Invention
1. Administrator Set-up
The first smartcard used with the application after installation will have
access to
the application configuration settings, including the Privileges Table, which
controls the access and processing rights of each user. The initial
configuration
of the application is carefully monitored because this will establish whether
or not
a single Administrator can make changes unilaterally. The application has
recommended or default settings for all options. The default setting for the
number of Administrators required to change the application configuration or
user privileges is 2. However, this setting can be reduced to 1 immediately
after
install which will effectively vest considerable control over the processing
of
digitally-signed documents in one individual.
Any number of users can be designated to have Administrator privileges. It is
recommended that 3 or more persons be established as administrators
immediately after installation and that the number of Administrators required
to
effect a change to user privileges be set to 2. The application will then
allow any
administrator to input a set of changes but require that the changes be
approved
by a second administrator before the user access privileges are updated. All
administrators require smartcard and password level access control.
The first time a user with Administrator privileges uses the application
he/she will
be prompted to enter a password as a secondary control over edit access to the
Privileges Table. Henceforth, when the menu item Edit Privileges Table is
selected, the application will confirm that the user has Administrator level
privileges and prompt for the password corresponding to the Username before
providing access.
If an Administrator forgets his/her password, a second user with Administrator
level privileges can deactivate the password control on the first's access,
enabling him to enter a new password when he next uses the application. An
Administrator can change his password after he has entered it, but he cannot
deactivate the password control for his own Username.
In its standard shipping configuration, the RDM application restricts persons
with
Administrator privileges from having the rights to sign an eCheck, of any
value,
without a co-signer.
Page 31 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
2. Name Document-Batch Types
Supported Document Types are:
elnvoice
eCheck
eDeposit
Document-Batch Types
For each Document Type, the Administrator may designate multiple Batch
Types. All Document Types have a default Batch Type called "General".
Additional Batch Types can be designated in order to provide for separate
processing of confidential documents. For example, eChecks might be
designated the following Batch Types:
General (Default)
Payroll
Confidential 1
Confidential 2
The Administrator may set several Batch Types for each supported Document
Type. However, there is no purpose in adding Batch Types beyond the default
"General" unless that type is going to be used for purposes of restricting
user
access.
This interface also allows the Administrator to specify a maximum number of
documents per batch for each Document-Batch Type. This provides for the
automated distribution of volume among multiple authorized users.
Document-Batch Table Fields
~ eDocument
~ eBatch
~ Maximum documents per batch
Page 32 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
3. Set Authority Levels
The application allows businesses to specify levels of authority for approval
and
signing for each Document-Batch Types. These levels are then used in
establishing signing limits for individual users and for separating batches
for
processing.
When Authority Limits are set, both for review and approval and for signing,
these Authority levels are used.
Default Authority Levels
The application includes default settings for Authority Levels which are as
follows:
Level Default
1 Up 1,000
to
2 Up 10,000
to
3 Up 50,000
to
4 Up 100,000
to
Up 250,000
to
6 Up 1,000,000
to
7 Over1,000,000
The default settings can be edited by the Administrator. When a new Document-
Batch Type is created, the default Authority Levels are assigned and the
Administrator is given the option of editing the Authority Levels for that
Document-Batch Type.
Authority Level Table Fields
~ eDocument
~ eBatch
~ Number of Levels n
~ Level 1 Limit
~ Level 2 Limit
~ Level n Limit
Page 33 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
4. Name User Groups
This Step is optional.
The ability to associate users with particular groups (e.g. Finance,
Purchasing
and Executive or A, B, C) will be implemented for the next release.
User Group Table Fields
User Group
Page 34 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
5. Set Processing Sequence
For every document-batch type, the Administrator will select from a drop-down
the tasks to be performed in processing that document-batch type in the
sequence in which they are to be performed.
This can be done for multiple document-batch types at once.
Automation of Tasks
For several tasks (such as Data Import, Scheduling or Transmission) the
application allows the Administrator to specify whether a task will be
automated
(in effect assigned to the computer) or manual. While these tasks will be
automatically performed by the computer, the Administrator has the option of
assigning the task to a user or a Group. This allows for human intervention,
review, confirmation before proceeding to the next step.
Assignment to Groups
The application will automatically assign the task to an individual or
multiple
individuals (where co-signing is required) based on the user privileges set in
Step 8 for the document-batch type. However, the Administrator can control the
computer's options for assignment more specifically by specifying groups. This
can also be used for sequencing the tasks more specifically (see example
below.)
Exception Handling
As a batch of documents is processed, some documents may be rejected for
invalid format or held by a user for clarification. These documents are
automatically put in an exception batch. The processing of any exception
batches is automatically assigned to the default user or Group specified (see
Default Assignment of Exception Handling below). However, the default
assignment can be changed through this dialog.
Processing Sequence UI
The following is an example of what the UI may look like and an example of a
Processing Sequence.
TBD.
Processing Sequence Table Fields
~ eDocument
~ eBatch
~ Step 1
~ Step 1 Group
~ Step 2
~ Step 2 Group
~ Step n
~ Step n Group
~ Exception
For example:
Page 35 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
<eDoc> eCheck
<eBatchType>General
<Step 1 >Import
<Step I Group>Accounts Payable
<Step2>Approve
<Step2Group>Accounts Payable
<Step3>Sign
<Step4>Encrypt
<StepS>Send
<Exception>Mary Smith
6. Define Default Roles
The administrator can set privileges associated with a named role rather than
a
user. For example, the Administrator may identify a role as "check signer" and
associate privileges with that role. The administrator can then use these pre-
defined roles to simplify the task of setting up user. By clicking on the
"Role"
button the Administrator can associate these rights with one or more users for
one or more document-batch categories by simply selecting a role from the drop
down list of pre-defined roles.
A number of common roles will be pre-configured in the application. These can
be edited, supplemented or deleted by the Administrator as needed.
The structure of the following table will be identical to the User privilege
Table
except that the first field will be a generic role rather than a specific user
and
there are no signatures required.
Default Roles Table Fields
~ Role
~ eDocument (optional)
~ eBatch (optional)
~ Import
~ Export
~ Entry
~ Edit
~ Schedule
~ Approve
~ Approve Alone Limit
~ Approve Cosign Limit
~ Authorize
~ Authorize Alone Limit
~ Authorize Cosign Limit
~ Hold
~ Send
~ View
~ Print
Page 36 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
7. Set User List, Access Controls and Grouping
In a preferred embodiment, an Administrator must enter the names of all users.
If a user's access is to be controlled by a smartcard, the user name entered
must be the same as on the user's smartcard. Until a user is listed in the
User
List, they will not be able to sue the application for any purpose.
An administrator can enter the user names of all users and identify how access
will be controlled. Options are:
No access Access control is external to the
control application or there is none.
Password The user enters a password to gain
access to the application.
Smartcard A smartcard must be present matching
the user
name and the user must enter a PIN
which is
checked against the PIN number on
the
smartcard.
In this release, this level of access
control
is required for all signing operations
and
the digital signatures are calculated
on
the smartcard.
Smartcard This is recommended for Administrator
and Password level access.
A user in the user list can also be associated with a group. This is optional.
Associating the user with a group allows the Administrator to include a group
distinction in the signing rules. For example, the check must be co-signed by
someone from Group A and someone from Group B.
User List Table Fields
~ User Name
~ Administrator
~ Group
~ Access Control
~ Digital Certificate (if required)
~ Cert Hierarchy Reference
Page 37 of 38
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
8. Set User Privileges
User privileges are assigned for each Document-Batch category.
Default rights are none. Therefore, no access is provided to any user until
the
Administrator designates the user's privileges.
User Privileges UI
The interface for setting User Privileges will look something like this:
Limits can be associated with approval levels and signing levels. In each
case,
two limits can be set: an "Alone" limit and a "Co-sign" limit.
For approval signatures, the "Alone" limit defaults to zero and the "Co-sign"
limit
defaults to the lowest approval authority for that Document-Batch Category.
Both
fields provide drop-down functionality allowing the Administrator to select
another option from the Signing Levels set for that Document-Batch Category.
For authorization signatures, both the "Alone" limit and the "Co-sign" limit
default
to zero. Both fields provide drop-down functionality allowing the
Administrator to
select another option from the Signing Levels set for that Document-Batch
Category.
Process
The first administrator sets up a user and clicks sign. The server application
will
then create a hash of the data and encrypt it using a session key. The session
key is encrypted with the public key of the Administrator from the server
database. The encrypted hash and session key are passed to the client
Page 38 of 38
The same user privileges can be set for multiple users and for multiple
Document-Batch Categories simultaneously.
CA 02266141 1999-03-18
Functional Specification: RDM eCheck Software
CONFIDENTIAL AND PROPRIETARY INFORMATION OF RDM
application. The client app uses the administrator smartcard to retrieve the
session key and decrypt the hash of the user's privileges. The Administrator
then
signs this with his private key on his smartcard and submits it to the server.
The
server authenticates the signature. If only one Administrator is required to
change a user's privileges the user privilege table is immediately updated and
the Administrators signature is entered into database record. If two
signatures
are required, the changes are held until the signature of a second
administrator
is obtained.
If a second Administrator signature is required the second administrator asks
to
review the changes signed by the first and then clicks sign. The same process
is
followed to provide the second signature to the Server. The Server will then
update the user privileges and record both signatures in the record.
If a third etc.
When a user logs in, the server will authenticate all signatures on the rule
set
and will then use the privileges to control the users access and signing
limits.
As an added precaution it is proposed that the all signatures on the user
privilege table be hashed and this has be encrypted in the server applet to
provide for a handshake between the server applet and the privileges table.
The
server applet would then periodically verify that the two are the same in
order to
ensure that no-one has tampered with the privileges table. Each time a user's
privileges are updated, this hash would need to be recalculated and stored for
reference. The database tables would be maintained in encrypted form.
User Privilege Table Fields
~ User Name
~ eDocument
~ eBatch
~ Import
~ Export
~ Entry
~ Edit
~ Schedule
~ Approve
~ Approve Alone Limit
~ Approve Cosign Limit
~ Authorize
~ Authorize Alone Limit
~ Authorize Cosign Limit
~ Hold
~ Send
~ View
~ Print
~ Admin 1 Signature
~ Admin 2 Signature
Page 39 of 38
