US 7987500 B2
The present invention is a method and system for providing a user with confirmation of the origin of a Web site and related information including the steps of registering a Web site with an assuring third party, saving the registration on a registration server, entering in a database the Web site's Internet domain name and cross-referencing it to the registration data, retrieving the Web site's domain with an Internet browser, and either (1) using a client application tool to call for registration data for the domain name via a secure SSL connection with the registration server, determining if the domain has been registered, and returning and displaying registration data for the domain name as a confirmed identity, or (2) calling a program on the registration server in response to an HTML tag on the domain via a secure SSL connection and passing it the domain name, determining if the domain has been registered, determining if the domain name has been registered, and returning and displaying registration data for the domain name as a confirmed identity.
1. A method for providing a user with confirmation of identification information for a Web site being browsed by the user comprising:
registering an http web site with a third party, the registration including a domain name of the http web site;
saving said registration on a registration server of the third party;
receiving a query from a client application tool of the user via a secure SSL connection to said registration server, the query including a query domain name corresponding to the Web site being browsed by the user;
determining if the query domain name has been registered; and
returning results of the determination to the client application tool for display on a client display.
2. A method for providing a user with confirmation of identification information for a Web site comprising:
requesting a web site from a first server by an http address via a web browser on a client computer;
sending a query from a client application tool on the client computer via a secure SSL connection to a second server, the query including a domain name of the web site;
receiving, via the client application tool, a response to the query indicating if the domain name is registered with the second server; and
displaying, on the client computer, the indication of whether the domain name is registered with the second server.
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
9. A method for providing a user with confirmation of identification information for a Web site comprising:
requesting a web site from a first server by an http address via a web browser on a client computer; determining by a client application tool on the client computer whether the web site is SSL enabled; (a) if it is determined that the web site is not SSL enabled: sending a query from the client application tool via a secure SSL connection to a second server, the query including a domain name of the web site; and receiving, via the client application tool, a response to the query indicating if the domain name is registered with the second server; and
displaying, on the client computer, the indication of whether the domain name is registered with the second server, or (b) if it is determined that the web site is SSL enabled: validating a SSL certificate via the client application tool on the client computer; and displaying, on the client computer, identification information of the web site based on the SSL certificate.
This application is a continuation of U.S. application Ser. No. 11/506,486, filed Aug. 18, 2006 now U.S. Pat. No. 7,552,466, which is a continuation of application Ser. No. 10/039,986 filed Jan. 4, 2002 now U.S. Pat. No. 7,114,177, entitled “Web Site Identity Assurance”; which claims priority to (a) Application No. 60/279,328 filed Mar. 28, 2001, entitled “Website Identify Assurance”; (b) Application No. 60/289,249 filed on May 7, 2001, entitled “TrustWatch”; and (c) Application No. 60/295,728 filed on Jun. 4, 2001, entitled “TrustWatch True Site”. Each of these applications is incorporated herein by reference.
This invention relates to electronic communication systems and in particular to a method and apparatus for showing end-users the confirmed identity of a Web site owner, and also in particular to this method and apparatus being a secure and reliable reporting mechanism based on existing and prevalent common standards.
The importance of secure communication is increasing as world-wide networks such as the Internet and the World Wide Web (WWW) portion of the Internet expand. As global networks expand through the interconnection of existing networks, users may gain access to an unprecedented number of services. The services, each of which may be maintained by a different provider, give users access to academic, business, consumer, and government information. Service providers are now able to make their services available to an ever-expanding user base that is truly global.
The ease with which services and users are able to find each other and the convenience associated with on-line transactions is leading to an increase in the number of remote business and related transactions. However, users and services are not always certain who or what is at the other end of a transaction. Therefore, before they engage in business and other transactions, users and services want and need reassurance that each entity with whom they communicate is who or what it purports to be. For example, users will not be willing to make on-line purchases that require them to reveal their credit card numbers unless they are confident that the service with which they are communicating is in fact the service they wanted to access. Commercial and other private entities who provide online services may be more reluctant than individuals to conduct business on-line unless they are confident the communication is with the desired individual or service. From the small and/or new on-line merchant's standpoint, they can reach a global audience through the World Wide Web but they are usually unknown to potential customers and have no brand on which to build an on-line business. For them, displaying confirmed and trusted identity and legitimacy are critical to building their brand and business.
Both users and services need reassurance that neither will compromise the integrity of the other nor that confidential information will be revealed unintentionally to third parties while communications are occurring. Security in a global network, however, may be difficult to achieve for several reasons. First, the connections between remote users and services are dynamic. With the use of portable devices, users may change their remote physical locations frequently. The individual networks that comprise the global networks have many entry and exit points. Also, packet switching techniques used in global networks result in numerous dynamic paths that are established between participating entities in order to achieve reliable communication between two parties. Finally, communication is often accomplished via inherently insecure facilities such as the public telephone network and many private communication facilities. Secure communication is difficult to achieve in such distributed environments because security breaches may occur at the remote user's site, at the service computer site, or along the communication link. Consequently, reliable two-way authentication of users and the services is essential for achieving security in a distributed environment.
Website Identity and SSL Protocol
The problem of establishing the identity of the owner and responsible party for a Web site is partially remedied by protocols such as the Secure Sockets Layer (SSL) protocol.
In the SSL protocol, each communicating program is assigned a key pair consisting of a public cryptographic key and a private cryptographic key. SSL uses the public and private keys for two programs to generate an agreed key that is used to encrypt a conversation between the two programs. This ensures privacy for the conversation and provides assurance to each party that only the other party could generate the other half of the conversation (this property is called two-party authentication).
In these prior art systems, a program that needs to send securely a non-repudiable piece of information (such as a receipt or a signed check) does so by encrypting that piece of information with its private key, which is equivalent to a digital signature. This technique is called signing. The receiver of the signed message can prove that the encrypted information came from the supposed sender (or anyone who knows the sender's private key) by successfully decrypting the message using the sender's public key. The receiver could also forward the message to a third party, who could similarly verify the sender's identity. Thus, non-repudiation is provided for specific situations.
SSL protocol, therefore, provides a partial identification and authentication solution for Web sites. There are limitations, however, as discussed below.
Limitations of SSL Protocol for Identification and Authentication
Even when a Web site is operating in SSL mode, the identity information stored in the underlying SSL certificate is not easily accessible to an end user for authentication purposes. Further, end users browsing the Web need to be able to know who is behind a site whether in SSL mode or not. Only a small percentage (less than 1%) of Web sites use SSL, and at those sites, only a small percentage (e.g., 1%) of all pages are protected by SSL.
In the SSL process the identity of the business responsible for a Web site is established and tied to Web site (actually to the fully qualified domain name) by a trusted certificate authority. This identity, when running under SSL mode, is available in a hidden way by clicking on the lock icon in the browser. However, most users do not know this lock icon is an active element that can be clicked and further do not understand the detailed information provided if they do click on it.
While SSL does a good job at establishing the basis for identity it has three chief shortcomings: (1) It does not work for pages that are not running under SSL (approximately 99.99% of all Web pages), (2) the identity aspect of SSL is hidden and obscure to the user, and (3) the limited identity information is minimal, incomplete and not considered useful to a consumer.
Furthermore, while SSL inherently supports identity and encryption, it is primarily focused on encryption. Use of SSL incurs substantial overhead (at least a 35% performance penalty and no possibility of pages being cached), and therefore is only present and usable on pages that require encryption such as those gathering sensitive data. A strategy for taking advantage of the identity aspects of SSL without incurring the overhead of encryption is not possible with its current design which is predicated exclusively on encryption of transmitted data.
Non-SSL Web Site Identity Solutions
While Web sites themselves can assert their identity without the use of SSL (e.g., through simple graphics and text), this identity method also has shortcomings: (1) Each Web site asserts its identity in a different way, leaving the user to figure out how to find the identifying information, and (2) no third party is standing behind the identity assertions, so a Web site can easily deceive an end user by putting whatever identity it desires on the Web site.
Use of Seals
Another non-SSL mechanism in common use by Web site owners to establish their identity and legitimacy as a reputable on-line business is to place seals from third parties on some of their Web pages. These seals are meant to portray an endorsement of some kind by the trusted, well-known third party seal provider. Seals are common in the off-line world and are displayed on doors and entrances of storefronts, in yellow page ads, on delivery or work vehicles and so on. On the World Wide Web they take the form of a graphic image and usually an active component such as a link that will identify this site as a legitimate holder in good standing of this seal.
Three serious problems exist with this prevalent mechanism. First, users do not usually click on the seal, which is required to verify association with the seal provider. Since the seal is just a static graphic image pulled from a file resident on the site's Web server, all seals from that provider are identical. Therefore the only way to differentiate one seal holder from another and check validity is to click on it. A click usually transfers the user's browser to the seal provider's site where a page is displayed stating the validity or lack thereof for the selected seal. Since most users do not click, this check is rarely performed. Also, users cannot be sure of what the check really is or what is meant to be displayed, so substituting some other page intended to represent or simulate validity (but that is actually fraudulent) is a trivial task for someone wanting to use the seal fraudulently.
The second serious issue is seal copying—the hijacking of the seals and placement on sites that are not legitimately allowed to display them. Any static image viewed by the browser is easily saved to a local disk and can be reused in a new Web page. This copying capability is a fundamental property of standard Web pages and the browsers that view them. This has made fraudulent placement of seals on the Web very common. This fact has made the effectiveness of seals for conveying identity and legitimacy on the Web weak and ineffective.
The third serious issue is Web site spoofing—the wholesale copying of a Web site to a new location for the purposes of identity theft and/or fraud. Site spoofing is a large and growing problem with several very large, public incidents having occurred and with over 1,000 reported incidents a year. Current state-of-the-art seals have no ability to detect site spoofing has occurred. In other words, if a site is spoofed that has one or more of current generation seals on it, the visitor to the spoofed site seeing one of these seals will have no indication this is not the legitimate version of that site.
Accordingly, an object of the present invention is to provide the confirmed identity of a Web site owner and related business information, regardless of whether the end user is browsing under SSL (i.e., in https) or not (i.e., in standard http).
It is a further object of the present invention to provide the confirmed identity of the Web site owner and related business information in a standard, recognizable, easy-to-access package passively with no click by the user.
It is a further object of the present invention to provide current confirmation that identity and business information is valid and accurate (e.g., not revoked, not expired).
It is a further object of the present invention to provide an identity confirmation mechanism that is robust and protects itself from copying or site spoofing threats.
The Web Site Identity Assurance invention described herein provides a confirmed identity and related business information to end users (e.g., browsers). The Identity Assurance is presented to the end user in the form of a visual display on the user's computer desktop or by other means of display or communication. The visual display can be (1) a graphic displayed from a client application tool that an end user would install on his or her machine, (2) a dynamic icon, the code for which is placed on a Web site by the Web site owner, or (3) some other means of display or communication. The client application tool has the ability to watch what sites an end user is browsing and therefore look up the associated confirmed identity information from an independent third party source. The dynamic icon has the ability to cause the browser to look up the associated confirmed identity information from an independent third party source for the URL of the page or pages where the dynamic icon is placed by the Web site owner. All three applications work in both SSL and non-SSL enabled Web sites.
The present invention is a system and method that meets the needs set out above. More particularly, the present invention is a method and system for providing a user with confirmation of the origin of a Web site including the steps of (1) registering a Web site owner's identity and business information with an assuring third party, (2) saving the registration in a database on a registration server, (3) entering in the database the Web site's Internet domain, and cross-referencing the Internet domain to the identity and business information), (4) retrieving the Web site's domain with an Internet browser, (5) calling a program at the assuring third party's registration server via a secure SSL connection and passing it the Internet domain name, (6) determining if the domain has been registered, (7) retrieving from the repository the identity (e.g., official name) and business information cross-referenced to the Internet domain name and returning the identity and business information to the client tool, (8) displaying the associated identity and business information in the client application tool.
In the alternative, the present invention may include the steps of (1) registering a Web site owner's identity and business information with an assuring third party, (2) saving the registration in a database on a registration server, (3) entering in the database the Web site's Internet domain, and cross-referencing the Internet domain to the identity and business information), (4), retrieving the Web site's domain containing an HTML dynamic image tag with an Internet browser, (5) calling a program at the assuring third party's registration server via a secure SSL connection and passing it the Internet domain name, (6) determining if the domain has been registered, (7) retrieving from the repository the identity (e.g., official name) and business information cross-referenced to the Internet domain name and generating an image with the identity and business information contained in the image, (8) displaying the dynamic icon image and associated identity and business information on the browser.
Preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which:
The present invention will now be described in detail with reference to the accompanying drawings. While the present invention is described in the context of an Internet based data communications network, which includes a specific number and type of components, the system of the present invention may be incorporated into data communications networks of many structures and sizes (e.g. mobile networks). The drawings are intended to provide one example of a data communication network configuration in which a system of the present invention may be implemented and are not intended to limit the applicability of the present invention to other network configurations.
The following description of the preferred embodiments of the invention relates to Web pages. It is noted up front, however, that the invention is not limited to use with Web pages.
Rather, all aspects of the invention can be used with any computer generated content including, but not limited to, rows in a database, an entire database, computer generated queries, documents, and the like.
The present invention is preferably implemented using a client server architecture, such as that shown in
Applications 21 include Web browser 24, among others. An example of a Web browser that may be used with the invention is Netscape.™. Navigator Web browser 24 displays a graphical user interface (“GUI”) to a user, through which the user may access information via the Internet (e.g., Web sites, individual Web pages, etc.). An example of such a GUI is shown in
Stored in this memory is assembly engine 25 and Web page elements 33. Assembly engine 25 is a program that is executed by processor 23 to assemble Web pages. More specifically, a single Web page may be composed of a plurality of static and dynamic elements, such as images, applets, text, sound, other Web pages, etc. In response to requests received from client 6, assembly engine 25 retrieves those elements (e.g., from memory 28) and combines them in a predetermined manner so as to form the Web page. Representative examples of commercially available assembly engines that may be used in connection with the present invention include ATG Dynamo, Servlets, JSP and ASP Certification server 7 likewise preferably comprises a computer having features similar to client 6. As shown in close up view 38, certification server 7 includes, among other things, memory 39 for storing both applications and certification information 48 which includes the manifests described below. Memory 39 may include one or more memory devices, such as a computer hard disk, redundant array of inexpensive disks (“RAID”), optical disk drive, and the like. Processor 40 is also included on certification server 7 so as to execute applications stored in memory 39 and to provide the resulting output to the network. Among the applications stored in memory 39 is certification engine 41. Certification engine 41 comprises computer executable code that runs on certification server 7 to certify Web pages and other dynamic pages based on their content and/or certification information stored in their elements. Certification engine 41 also organizes sets of Web pages into plural zones based on their levels of certification, the type of information contained therein, or the like, as described in more detail below. It is noted that certification server 7 and Web server 9 may be one in the same; however, since this is not a requirement, the more general case of separate Web and certification servers is depicted in
Web Site Identity Assurance
The present invention provides identity assurance of a Web site owner by presenting to the end user in the form of a visual display on the user's computer desktop information regarding the owner. The visual identity display can be either a dynamic icon placed on a Web site by the Web site owner or a graphic displayed from a client application tool that an end user would install on his or her machine. The client application tool has the ability to watch what sites an end user is browsing and therefore look up the associated confirmed identity information.
Turning now to
Client Application Tool Example—Assuring Third Party Server
Turning now to
1. At setup time the Web site owner performs an off line registration with an assuring third party. The assuring third party puts an entry in a database cross-referencing the Web Site's Internet domain to the associated identity and business information provided by the Web site owner during registration. The identity and associated business information is independently confirmed as part of registration. This registration process is a one time event that only occurs at setup time.
2. An end user browses to a Web site that has signed up with the assuring third party. The Web site need not be running under SSL. The client application tool running on the end user's system retrieves the current domain being browsed from the client browser itself.
3. The client application tool calls a program via a secure SSL connection on the Assuring Third Party's Server passing it the domain name being browsed.
4. The Assuring Third Party Server looks up the domain, determines that it has been registered and returns the associated identity and business information to the client application tool for display.
Client Application Tool Example-Challenge-Response File on Web Site Server
Turning now to
In this alternate version, Web Site Identity Assurance is displayed via a client application tool on the end user's desktop as in the previous exemplary embodiment; however, the identity and business information is stored on the Web site's server rather than the server of the assuring third party. As in the previous example, the client application tool is a tool capable of seeing what the end user is browsing and displaying the confirmed identity and business information of the owner of the Web site. In this embodiment of the present invention, the Assuring Third Party Server provides a digitally signed challenge-response file to the Web Site operator to put on the Web Site's server with a known name, for example Identity.txt and in a known location, typically the root directory. More specifically the process includes the following steps.
1. At setup time the Web Site Owner performs an off-line registration with the assuring third party. The assuring third party provides the Web site owner with a challenge-response file containing the identity and business information from registration that has been digitally signed by the assuring third party. This file is placed in a known location on the Web site server. This registration process is a one time event that only occurs at setup time.
2. The user browses to a Web site that has signed up with the assuring third party. The Web site need not be running under SSL. The client application tool running on the end user's system retrieves the current domain being browsed.
3. The client application tool connects to the Web site server looking for the digitally signed file with a known name (for example, Identity.txt) in a known location (typically the root directory).
4. The client application tool validates the digital signature of the assuring third party using the embedded third party's public key confirming that the file is not invalid and has not been tampered with. Once confirmed, the client application tool displays the identity and business data obtained from the Assuring third party server.
Dynamic Icon Example
Turning now to
1. At setup time the Web Site Owner performs an off-line registration with the assuring third party as previously described.
2. The Web Site Owner places the dynamic icon tag in the desired page(s) on his or her Web Site. The tag is a simple HTML image tag with reference to a remote server not a local static image file as is customary. For example: The image tag might look like <img src=https://www.thirdparty.com/getImage.jsp>. A very unusual aspect of this is that the image tag points to a program (script) on the Assuring Third Party's Server rather than to an actual image. This allows the verification program to be invoked and do the assurance process before creating and returning the dynamic image.
3. The user browses to a Web site that has signed up with the assuring third party. The dynamic image icon as described above is embedded in the HTML for the Web site. The browser attempting to render the image will invoke the associated program on the Assuring Third Party's Server by transmitting the Internet domain name for the Web site page being viewed by the browser (Referrer Address).
4. The Assuring Third Party Server program is invoked via a secure https connection.
5. The Assuring Third Party Server formats the image with the identity and business information associated with the Referrer Address from the data stored in the Assuring Third Party Server and adds a date-and-time stamp for copy prevention. The associated program may also return instructions to the browser (e.g., by Java script code) that modifies the behavior of the browser by disabling the right-click or copy function of the end user's mouse so the returned image cannot be copied and pasted at a different Referrer Address (i.e., an anti-fraud and anti-copying feature). This formatted image containing the associated identity and business information is returned to the Web browser and the Web browser renders the image. This embodiment of the present invention makes use of the standard browser feature—that the browser always provides the domain name of the Web site page being viewed by the browser (Referrer Address) at the time it invokes the program associated with the HTML dynamic image tag embedded on the Web site page—as an additional anti-fraud and identity feature, as the Assuring Third Party Server will only render and return an image to the browser containing the registration data for the Referrer Address, and not for any other address. If the HTML dynamic image icon is somehow copied and pasted or otherwise reproduced on a Web page for another domain name, the program will either return no image or a warning image (if the actual domain name is not registered in the Assuring Third Party Server) or will return an image containing registration data only for the Web page actually being viewed, not for the Web page from which the HTML dynamic image icon was copied.
Turning now to
1. The end user browses to a Web site in SSL mode (https).
2. The client application tool recognizes that the browser is in SSL mode, validates the SSL certificate and displays the Organization Name and other embedded information from the certificate.
Visual Identity Assurance Display
Turning now to
Turning now to
In another embodiment the present invention can be implemented to provide real time confirmation of which Web site a viewer is viewing (i.e., no spoofing or high jacking). Additionally, the user can be provided with confirmation of the registrant of the domain name and information about the business which owns or is behind the site. The business information could in one embodiment be provided and verified through a variety of independent sources.
1. Domain Name Registrant Confirmation
In order to implement this function, enrollment and registration data as is collected as previously described, with the addition of extra fields (as described below). In addition, automatic checking of the domain name registrant against the appropriate registry, such as WHOIS, can be included.
2. Unverified Business Information
The expanded page of True Site can also include unverified business information taken straight from the on-line enrollment form (no editing). This could also include a text field containing additional information, such as an explanation of the relationship between the “real” business and the site and/or domain name registrant shown in the upper part of True Site.
Information fields would be provided by the business/enrollee as noted as being valid on a particular date. In addition such information would not be independently verified against public records.
The verification of domain name registrant and posting of enrollee business data could then be posted almost immediately on the enrollees site, and begin offering useful information immediately. Operations will not slow the process, and there will be little chance of error.
3. Verified Business Information
In an another embodiment of the above process, a standard verification processes for certain data fields in the enrollment form received from the enrollee—chiefly corporate name, official address, state of incorporation, registration number, officers, and renewal date could be undertaken. The True Site display could then be altered to indicate which fields had been independently confirmed. For example, a sentence could be added to the expanded True Site page, as follows “Data fields that have been independently confirmed are marked with an asterisk (*) and the date the data was confirmed.” If nothing can be confirmed we no asterisk is shown.
Here is an example of how True Site might look under these rules. First, here it is immediately after enrollment:
The True Site icon:
The expanded icon:
Later, after we have checked on-line with the Illinois Secretary of State, the expanded icon will appear as follows:
Note that not all information in the display above has a checkmark showing confirmation; nevertheless it is useful. The text field at the end (unconfirmed) is the way a business can explain its relationship to the domain name owner and the domain name itself.
The reason this would work is that the Trust Provider controls the content in a business' True Site on its own computer, so can update these fields and display (including confirmation of fields) whenever it wants to.
The graphics above are just a suggestion—maybe instead confirmed fields get special shading or background. Again, when in doubt, no confirmation would be provided.
Once this kind of True Site is established, it can be expanded over time with more and more tabs and fields with “Trust Provider confirmed” data.
The techniques described here are not limited to any particular hardware or software configuration; they may find applicability in any computing or processing environment. For example, functions described as being performed by a server can be distributed across different platforms. Moreover, the techniques may be implemented in hardware or software, or a combination of the two. Preferably, the techniques are implemented in computer programs executing on programmable computers that each include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device and one or more output devices. Program code is applied to data entered using the input device to perform the functions described and to generate output information. The output information is applied to one or more output devices.
Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system, however, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
Each such computer program is preferably stored on a storage medium or device (e.g., CD-ROM, hard disk or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described in this document. The system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner.
Thus, the foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.