SYSTEM AND METHODS OF PROVIDING VERIFIED NETWORK SESSIONS
VISUAL CONFIRMATION
This application claims the benefit of U.S. patent application Serial No. 60/157,642 filed
October 4, 1999, the entire disclosure of which, including references and drawings, is incor¬
porated herein by reference.
BACKGROUND OF THE INVENTION
Field of the Invention
The invention is related to the authentication and verification of two party transactions
over a computer network including visual confirmation thereof.
Related Art
On the Internet today, clients and servers often transact in ways that provide less than full
non-repudiation of messages exchanged. In particular, session level security, such as SSL
(secure sockets layer), does not provide non-repudiation and one party could later deny all or
part of a transaction, and the other party would be unable to prove otherwise.
So long as at least one of the parties has an impeccable reputation for honesty and integ¬
rity (e.g., a bank or large well-known merchant), that party can generally be relied upon to
maintain a reliable record of the transaction. However, the Internet enables all potential buy¬
ers and sellers of goods and services to transact with each other, and the potential for bad
conduct, or the fear of such bad conduct, will act as a deterrent to the full potential of online commerce.
One way to increase the level of proof in such transactions is to require all messages ex-
changed between the parties, or at least the most legally important ones, to be digitally signed
using an asymmetric public-private key cryptographic system. Such an approach can work to
provide the necessary level of proof, but the digital signing and verification operations needed during such a process can be exceedingly time consuming for a transactional web server. To
maintain any level of volume throughput, it is necessary to invest in costly hardware crypto¬
graphic acceleration boards. However, even such boards can only handle so much volume.
Due to increasing key length requirements, to defend against improved factoring methods, the need for such boards is likely to increase, rather than decrease over time.
Also, it is a formidable task to deploy digital signing and record-keeping capabilities
to individual desktop computer users (whether home or business). While the SSL secure ses¬
sion capability is widely deployed, the market for digital signing technologies remains im¬
mature, and equipping any large percentage of end users to handle a particular type or format of digital signing can be an insurmountable barrier to rapid adoption. In view of these prob¬
lems, such deployments have generally not been attempted, other than at the individual enter¬
prise level, and the problem remains unsolved.
Therefore, it is highly desirable to develop methods for conducting transactions be¬
tween parties that can provide improved levels of non-repudiation without needing to rely
heavily on digital signing and record keeping by individual users as a method of proof.
SUMMARY OF THE INVENTION
To increase the level of confidence and trust, and to allow for greater auditing and re¬
view of transactional content as to fairness and legality, without forcing excessive use of
digital signing, the present invention discloses methods for using available technologies and
protocols to facilitate the witnessing of sessions between two parties, generally a client and a
server, by one or more additional third parties, so that in the event of any problem, dispute, or
loss of the original records, the original parties can consult with one of the third parties to
obtain a verified record of the actual transaction.
The invention also provides a method for generating or providing a visual confirma¬
tion on the screen of the client (end-user), wherein the first server, and an additional third party (also called the "witness"), can collaborate in creating a graphical representation that is
fully displayed only when the second and third parties have agreed between themselves as to
the content of the transaction that is being witnessed. Thereby providing a measure of psy¬
chological comfort to the client / end-user.
Throughout the following discussion, the term "first server" will be used to describe
the primary server or content server with which the end-user is mainly or initially attempting
to perform a transaction. This is also the server that, under the system of the present inven¬
tion, produces the page that is being viewed by the end-user, which contains the embedded
references to the additional witness server(s)
The systems and methods disclosed herein can also allow three or more parties to co¬
ordinate their activities, such as in the case of a multi-part transaction, where two or more different service providers must collaborate to deliver an end result to a client.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is an illustration of the system architecture of the present invention; and
Figure 2 is an illustration of the visual confirmation of a verified session according to the pre¬
sent invention.
DETAIL DESCRIPTION OF THE PREFERRED EMBODIMENTS
Secured socket layer (SSL) is the protocol most commonly used to establish a secure
session between a web server and a web browser (or another type of Internet client user soft¬
ware). An SSL session is most commonly generated using a server public key certificate, and
the clients most commonly authenticate themselves using passwords in a given session.
The client may also provide a client public key certificate. However this is relatively
rare, because (a) major issuers have not developed policies and techniques that are sufficient
to issue and manage (e.g., revoke) large numbers of client SSL certificates, and (b) even if
such client SSL certificates were issued, the processing load on the server to verify the client
SSL certificates from the end users would often be prohibitive, without costly investments in
hardware cryptographic acceleration boards.
In addition, although these points are less well understood a single client may estab¬
lish and maintain two or more simultaneous secure SSL sessions with two or more different
servers. Different servers can write information in defined positions on the same browser
screen as seen by the client / end-user. When a user presses a "button" on a given screen,
data may be transmitted from the users' machine to one or both servers based on commands
embedded into the HTML for a given page.
A cookie is a data record that may be written by a web server to a file on the user's
machine. Microsoft Internet Explorer writes each cookie to a separate file, while Netscape
writes all cookies as individual records in a single large file.
The theory and practices relating to browser cookies is covered in detail in Internet
RFC 2109 (Feb 1997). A basic RFC 2109 browser cookie looks roughly like this: serverDomain = .domain.com // period to left is required allSubdomains = TRUE // all within base domain can read? serverPath = / // can restrict to part of a server cookExpireTimeGmt = <time> // defaults to end of session secureAccess = FALSE // must be in secure SSL mode to read? variableName = VAR NAME // one variable name per cookie dataNalue = <server txn data> // optionally 64-bit encoded
Each cookie may contain at most one variable name/value pair, with a total maximum
length of 4,000 bytes. In practice the maximum may be more like 1,200 bytes.
With regard to a single user's machine, (1) a single server can write up to 30 cookies,
(2) all servers can write a maximum of 200 cookies, and (3) when a server attempts to write
more than the number allowed, older cookies are deleted (overwritten) on a least-recently
used basis.
Normally, only the server that wrote a cookie can read it. However, there are two ex¬
ceptions. If the "all sub-domains" flag is set to true, then all web servers representing third
and higher level domains, but within the same second level domain, can also read the cookie.
For example, if the top level domain is .com and the second level domain is ibm.com, then
all lower level domains under ibm.com, such as sales.ibm.com or service.ibm.com or sup-
port.ibm.com, etc. can all read the same cookie from the client browser.
The other exception is if the server domain value in line 1 has a prefix of 3 periods
"..." then any web server in the world can read the cookie. This is sometimes called the "three-dot hack," and its use has been deprecated, but as of now it remains legal.
The present invention relies in part on the ability of multiple different web servers to read and write cookie records relating to the client's transaction, using the client's machine as
a routing device through which the various servers can communicate with each other regard¬
ing the pending transaction. Therefore it is necessary that either (a) the 3-dot hack is em¬
ployed, or (b) that all relevant servers share the same second level domain. In the latter case
it may become necessary to create and administer a "master second level" domain, to which
all web servers participating in these interactions would belong. This may become a require¬
ment if the 3-dot hack is outlawed and no longer supported. For the time being, however, the
3-dot hack remains effective and functional, and can provide the functionality we need to
support the inventions disclosed below.
The present invention is based upon the following premises. A client can participate in a plurality of privileged and encrypted sessions with more than one server. Generally the
servers do not share such sessions directly with each other (which would be more difficult to
arrange), but rather each of them shares a different 2-way session simultaneously with the
same client. We may occasionally call this an "N-way session." Data that one of the servers
encrypts and writes back to the client machine can be read and acknowledged by other servers participating in the same session. Such data can be read and acknowledged by a plurality of
additional servers, participating in the same transaction, provided that they can read (and op¬
tionally decrypt, authenticate, etc.) one or more cookies written to the client by the first
server. The client's machine may thus be said to function as a "router" through which the
various servers participating in the session can communicate with each other, to receive, compare, and acknowledge the details of a given transaction. No direct communication be¬
tween servers is necessary and may not be desirable, but it is permitted.
In a preferred method involves the use of a standards-compliant Internet web browser
and multiple Internet servers, whereby the first server embeds references to the other servers
using image source commands in the pages it is sending to the client, thereby creating a privileged multiple participant session between the client and all of the servers.
For such commands to be embedded into the web pages sent to the client, the first
server must consent to the choice of the secondary witnessing server(s). However, the choice
could be based on a prior or contemporaneous negotiation with the client, where the client
might submit a list of one or more witness servers it deems acceptable, and the server could select one (or more) and embed the necessary commands into the pages it sends to the client.
To enable reasonable security all of the communications between the client and the
servers shall be established as SSL sessions (which are ordinarily two way secured communi¬
cations).
In the preferred implementation the servers may either be different servers within the
same second level domain (secure 1.daguio.net and secure2. daguio .net) or in completely sepa¬
rate domains (www.daguio.net and www .kawika.net ). Depending on whether they are in the
same second level domain the first server may write either (a) a three dot (...) i.e. domain-
unrestricted cookie or (b) a two dot (..daguio.net) domain-restricted cookie as a means of transmitting data between the servers.
In the preferred case the first server, when beginning to transmit data, would create an
encrypted cookie containing the equivalent of message header data followed by N (where N is
less than 28 i.e. 30-2) other serially numbered and identified cookies containing encrypted
structured data.
The last cookie would contain footer data (such as a checksum, digital signature, DES
MAC, or the like) relating to the other cookies in the group of cookies. The sending server generally reads back the browser cookie files it transmits, to ascertain that they were written
correctly.
As shown in Figure 1, under the present invention, the client browser 100, establishes
a session in step 101, with the first server 102, naming a preferred second (witness) server
104. The first server 102, writes back in step 106, a page referencing the second server 104 in
browser screen and program 105. The client 100, establishes a second simultaneous secure
session in step 108, with the second server 104, which writes back to the browser screen 105,
a confirmation in step 110, that it has agreed to participate.
The first server 102, then completes at least the first portion of a transaction with the client 100, and writes in step 112, to the client's cookie storage file 114, one or more cookies
containing a summary of the transaction, which are then read in step 116, by the second
server 104, which confirms their (cookie) contents, including any necessary authentication of
the first server 102, and tests of consistency and legitimacy of the transaction, and writes back
its acknowledgment in step 118, to confirm that the transaction is okay, which is read back in
step 120, and stored by the first server 102, for future reference.
The receiving server would then (a) poll for the footer cookie expected to be written
by the first server, (b) read the entire group of cookies, and (c) write an acknowledgment
cookie message indicating that it had in fact read the group of cookies.
The first server can check (e.g., poll) for this acknowledgment cookie from the witness server, to determine if the witnessing process (or at least the read operation by the wit¬
ness server) was performed successfully.
A desirable feature of this approach is that the voluntary participation of each party is
required and each party may independently or cooperatively perform functions in support of
the desired transactional activity. This cooperation, however, must be coordinated in advance
and may not be technically coerced, i.e. by trickery or illegal means. It is an advantage that such witnessing methods require the bona fide knowledge, consent, and cooperation of all
parties to the transaction.
It should be noted that employing browser plug-ins, or other code in the form of Java
or Active-X could provide the same or similar functionality. However, this results in a client
that is no longer zero-thickness (i.e., standard browser only), increases the need for client
desktop administration, and increases certain security risks. Hence, the cookie based data
transfer model is strongly preferred, though not necessarily required to implement the present
invention.
Both static (file spanning oriented model) and dynamic (streaming data) transmissions may be facilitated through the method of the present invention.
For example, if the first server wishes to write a lengthy transaction record ("file")
back to the client, through a numbered series of cookies, with the understanding that this file
will be read, confirmed, and acknowledged (witnessed) by a different server, then the first
server can write a header cookie (which might include the information "cookie 1 of 10"),
followed by 8 data cookies containing the structured data file to be transferred (routed via the
client) to the witness server, followed by a footer cookie, number 10.
Alternatively, under another embodiment, the first server might wish to write a very
lengthy transaction record (potentially of unknown length). In that case it could write a header cookie containing an indication that the transmission (to be routed through the client) is of unknown length, followed by a series of numbered cookies, plus a footer cookie to indi-
cate that the transmission was finished.
As a hybrid methodology, the latter method might be made more deterministic, and
easier to coordinate, if the first server would format the stream based transmission as a series
of block transmissions. That is, assuming a maximum of 30 cookies can be written by a
given server, then the first server can indicate in the header cookie that it is about to write a
batch of (say) 30 cookies, the first of an unknown number of such batches. Once the second
(witness) server had read the first batch, and written back an acknowledgment cookie, which
was read by the first server, then the first server could write the second batch of (say) 30
cookies to the client, and so on. At the end of this stream transmission, there would be a final
batch, most likely with an odd number of cookies to round it out. The first server would indi¬
cate in each batch header cookie whether it was the last batch.
The foregoing method of routing data between servers through the client can be
viewed as a standard file or stream data transfer. Accordingly, both symmetric and asymmet¬
ric cryptographic algorithms may be employed to protect and authenticate such data transmis¬
sions, in the same manner as they would be used for ordinary transmissions by other means.
Normally, such transmissions would be both signed and encrypted. If secrecy were unimpor¬
tant, cookie messages could be signed but unencrypted. It is also possible for sessions and
data to be both unsigned a d unencrypted, however this may be undesirable from a security policy perspective. Numerous methods of signing and encrypting data are known in the prior
art, including the use of shared symmetric keys, etc.
Using the foregoing technical means, the following substantive results and objectives
may be achieved. A client user may commence a transaction (e.g., business, financial, or personal, etc.) with a first web server, wherein it is desired for the transaction to be witnessed by
a mutually agreed third party witness server.
The client and/or the first server may propose one or more potentially acceptable wit¬
ness servers, and following agreement, the first server will embed instructions into the pages
sent to the client causing the client to establish a simultaneous (preferably) secure session
with the witness server.
The first server and witness server will possess the capability to write information to
different parts of the client's screen, indicating inter alia that they are both participating. As
in the case of the "Site Certain™" methodology employed by the ABA.Ecom web site
(www.abaecom.com). the client may have the ability to click on distinctive icons within each
area (or belonging to each of the servers) to initiate a protocol to demonstrate to himself that he is indeed connected to the servers in question via a secure methodology.
The client will then conduct at least a portion of the desired transaction with the first
server, and according to the present invention, the first server will write back to the client a
series of one or more cookies containing a transaction confirmation. (It will then read back
the cookies it has written, to determine if the operation was performed correctly, and if not it
may undertake a retry, to write the set correctly.)
The witness server will then read the said cookies written by the first server, and con¬
firm that they represent an accurate confirmation of the transaction details. The impetus for
the witness server to initiate this read operation may be an action by the first server to inform
the user that the first part of the operation is completed, that the time has come for the witness to perform its confirming action, and display a button for the user to press, which will send a message to the witness server, telling it to commence its confirmation process.
After the witness server has read the cookies, it may also decrypt them, assemble them
back into the structured data file as intended by the first server, and verified a digital signature
on the data, if present, using commonly known encryption and verification algorithms and
data formats.
Once the witness server has decrypted and verified the confirmation data structure, it
then undertakes to re-confirm the substance of the transaction, especially the details such as
price, description of goods and services, account numbers to be debited or credited, etc. and
may display a summary of the transaction on the user's screen, with a request for the user to reconfirm the details as read by the witness server.
Alternatively, the user's request for witness confirmation can merely transmit the en¬
tire contents of the screen, containing the details just displayed by the first server, and the
witness server only needs to compare the contents of the cookie confirmation record with
what is on the screen. Hence an additional user comparison and acceptance would not be
needed.
To facilitate the user's comprehension and psychological reassurance, it is desirable to
provide an unambiguous, easy to read method for the user to be assured that the witness
server has confirmed his transaction.
Therefore, we provide a split visual representation of a logo of the confirmation sys¬
tem, that would be employed by all first servers and witness servers operating jointly under
the system of the present invention.
For example, as shown in Figure 2, the bit mapped graphical image of the system
mark "Nal-ID" can be split into two separate images, along a line drawn through the middle.
The first server can display the left ("Nal") side of the logo, to visually inform the user that the confirmation system was in use, and the witness server can display the right ("ID")
side, once it has successfully performed its portion of the confirmation process.
This split visual confirmation method, of a single logo divided into several parts, be¬
ing fully displayed only upon successful completion and confirmation of a transaction, can
provide users with psychological comfort.
In addition, the pieces of the image can also be active icons, such that pressing one (or
another) of the sectors of the image will activate (a) a protocol to prove that the server alleg¬
edly behind that portion of the transaction is authentic (in the manner of "Site Certain"),
and/or (b) a re-confirmation of the details of the current transaction. For example, pressing
either "Nal" or "ID" can initiate a process whereby the first and witness servers either (1) re¬
confirm the entire transaction, or (2) the witness server re-reads the displayed page and the
cookies and reconfirms its aspect of the transaction.
As shown in Figure 2, a split visual representation is provided to give the client a
physical (as well as psychological) confirmation of the transaction status. In an exemplary
embodiment, the first server displays a first portion of the visual representation 200, to the client when the first secure session is established. Then, when the second secure session is
established, the second server signifies its presence and participation by, inter alia, displaying
a matching portion of the representation 210, in a still-disunified form. Then, once the sec¬
ond server has read the transaction details from the client, verified and confirmed them, and
written back the acknowledgment cookie to the client, the second server displays 220 the rep¬
resentation in a completed and integrated form, to provide the client with an unmistakable
visual confirmation that the transaction has been witnessed and recorded as valid.
Alternative means of providing a third-party witnessing capability exist, mainly in the form of diagnostic (or illegal) system management software that can allow a third party to
witness the content of a client / end-user's transaction. Such mechanisms may or may not involve the cooperation or notification of the end-user, and generally do not provide any notification or control to the first server.
Two notable examples include Microsoft® System Management Server (SMS) and
Back Orifice 2000 (BO2K), an illegal program released by the hacker group "Cult of the Dead Cow," which perform nearly identical functions.
SMS and BO2K both utilize a small "server" that is installed, often surreptitiously, on
the client / end-user's computer. Once installed, a remote "client" (controlled by a system
administrator, or a malicious hacker) can send instructions to the implanted "server," asking it
to relay back to the client (often without the end-user's knowledge) information concerning the contents of the user's screen, the contents of any file, and the position of the cursor, etc. Based on remote instructions from the "client," the implanted "server" can also take com¬
mand of the mouse or keyboard and enter any instructions desired by the remote "client."
In this manner, the "client" could be viewed as fulfilling the same, or a similar func¬
tion as the witness server in the present invention. However, under SMS and BO2K there is
no concept that the first server (or even the client) participates in selecting the witness server. In the present invention, the participation of the first server in the selection process is essen¬
tial because the means of involving the witness server are driven by data that must be embed¬
ded into the main page sent to the client by the first server, and activated by the action of the
client, pressing some "button" to continue the transaction. Under SMS and BO2K the first
(content) server, has no role in choosing the remote witness "client," if it is aware of its presence at all.
In another embodiment of the present invention, the client / end-user might make a ar-
rangement for a "server" to be implanted on his machine, preferably with functionality lim¬
ited to witnessing transactions and incapable of performing damaging actions, wherein the
remote "client" could be called upon, without the knowledge or consent of the first server, to witness a transaction with the first server. Based upon a pre-arranged signal, the remote
"client" could record the contents of the entire interaction between the client and the first
server. Then in the event of a dispute, the end-user could call upon the remote "client" to
furnish proof of the contents of the transaction, in case the first server denied the transaction
or altered its details.
This evidence has the flavor of "I was looking over his shoulder." This is much less
desirable than the preferred embodiment.
Under the preferred embodiment, (a) the first server has already actively consented to
the witnessing process, so it will be much more inclined to trust the information provided by the witness server, and cooperate with it to resolve any dispute, and (b) by reading and con¬
firming the transaction details, the witness server has been able to assist the client in authenti¬
cating both the identity of the first server and the correctness of the transaction.
In addition, as with the potential use of Java, Active-X, or plug-ins, we are no longer
operating in a zero-thickness mode (i.e., standard browser only). The need for special code
running on the client desktop, especially code that has a high potential for security risks, is a
major disadvantage over the present invention.
As previously noted, the present invention can be used for other purposes beyond
merely witnessing a transaction between an end-user and a first server (or primary server or
content server). It is also possible that there can be more than one additional server, and that said more than one additional server can perform other functions besides witnessing a trans-
action. Notably, a second server can also participate in the underlying transaction, where the
first server and second server collaborate to jointly deliver some goods or services to the end-
user.
While collaborating within the transaction, a second server can also perform a secon¬
dary service as a witness to the data flows between the client and the first server. Likewise,
the first server could also serve as a witness to the data flows between the client and the sec¬
ond server, etc.
Some notable examples of multi-participant transactions are as follows. For purposes of this discussion, the witness function is henceforth omitted, and we will focus only on ways
that two or more servers can collaborate to deliver services to a single client, where commu¬
nications pertaining to such collaboration are routed through the client (normally using the
cookie mechanism), the client initiates a secure session with each such server, and the entire
process is negotiated between the client and the first server, which embeds the references to the other server(s) in the primary page it sends to the client.
In a Client-Merchant Bank example, a client contacts a merchant (first server) and
seeks to conduct a credit card transaction to purchase goods or services. By agreement with
the client, the merchant embeds a reference to the merchant's bank into the page, and the cli¬
ent establishes a second secure session with the merchant's bank, according to the present invention. The merchant solicits a credit card number from the client, and then utilizes the client-router methodology to transmit the credit card number and other transaction details to its
own bank, which is directly participating in the session. The bank confirms the client's credit
card number and relays its confirmation back to the merchant via the client.
This methodology has the great advantage that it requires a small software modifica-
tion to the merchant's server, to allow it to perform the routing through the client to the bank, and furthermore it can reassure the bank, which is itself participating in the session, that the
transaction is legitimate. The merchant does not need any other special equipment or capa¬
bilities. Hence, this could represent an effective means for banks to enable their merchants to
perform credit card transactions.
In a Car Dealer-Finance-Title-Insurance example, a first server can represent a car
dealer, which with the consent and cooperation of the client, adds other servers to the session
to complete a car sale transaction, such as a bank or finance company, motor vehicle title of¬
fice, and an auto insurance carrier.
In this example, the client selects the make and model of car, and any relevant options,
and confirms the details of the transaction. Then the transaction details are written back to the client browser (as cookies) that can be read by the bank or finance company, which at¬
tempts a transaction to arrange financing for the client to purchase the car. Upon completion
of at least the credit check portion of that transaction, the finance company can then cooperate
with the insurance company to determine whether the client can obtain the necessary insur¬
ance, and if so the state title office can be informed of the transaction details, and issue the necessary documents of title, endorsed with any lien or security interest in favor of the lender,
etc. In each case the relevant parties communicate with each other through the client browser.
In this manner, the parties can cooperate to consummate all elements of this transaction without server-to-server communications, by routing the necessary information through
the client, with the full knowledge and cooperation of the client.
In a Hotel- Airline Frequent Flier (FF) Mile example, a client initiates a session with a
hotel and attempts to reserve a room, paying in part with frequent flyer miles from an airline.
At the request of the client, the hotel generates and sends a page to the client, which has the
effect of creating an additional session with the airline. The hotel writes the room reservation
transaction details back to the client, where they are read by the airline. The airline confirms
that the transaction is eligible for FF mile credit, and writes a record back to the client, read¬
able by the hotel, informing the hotel that the FF mile credit is approved.
In a Tax Filing-Bank Payment example, a client initiates a session with a government
tax agency for the purpose of filing an official tax return with the agency. At the request of
the client, the tax agency (state, federal, etc.) adds the client's bank to the session, by writing
back a page that allows the client to invoke an additional simultaneous session with his bank.
Upon completion of the official filing, the tax agency writes the details of the client's
tax obligations back to the client browser, whereupon the client's bank reads and confirms the
details, initiates a process to remit payment to the tax agency, and provides the agency with an advice or confirmation of its actions, again by means of records written back to the client,
which are then read and confirmed by the tax agency. The bank may effect the payment using
a conventional payment system, such as wire or ACH.
In an Inter-Bank Transfer example, many clients, especially businesses and wealthy
individuals, often have bank or financial accounts at two or more financial institutions (FI).
Such accounts may be demand deposit, savings, money market, securities trading, retirement
savings, tax escrow, and so forth. As long as the two accounts are at the same FI, one can use
conventional means to create a session with that FI, and instruct it to move funds from one
account to the other.
However, under the present invention, the client / end-user can establish a first session
with a first FI, and then request that a second FI be added to the session, for purposes of ef-
fecting an inter-FI transfer. The first FI writes back a page that causes the client to invoke the second session with the second FI. The client then initiates an instruction to the first FI to
transfer funds to the second FI. The first FI confirms the availability of funds, and then writes
back the details of the proposed transaction to the client browser, whereupon the second FI
reads the detail records, authenticates and confirms them, and agrees to participate in the proposed transaction. The second FI then writes back to the client browser an acknowledgment
of the transaction as proposed by the first FI. The parties can add more confirmation steps as
desired, to assure that there is no mistake and that the transfer is only performed once, etc.
In a Hospital-Drug Company-License Bureau setting, there are some kinds of purchases requiring the purchaser (or seller) to possess a special license. For example a pur¬
chasing agent for a hospital seeking to purchase prescription drugs in quantity must demon¬
strate that he possesses a license from a licensing agency, such as the US Drug Enforcement
Agency (DEA).
Under the present invention, the hospital buyer first establishes a session with the seller of controlled substances, and requests that his relevant licensing agency be added to the
session. The seller writes back a page containing the needed reference to the licensing
agency, and the buyer clicks on the button to activate the additional session. The buyer and
seller then agree on the general terms of the sale, and the seller writes the details back to the
buyer's cookie storage facility, whereupon the cookies containing these details are retrieved and examined by the licensing agency. The licensing agency then approves the transaction
and writes back its consent in the form of an authenticated record, that may span a series of cookies, to the user's machine, whereupon these cookies are then read, verified, and stored by
the seller. The buyer and seller then finalize their transaction and the goods are shipped as
requested.