Authenticated payment

[0001] Technical field to which the invention belongs The present invention relates to authenticating a buyer (buyer) in an online commerce, and particularly to having a separate authentication service to authenticate the buyer. [0002] The invention is prioritized by US Provisional Patent Application No. 60 / 198,110, entitled Authenticated Payment by Greg Whitehead, Michael Graves, and Thane Plambeck, April 17, 2000. The subject matter of this application is included here for reference. [0003] Conventional technology Here, the background technology is described. Online commerce has become a major business as a result of the increasing popularity and acceptance of the Internet and other forms of networked communications. For example, the amount and volume of consumer purchasing, inter-business transactions, stock trading and other forms of investment that occur on the Internet and / or wireless networks is constantly increasing, which is the other form of online commerce. Similar to form. In addition, considerable effort has been put into other business models (such as auctions and group purchases) and other forms of payment (e-cash and transfer of funds approved on the internet (fund transfer)). Attempts have been made to develop and take advantage of the unique characteristics of online commerce. [0004] Problems to be solved by the invention However, one of the drawbacks of online commerce is the difficulty of authenticating the buyer. For example, suppose a consumer wants to use a credit card to purchase an item (an item, which in this case includes a service). If this buyer were doing this in the real world, he would present his physical (tangible, physical) credit card (perhaps with a photo on the card). You will be required to sign a credit card slip (slip) with a signature that matches what is on the credit card. These actions serve two important purposes. First, the action is to set some certainty that this buyer has the authority to use that credit card (approval has been granted), and second, the buyer later It is to create a record that makes it difficult to deny that you have approved the purchase. Both of these factors significantly reduce the risk of fraudulent (fraudulent) transactions. [0005] In the online version of this transaction, there is no action that supports presenting a physical credit card and signing a credit card voucher, and if any, it is dangerous (risk). ) Is not effective in reducing. For example, in many cases, the buyer is simply required to type in the person's credit card number and then click on the buy (make purchase) button. These two actions are more vulnerable to fraud than the corresponding actions in the real world, because the seller has the actual authority to use the credit card. I don't know if I'm there. In other words, it is difficult for the seller to authenticate the buyer. Moreover, even if a genuine credit card owner approves the transaction, there is an increased risk of fraud that the records left are not as strong. The reason is that credit card owners can claim that the fraudster has approved the transaction. This Card not The additional risk of fraud in the present) state raises higher exchange rates and fees for transactions processed on the Internet and other commerce systems, perhaps one to the cost base for Internet commerce. It will be the one that brings the greatest single contribution (contribution) (contributor). [0006] One of the reasons why the Internet and other online frauds have grown is personal payment securities (personal payment instruments, instruments mean tools. In the financial sector, they refer to legally effective documents. It is normal, and here it is not translated as a tool, but translated as securities according to the example of the financial sector), credit card number, check issuing account (checking account) number, And related data are essentially "public information" and are open to the public in the sense that this data is immediately available. For example, a consumer would give each online merchant each transaction in an unprotected format, such as his credit card number and expiration date. In addition, information such as name, address, social security number, etc. will be available from sources other than the cardholder. For example, a searchable, web-accessible telephone number book (directory) or other directory can contain much of this form of information. Repeated, unprotected disclosures of payment securities information, combined with the fact that much of this information is available from other sources, increases the risk of fraudulent transactions. For example, mint often only needs to capture a database of credit card numbers and their associated name and address information, thereby making them like real cardholders in many online trading environments. Try to put on a mask. [0007] Conveniently, buyer authentication systems are working on the practices commonly used in Internet (web) commerce environments through the use of passwords, where buyers typically use simple user names and passwords. Authenticates itself. As mentioned above, passwords have inherent weaknesses for use for this purpose, and current practices exacerbate these weaknesses. For example, consumers generally have to register individually with each merchant using an online process. As a result, the merchant has only a limited opportunity to confirm the consumer's registration, because it does not allow confirmation that the timing of online registration is sometimes meaningful, if any. The cost forbids it because each merchant has to bear the cost of his own confirmation. In addition, consumers will often use the same user name and password for multiple accounts. This increases the chances that the username and password will expose the secret to the enemy, and if exposed, the damage that can be incurred. In addition, the username and password are generally transferred to the merchant in clear text, so an unfaithful merchant can also use this information to know the secret of another consumer's account. As a final example, many current authentication systems aim at a consumer's identity (identifier, ID) -for example, to prove that the person actually John Doe is the user-but someone's identifier. Authenticating does not necessarily have to be the same as verifying someone who is authorized to use a particular payment certificate. [0008] The Secure Electronic Transaction (ie) protocol is an attempt to address buyer authentication issues in order to function for secure card transactions over the Internet. SET uses digital certificates to create a chain of credit (trust chain) throughout the transaction. For example, a consumer will have a digital certificate (book), which the consumer presents to the merchant. The merchant will have a digital certificate (book), which the merchant presents to the consumer. Each confirms the digital certificate (book) of another person and the chain of digital certificates (book) placed in it to determine that it is credible (trustworthiness). However, this approach imposes considerable administrative and also operational complexity on consumers and merchants and the corresponding transaction processing information. For example, both buyers and merchants are required to specialize in technology and become involved in the protocol, and each time a new digital certification technology is adopted, it is necessary to upgrade the technology. As a result, SET was not widely adopted. [0009] In this way, there is a need for fruitful buyer authentication in online commerce. In addition, there is a need for ways to authenticate buyers, which are also flexible enough to easily adapt to varying levels of security for different applications, and are easy to adopt new technologies. It shall be flexible enough to adapt to. It is also preferred that this approach imposes a significant burden on the existing transaction processing infrastructure and does not require significant changes. [0010] Means to solve problems According to the present invention, the online commerce system (100) includes a buyer (110), a seller (120), and an authentication service (130). Authenticate to the seller (120) that the buyer 100 is authorized (authorized) to use the payment securities (tool) as part of an online transaction with the seller (120). Is desired. To do this, the authentication service (130) performs the following steps, all of which occur in real time as part of its online commerce. The authentication service (130) receives a request to confirm that the buyer (110) is authorized (authorized) to use the payment securities (tool). The service determines if the buyer (110) has access to certain confidential information without disclosing the confidential information to the seller (120). Access to this confidential information confirms the authority to use payment securities (tools). In response to determining whether the buyer has access to confidential information, the authentication service (130) sends a response (250) to the seller (120), in which the buyer (110) pays the securities. Includes whether you have permission to use (tool). In another aspect of the invention, the authentication service (130) also applies profile information about the buyer (110) to online commerce and / or multiple processes (270) (260), or at least in part. Process payment operations. The authentication service (130) can also store (280) records of the use and / or transaction of payment securities. [0011] Embodiment of the invention In preferred embodiment (300), online commerce occurs on the Internet. The buyer (110) accesses the Internet via a web browser, and the seller (120) operates the Internet storefront (in front of the store), which is hosted by a web server, and an authentication service (120). 130) is implemented on the web server. [0012] In addition, confidential information contains private (private, public (public) opposite) keys. In other words, creating a digital signature using a private key is a testament to the signer's authority to use the corresponding payment security (tool). In this embodiment, the request for authentication (330) is triggered by the submission of a form (form) (400) by the buyer, which form contains an action attribute that identifies the authentication service (130). I'm out. The request to the authentication service (130) also includes the seller's address, so that the authentication service knows where to send the results of the authentication process it has done (350). To authenticate the seller (120), the authentication service (130) sends a call request (challenge request) to the buyer (110) (340) and the buyer (110) digitally signs some data. Ask to use a private key. The authentication service (130) uses the buyer's response (342) to determine if the buyer (110) has access to a private key (346) and then sends the result to the seller (120). .. The authentication service (130) may further require that the buyer (110) digitally sign the transaction record, thereby creating a strong record of the transaction (380). [0013] The invention is particularly favorable because a separate authentication service (130) is used to authenticate the buyer (110) rather than the seller (120). As a result, the seller (120) does not gain access to the confidential information associated with the buyer's payment securities (tools). This prevents the seller (120) from reusing this confidential information to authorize fraudulent transactions. [0014] Furthermore, the concentration of authentication functions in authentication services provides significant flexibility and economies of scale. Many forms of confidential information are appropriate, and each requires different techniques for implementation. Centralizing the authentication function in the authentication service (130) allows the cost of the required technology to be shared among many sellers (120). Moreover, or if the format of the confidential information or the corresponding buyer authentication process changes, this chunk of change only affects the authentication service (130) and thus new authentication technologies can be easily implemented. To do so. If the authentication service (130) performs other functions such as adding buyer profile information to transactions, processing payment securities (tools), or keeping transaction records, it adds to the scale. The economics of this is realized because the authentication service (130) is a natural focus on these other features. [0015] Example Hereinafter, in the present specification, the above-mentioned, another more detailed, specific object and feature of the present invention will be described with reference to the accompanying drawings. FIG. 1 is a block diagram of the system 100 according to the present invention. System 100 includes a buyer 110, a seller 120, and an authentication service 130, which communicate with each other. System 100 also optionally (optionally) includes Directory 140 of the authentication service, which is accessible by Buyer 110, and also includes Database 150 of Buyer Profile and Transaction Logs (Transaction Archive) 170. , Both are made accessible by the authentication service 130. The optional payment gateway 160 is also made accessible by the authentication service 130, and in an alternative embodiment this may be the seller 120 or both the authentication service 130 and the seller 120, and these Is supposed to access the payment gateway 160. The payment gateway 160 is simply a conduit through which payment transaction operations are sent to each financial institution. The present invention is intended to allow a number of different forms of payment gateway 160 (or one without a payment gateway) to be used together and is not intended to be limited to a special form of gateway technology. [0016] Buyer 110 wants to use payment securities as part of an online commerce with seller 120. For example, in one application, the buyer 110 is a consumer and the seller 120 is a merchant at the Internet storefront, a product, information, or service for which this consumer is using his or her credit card. Want to buy from the merchant. In another example, the buyer 110 is an individual, who is connected to the seller 120 via a radiotelephone or personal digital assistant (PDA) on hand, and the seller 120 is a bill payment service. , Wants an individual to write an "Internet check" to pay for his or her monthly bill. In yet another example, the buyer 110 is a company or individual who works on behalf of a company that purchases materials or services from the company's supplier 120. Other examples of payment securities (tools) are Checking account routing numbers, virtual money, or electronic cash displays, and prepaid cash values stored in an electronic wallet. Includes purchase cards (purse cards), and internet credits or coupons. [0017] What is clear from these examples is that many other applications are possible, and the terms "buyer" and "seller" are used as expedient labels. The meaning is not limited to these entities. The "buyer 110" is not required to actually buy something, and the "seller 120" is not required to actually sell it. Similarly, "online commerce" is not limited to the trading business of buying and selling. Rather, instead, online commerce can be any transaction, where buyer 110 wants to use payment securities (tools, instruments) as part of the transaction business, or more generally. , Suppose you want to use payment securities as part of a transaction that would benefit from the authentication of Buyer 110. As an example of an application that does not use payment securities, the "buyer" 100 is an individual and the "seller" 120 is an insurance company, which means that the buyer has a policy and "transactions". ) May be that the buyer wants to change his or her trust, pension, etc. The seller first wants to authenticate the buyer's identity before allowing access to the buyer's account. [0018] FIG. 2 is an event tracking diagram (event tracing) showing the operation 200 of the system 100. Method 200 is broadly divided into three main parts. Buyer registration 202, buyer authentication 204, and recording transaction operations 206. Not all practices utilize all three stages 202-206, nor do all of the individual stages shown in FIG. 2, but these are to show the various features (aspects) of the invention. It is included in this example. In buyer registration 202, confidential information will be used in step 204 to authenticate the buyer, and payment securities will be set up between the buyer 110 and the authentication service 130. Buyer registration 202 preferably occurs only once for payment securities. Buyer approval (authorization, authorization) 204 occurs in real time as part of an online commerce. At this stage, the buyer 110 actually accesses (demonstrates) the confidential information for the authentication service 130. If this access is successful, the authentication service 130 informs the seller 120 that the buyer 110 has been authorized to use the payment securities. At stage 206 of the transaction record, the authentication service 130 creates a record of the transaction, which is later used as evidence to testify whether any transaction has occurred. [0019] The use of the individual authentication service 130 has many advantages. For example, as will be made clearer from the following description, the bulk of the buyer authentication process 204 is performed by the authentication service 130. The authentication service 130 determines whether the buyer 110 actually gains access to the confidential information and thereby is authorized to use the payment security. Buyer 110 is made to be minimally involved, and seller 120 is essentially uninvolved. This concentration of functionality in Authentication Service 130 provides significant flexibility and economies of scale. For example, different forms of confidential information, ranging from simple PINs (personal identification numbers) to highly advanced and complex digital proof protocols, can be used to create different levels of security for different payment securities. Different forms of confidential information will require different infrastructure to perform buyer authentication step 204. Centralizing the buyer authentication stage 204 within the authentication service 130 allows the cost of this infrastructure to be shared among many sellers 120. Furthermore, if the confidential information or the corresponding buyer authentication process is changed, the mass of changes will affect only the authentication service 130, making it easier to implement new authentication technologies. .. In contrast, it's a way like the previous SET, which requires each seller to have most of the infrastructure needed. This leads to high costs, slow initial adaptation and difficulty in switching to new technologies, which ultimately lead to the failure of SET and similar practices. [0020] This approach is also convenient because the seller 120 may not gain access to the buyer 110's confidential information and the seller is not involved in the buyer authentication 204. This authorizes fraudulent transactions and prevents the seller 120 from reusing the confidential information of the buyer 110 later. For example, suppose the secret information is a PIN number. If the seller 120 was responsible for the buyer's authentication 204, the buyer 110 would disclose his PIN number to the seller 120, which could later be used for illegal purposes. However, in the current practice, the seller 120 only discloses the PIN number to the authentication service 130, not the seller 120. [0021] [0021] Seeing FIG. 2 again, each of the dashed boxes 110, 120, 130 represents one of the components within System 100. The solid box represents the various stages within Method 200. The position of the solid box within the dashed box indicates that the steps are generally performed by these components. For example, stage 210 is placed inside a dashed box for authentication service 130. This indicates that the authentication service 130 generally performs step 210. A stage has two boxes, which indicates that the stage occurs on two components. For example, one component can send a message to another. These steps are often performed by software running on various components inside the system 100, and the system is probably assisted by hardware modules. This can also be done in hardware and / or firmware. [0022] Buyer registration stage 202 should occur prior to the actual online commerce. At stage 202, confidential information is set up between the buyer 110 and the authentication service 130. Information is confidential in the sense that it is ideally known and / or accessible only by the buyer (or, if it is a secret shared by both buyer 110 and authentication service 130). Is. It is generally not available to the public or by seller 120. In addition, this confidential information corresponds to a particular payment security, and proof of access to the confidential information is done as an authorization (authorization) to use the payment security. [0023] Different forms of confidential information may be used depending on the required form of security. Examples of confidential information are localized to PIN numbers and passwords, network-stored credentials (eg, to support roaming), "roaming" digital signing capabilities, and buyers' machines. Software credit certificates (credentials) such as private keys, private keys on hardware tokens or smart cards, biometric credit certificates, and cryptographic call (challenge) response protocols Contains information used in. [0024] In the specific example of Figure 2, the confidential information is set as follows: Authentication service 130 receives confirmation information (210), which allows the buyer 110 to later determine if it has access to confidential information. The authentication service 130 then stores this confirmation information, which is related to the payment security, as, for example, as part of the buyer profile database 150 (212). In one embodiment of this model, the buyer's confidential information is the private key, and the corresponding confirmation information is the corresponding public key. [0025] In another embodiment, buyer registration is carried out in a different way. For example, the confirmation information does not have to be stored in the authentication service 130. Instead, it is stored elsewhere and recovered (searched and read) by the authentication service 130 when needed. Instead of storing confirmation information that is different from confidential information, the authentication service 130 can simply store the confidential information itself (for example, a password or a password hash (with a booth)). Remember things). In another example, buyer registration 202 may occur offline instead of online. For example, buyer 110 fills in an application (form) and sends it to the bank. The bank confirms the information on the application (form), issues a credit card to the buyer 110, and sends the account information to the authentication service 130. The authentication service 130 creates a smart card, which contains the embedded confidential information, and the smart card is sent to the buyer 110, for example, via a postal service. Note that in this last example, Buyer Registration 202 takes advantage of the credit card enrollment process. Buyer registration may also take advantage of other processes. [0026] Confidential information is preferably generated by Buyer 110 to minimize disclosure to other parties. However, in another embodiment, confidential information may be generated and / or shared by other parties, such as when the authentication service is to another party, especially when the risk posed by such party is considered small. To be done. [0027] At buyer authentication stage 204, buyer 110 wants to use the payment securities as part of an online commerce with seller 120. Authentication service 130 determines in real time whether buyer 110 is authorized (authorized) to do so as part of the transaction. Buyer 110 proposes to use payment securities (220). For example, buyer 110 offers to pay for a purchase using a credit card. [0028] Seller 120 wants to know if the buyer is authorized to use the payment security (tool) and sends a request to authentication service 130 to confirm the buyer's authority (230). Depending on the payment securities, the identification of authentication service 130 may not be immediately revealed. There may be multiple authentication services. For example, each credit card company will provide its own authentication service. One way to solve this problem is to have Directory 140, which associates the authentication service with the payment securities. In this case, the seller 120 accesses the directory 140 to determine which authentication service is appropriate for the payment securities presented by the buyer 110. [0029] The authentication service 130 determines in stages 240-246 whether the buyer 110 has access to the confidential information. Authentication service 130 sends a challenge request to buyer 110 (240). The call request seeks proof that the buyer has access to confidential information. For example, if the confidential information is a password, the call request may ask for this password. If the confidential information is a private key, the call request may require the buyer to digitally sign something with that private key. In one embodiment, the call request also includes a description of the online commerce, allowing the buyer to stop the transaction, eg, when the description does not match the buyer's expectations. .. Similarly, the call request may instead seek the buyer's consent for the transaction. If buyer 110 wants to move forward, he sends a "call response (challenge response)" back to authentication service 130 (242). [0030] The authentication service 130 searches and reads the confirmation information about the payment securities stored in the early stage, and uses this confirmation information and the call response to determine whether the buyer 110 has access to the confidential information. For example, in the password example embodiment, the authentication service breaks the transmitted (allegged) password from the call response and compares it to the boot break stored as confirmation information. In the example of the private key example, the authentication service 130 uses the public key stored as confirmation information and really uses the private key that the digitally signed message in the call response corresponds to. Determine if it has been digitally signed. [0031] The authentication service 130 then sends a response to the seller's original request to the seller 120. This response includes whether Buyer 110 is authorized (approved) to use the payment security. It can also contain additional information, which will be described under the circumstances of stages 260 and 270. Note that during Buyer Authentication 204, no confidential information is shown to Seller 120. [0032] Before moving on to stages 260 and 270, it should be noted that what is shown in Figure 2 as certification stages 240-250 is just one way to implement buyer certification stage 204. Other implementations will be obvious. For example, authentication service 130 can receive a request for authentication from buyer 110 (230) rather than from seller 120. In another example, authentication service 130 may not use call request 240 and call response 242. Proof of access to Confidential Information may instead be included as part of Initial Request 230. In addition, as mentioned in Phase 202 of Buyer Registration, Authentication Service 130 uses methods other than Confirmation Information (Stages 244 and 246) to determine if the Buyer has access to Confidential Information. You may judge. [0033] Returning to FIG. 2, in one embodiment, the authentication service 130 can also apply additional buyer profile information to the transaction. For example, seller 120 may require that the buyer's shipping address be added to the transaction business. Authenticate service 130 Search and read this information from database 150 and add it to the ongoing transaction. This additional information can be added at various points during the transaction and may include communication with either the buyer 110 or the seller 120. For example, within the shipping address, the buyer 110 may be required to confirm this address, and / or the seller 120 may also use this address to calculate the shipping charges, which charges are further ahead. It will be converted into a dollar amount for trading operations. [0034] Similarly, the authentication service 130 can also process (270) payment transaction operations, for example via the payment gateway 160. In one extreme process, the authentication service 130 simply notifies the seller 120 (250) and the buyer 110 is authorized to use the payment security, while the seller 120 is required to process the payment security. Inform them to take all steps of. In other extreme processes, it may be the authentication service 130 that performs the steps to process the payment transaction operation. In the middle case, Authentication Service 130 will perform several steps to allow the buyer to complete others. [0035] Both buyer profile formation 260 and payment processing 270 are attractive because authentication service 130 is a natural focus on these activities. Looking at the actual certification stages 240-246, the economics of the scale may be realized by having the certification service 130, where the certification service performs these functions rather than each individual seller 120. [0036] At the transaction record stage 206, the authentication service 130 stores the transaction record in the transaction record document (transaction archive) 170 (280). The credibility of this record will depend on the particular application. As an example, the authentication service 130 may simply memorize the plaintext description of the transaction operation. In another example, a digitally signed and time stamped record would be more appropriate. Continuing with the password example above, a digitally signed record may be created by having an authentication service that digitally signs the record using its own private key. In the private key example, the buyer 110 itself creates a digitally signed record of the transaction business using his own private key. In both of these examples, the result is a permanent, digitally signed record of the transaction, which can be used by Buyer 110, Seller 120, or another party to resolve a dispute about the transaction. It is a thing. [0037] 3-9 are preferred embodiments of System 100 and Method 200. In the Internet embodiment, online commerce occurs on HTTP application systems, especially on the Internet. Buyer 110 uses a regular web browser to access the Internet. Seller 120 is a merchant who operates the front of a website store (storefront) on the Internet, in this case the virtual Pete's Soccer Emporium. The front of the store runs on a regular web server. Authentication service 130 also provides an interface to the Internet via a web server. Buyer 110 wants to use his credit card as a payment security to buy a particular cup (the Adidas Ept. Predator Accelerator Cup) from Pete's Soccer Emporium. Confidential information used to secure transactions is a private key associated with payment securities. For convenience, this embodiment is an Internet embodiment, but does not mean that this embodiment is the only possible one for the Internet. [0038] FIG. 3 is an event trace (trace of an event) and shows the operation of the Internet embodiment. Like Method 200, Method 300 can be broadly divided into three main parts. Buyer registration 302, buyer authentication 304, and keeping a record of transaction operations 306. However, the buyer certification 304 and the record 306 are intertwined with each other. [0039] In the buyer registration phase (phase) 302, the buyer 110 sets the person's "account" with the authentication service 130. In this case, it means that any offline investigation will be conducted, for example, receiving confirmation from the credit card company that the buyer 110 is authorized to use the credit card. In addition, a combination of private and public keys is generated for that account and the public keys are stored in the authentication service database 150 (312). In a preferred embodiment, the public key is stored in the form of a digital certificate (book), which indicates that the public key is linked to the buyer's account. [0040] In this embodiment, the account and key pair are linked to a large number of payment securities and include a particular credit card that will be used for proof of payment. In other words, the digital proof and key pair is about the buyer's "wallet", which contains a number of payment securities (tools), not for one particular payment security. Absent. However, other embodiments may use different schemes, such as using different account and key pairs for each payment security. In addition, the buyer may have a large number of accounts and key pairs. In this embodiment, the buyer's private key and the associated public key infrastructure (PKI) service are managed by the software agent for the buyer 110, especially the VeriSign Personal Trust Agent. It is managed by (PTA). This PTA has a general-purpose key and a certificate (book) management function, and is designed to be easily incorporated into web applications. [0041] VeriSign PTA manages the buyer's PKI credential. For example, if the buyer 110 does not have a digital certificate (book) or key pair, the PTA will incorporate the buyer 110 into the certificate registration (enrollment) page. If this buyer's digital certificate expires soon, the PTA advises buyer 110 to renew the certificate before continuing and to bring buyer 110 to the certificate renewal page. Similarly, if the buyer's certificate has already expired, the PTA offers an option to go to the certificate renewal page to renew the expired certificate. All of this can be done with matching sets of dialogs across different browsers. In addition, while this particular embodiment uses a browser, the PTA also favors other devices, including wireless phones and personal digital assistant associations (PDAs) on hand. .. [0042] PTAs and private keys can be hosted (accessed) in many places. In this example, a separate server (not shown) hosts the software performing the PTA and remembers the corresponding private key. One advantage of this approach is that the PTA and private key are implemented as a zero client, hosted service, so no changes are required to the buyer's browser. Is. Another advantage is that the buyer's browser does not require any specific software, so the buyer 110 can potentially access the PTA and its private key from any standard browser. For an example of how this can be done, see US Patent Application Series No. 09 / 574,687, Server-Assisted Regeneration of a Strong Secret from a Weak sectret, by Warwick Ford, May 17, 2000. This document is incorporated herein by reference to the application. Assuming that the server hosting the PTA is the same as hosting the authentication service 130, the two functions may be integrated to some extent. In another embodiment, the PTA and / or the corresponding private key is implemented at the buyer's client. For example, a PTA is a plugin to a buyer's browser with a buyer's private key stored locally on the buyer's client or in dedicated hardware (eg, a hardware token). It may be implemented as ActiveX control). [0043] Continuing with Sucker's example, after registration 302, buyer 110 is shopping at Pete and decides to buy some product. Figure 4 is a screenshot (depiction) of the buyer's browser as the buyer initiates the checkout (examination, selection, payment completion) process. The HTML order format 400 includes an order area 410, as well as a button 420 for urgent authenticated payments. The order area shows that the total amount and tax for this order is $ 59.95. Buyer 110 can use the rest of this format to check out (pay), filling in credit card information, billing address, etc., in an unauthenticated manner. However, the buyer 110 wants an authenticated payment and instead clicks button 420 for "AuthPay" (ie authenticated payment). [0044] As a result of clicking the authenticated payment button 420, a request for authentication is sent from the buyer's browser to the authentication service 130 (330). This request includes a description of the payment transaction business (transaction) and also identifies and identifies the seller 120. Authentication service 130 determines if buyer 110 has access to confidential information (in this case a private key for the chosen account) (steps 340-346). In particular, the authentication service 130 sends a call request (challenge request) to the buyer 110. The call request requires Buyer 110 to digitally sign certain data with a private key for the chosen account. Buyer 110 sends the person's call response (challenge response) back to authentication service 130. The authentication service 130 searches and reads the public key stored early and uses it to determine if the buyer 110 has access to the corresponding private key. The authentication process is generally performed between computers and is done without the active involvement of the human buyer 110. [0045] In this embodiment, the PTA also allows the buyer 110 to choose which account of the person he or she wants to use, and then select a particular payment security (tool) from there within that account. Called to do so. More specifically, clicking button 420 allows the buyer's web browser to interact with the PTA through the dialog boxes in Figures 5 and 6. In Figure 5, buyer 110 identifies which account he or she wants to use by filling in the username (name) field 510, and then fills himself with the correct password 520 against the PTA. Authenticate. The PTA displays the dialogue box in Figure 6, which contains a visible (visual) display 530 for the selected account. Buyer 110 clicks on the Login button 540 to confirm that he or she wants to use this account. A private key for this account is available here for authentication and digital signatures. [0046] If the buyer 110 is unsuccessful at the authentication stage, the authentication service 130 adopts the proper behavior. For example, notify seller 120 that the buyer has not been authenticated. Alternatively, it can refuse processing for further trading operations and return the initial screen (eg, checkout screen 400) to the buyer. [0047] If buyer 110 is authenticated, authentication service 130 applies additional buyer profile information to the transaction business (360). In this case, the authentication service 130 searches for the buyer profile information and sends this information to the browser in the format shown in FIG. This information contains different payment securities (tools) 610 within this account, as well as different shipping addresses 620. Since this buyer's profile information is sensitive in nature, the authentication service 130 should authenticate the buyer 110 before sending the information to that person. This form also iterates over information 630 about the trading business. Buyer 110 submits this form by selecting payment securities 610 with billing address 620 and clicking the Continue button. [0048] Buyer 110 and Authentication Service 130 create a digitally signed record of the transaction operation using the form and dialogue box shown in Figures 8 and 9 (380). In response to the submission of this form 600, the authentication service 130 returns the form of FIG. 8, which contains a summary 710 of the transaction operation and also requires the buyer 110 to approve the transaction. Buyer 110 clicks on Authorize Transaction button 720 to do so. This calls the PTA dialogue box in Figure 9. By clicking the Sign button 730, the buyer causes the PTA to digitally sign the summary, thereby creating a digitally signed record of the transaction. The authentication service 130 then notifies the seller 120 (350), stating that the buyer has approved the use of the payment securities, and preferably the buyer is further authorized for this transaction. I also tell you that. [0049] In this embodiment, the authentication service 130 also processes payment securities for the seller 120 through the payment gateway 160, such as the Payflow service made available by VeriSign. [0050] The transmission of information between the buyer 110, the seller 120 and the authentication service 130 within Method 300 is achieved using conventional web technology. For example, format 400 is provided by seller 120, but clicking on the authenticated payment button is to hand off the buyer's browser from seller 120 to authentication service 130. Similarly, once the authentication process is complete, the buyer's browser is returned from the authentication service 130 to the seller 120. [0051] Both of these transfers (transfers) are accomplished using conventional techniques such as GET, POST (mailing), and / or forwarding (readdressing). For example, a transfer can be achieved by a form of HTTP POST that contains the data to be sent. This is robust, but sometimes results in an intermediate web page that you don't want. However, automatically triggered client descriptions (scripts) can be used to eliminate the need to click through intermediate pages. Another option is to be HTTP forwarded towards the URL, which contains the data to be conveyed. This can eliminate intermediate pages, but currently there is a limit to the amount of data that can be conveyed (because only HTTP GET can be transferred). Another option is to HTTP forward to a URL that references the location of the data to be communicated, which will be referenced along with the data actually transferred via some other mechanism. This is more complicated than the other two methods, but it allows you to eliminate intermediate pages without limiting the amount of data that can be conveyed. The data is transmitted by some other mechanism (method), given an identifier (ID) at the destination, and cached. Buyer 110 is forwarded with a URL that contains the identifier specified there. [0052] In a simplified example, it is assumed that clicking the authenticated payment button 420 sends a request for authentication to the authentication server 130. This is achieved in this embodiment using Form 400 with the following structure (Equation 1): [0053] [Number 1]<img file="JP4880171B2_D0001.tif" />[0054] Here, "https://authpay.verisign.com/authenticate.dll" is the URL of the authentication service 130. The "return URL" field identifies the location of the seller 120 on the website, to which the buyer will return after verification is complete. The "msg" field bears a request for authentication. Other fields may be used to support additional features, which include applying profile information and payment processing. [0055] When the payment approval process is complete, Buyer 110 is handed from Authentication Service 130 to Seller 120 to return via HTTP POST to the return URL (return URL) specified in the request. The HTML format sent back to seller 120 has the following structure (Equation 2): [Number 2]<img file="JP4880171B2_D0002.tif" />[0056] Here, the "transID" field contains a transaction business identifier that can be used by either the buyer 110 or the seller 120 to refer to the transaction business in the transaction business record document 170. Can be applied. The "msg" field carries the response from the authentication service 130 to the seller 120. [0057] The present invention has been described in considerable detail with reference to preferred embodiments, but other embodiments are possible. For example, in a wireless (for example, WAP application) embodiment, some or all of the communication between the buyer 110, the seller 120, and the authentication service 130 occurs via a wireless connection or the wireless infrastructure is wired. It occurs through a gateway connected to the infrastructure. For example, Buyer 110 will communicate from a device on hand that allows WAP. Therefore, the scope of claims should not be limited to the description of the preferred examples contained herein. [Simple explanation of drawings] FIG. 1 is a block diagram of a system according to the present invention. [Figure 2] The figure which shows the event trace which shows the method of operating the system of FIG. FIG. 3 shows an event trace showing a preferred method of operating the preferred embodiment of the system of FIG. FIG. 4 shows various screenshots (one scene) and dialog (natural language dialogue) boxes showing the method of FIG. FIG. 5 is a diagram showing various screenshots (one scene) and a dialog (dialogue in natural language) box showing the method of FIG. FIG. 6 is a diagram showing various screenshots (one scene) and a dialog (dialogue in natural language) box showing the method of FIG. FIG. 7 is a diagram showing various screenshots (one scene) and a dialog (dialogue in natural language) box showing the method of FIG. FIG. 8 is a diagram showing various screenshots (one scene) and a dialog (dialogue in natural language) box showing the method of FIG. 9 is a diagram showing various screenshots (one scene) and a dialog (dialogue in natural language) box showing the method of FIG.