This invention pertains to on-line transactions, and more particularly to presenting users with information about the reputation of relying parties.
When a user interacts with sites on the Internet (hereafter referred to as “service providers” or “relying parties”), the service provider often expects to know something about the user that is requesting the services of the provider. The typical approach for a service provider is to require the user to log into or authenticate to the service provider's computer system. But this approach, while satisfactory for the service provider, is less than ideal to the user. First, the user must remember a username and password for each service provider who expects such information. Given that different computer systems impose different requirements, and the possibility that another user might have chosen the same username, the user might be unable to use the same username/password combination on each such computer system. (There is also the related problem that if the user uses the same username/password combination on multiple computer systems, someone who hacks one such computer system would be able to access other such computer systems.) Second, the user has no control over how the service provider uses the information it stores. If the service provider uses the stored information in a way the user does not want, the user has relatively little ability to prevent such abuse, or recourse after the fact.
To address this problem, new systems have been developed that allow the user a measure of control over the information stored about the user. Windows CardSpace™ (sometimes called CardSpace) is a Microsoft implementation of an identity meta-system that offers a solution to this problem. (Microsoft, Windows, and CardSpace are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.) A user can store identity information with an identity provider the user trusts. When a service provider wants some information about the user, the user can control the release of information stored with the identity provider to the service provider. The user can then use the offered services that required the identity information.
But while the replying party has some information about the user's identity, the user has no information about the relying party—at least, no information that the user cannot find on his own. This can be a problem: some merchants do not make any reputation information available on their site, and other merchants control what reputation information is available, limiting the reputation information to only information that praises the merchant. And even if the merchant makes all reputation information available, the accuracy of the data can be questionable, as the merchant controls the reputation information.
A need remains for a way to addresses these and other problems associated with the prior art.
In an embodiment of the invention, a system includes a reputation information engine. The reputation information engine is capable of providing reputation information to the user about the merchant. The user can then use the reputation information in using the system.
The foregoing and other features, objects, and advantages of the invention will become more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.
Co-pending U.S. patent application Ser. No. 12/030,063, titled “INFO CARD SELECTOR RECEPTION OF IDENTITY PROVIDER BASED DATA PERTAINING TO INFO CARDS”, filed Feb. 12, 2008, which is hereby incorporated by reference for all purposes, describes how an identity provider can provide metadata which can be used by the user for various purposes. One example of such metadata is reputation information about the relying party: for example, whether a relying party has previously been considered reliable by other users. While co-pending U.S. patent application Ser. No. 12/030,063, titled “INFO CARD SELECTOR RECEPTION OF IDENTITY PROVIDER BASED DATA PERTAINING TO INFO CARDS”, filed Feb. 12, 2008, could be used as is without modification (except to use reputation information as the metadata) to provide reputation information to a user, there are advantages to modifications of that system, as described herein Before explaining the invention, it is important to understand the context of the invention.
In
Relying party 130 is a machine managed by a party that relies in some way on the identity of the user of computer system 105. The operator of relying party 130 can be any type of relying party. For example, the operator of relying party 130 can be a merchant running a business on a website. Or, the operator of relying party 130 can be an entity that offers assistance on some matter to registered parties. Relying party 130 is so named because it relies on establishing some identifying information about the user.
Identity provider 135, on the other hand, is managed by a party responsible for providing identity information (or other such information) about the user for consumption by the relying party. Depending on the type of information identity provider 135 stores for a user, a single user might store identifying information with a number of different identity providers 135, any of which might be able to satisfy the request of the relying party. For example, identity provider 135 might be a governmental agency, responsible for storing information generated by the government, such as a driver's license number or a social security number. Or, identity provider 135 might be a third party that is in the business of managing identity information on behalf of users. It is worth noting that identity provider 135 stores the claims—the actual values of the identity information about the user; the information card stored on computer system 105 represents this information. The identity provider does not store the information cards themselves.
The conventional methodology of releasing identity information can be found in a number of sources. One such source is Microsoft Corporation, which has published a document entitled Introducing Windows CardSpace, which can be found on the World Wide Web at http://msdn2.microsoft.com/en-us/library/aa480189.aspx and is hereby incorporated by reference. To summarize the operation of Windows CardSpace, when a user wants to access some data from relying party 130, computer system 105 requests the security policy of relying party 130, as shown in communication 140, which is returned in communication 145 as security policy 150. Security policy 150 is a summary of the information relying party 130 needs, how the information should be formatted, and so on.
Once computer system 105 has security policy 150, computer system 105 can identify which information cards will satisfy security policy 150. Different security policies might result in different information cards being usable. For example, if relying party 130 simply needs a user's e-mail address, the information cards that can satisfy this security policy might be different from the information cards that satisfy a security policy requesting the user's full name, mailing address, and social security number. The user can then select an information card that satisfies security policy 150.
Once the user has selected an acceptable information card, computer system 105 uses the selected information card to transmit a request for a security token from identity provider 135, as shown in communication 155. This request can identify the data to be included in the security token, the credential that identifies the user, and other data the identity provider needs to generate the security token. Identity provider 135 returns security token 160, as shown in communication 165. Security token 160 includes a number of claims, or pieces of information, that include the data the user wants to release to the relying party. Security token 160 is usually encrypted in some manner, and perhaps signed and/or time-stamped by identity provider 135, so that relying party 130 can be certain that the security token originated with identity provider 135 (as opposed to being spoofed by someone intent on defrauding relying party 130). Computer system 105 then forwards security token 160 to relying party 130, as shown in communication 170.
In addition, the selected information card can be a self-issued information card: that is, an information card issued not by an identity provider, but by computer system 105 itself. In that case, identity provider 135 effectively becomes part of computer system 105.
In this model, a person skilled in the art will recognize that because all information flows through computer system 105, the user has a measure of control over the release of the user's identity information. Relying party 130 only receives the information the user wants relying party 130 to have, and does not store that information on behalf of the user (although it would be possible for relying party 130 to store the information in security token 160: there is no effective way to prevent such an act).
But, as noted above, there might be information—reputation information about the relying party—stored either locally or externally, such as on an identity provider or a reputation service, that might be of value to the user. If the user is not provided this reputation information, the user makes less than a fully-informed decision in selecting an information card. The user might be releasing potentially sensitive information to an untrustworthy relying party. This, it is important that the user be provided reputation information about the relying party, wherever it might be stored.
Now that the problem—providing reputation information to a user—is understood, a solution to the problem can be explained.
Computer system 105 also includes reputation information store 225. Reputation information store 225 stores reputation information, such as reputation information 230, about relying parties, such as the relying party with whom the user wants to perform a transaction. Each piece of reputation information stored in reputation information store 225, such as reputation information 230, can be identified with an identifier such as reputation information identifier 235. Reputation information 230 can include an overall reputation for the relying party, or it can be subdivided by category (for example, to indicate that the relying party is very reliable in shipping purchased products that are in good condition and has a good “terms of use” policy, but has a poor reputation for keeping the user's privacy data private). Reputation information is not limited to just a raw number rating: reputation information 230 can include comments/remarks from other users who have reviewed the relying party.
Aside from what data reputation information 230 can represent, reputation information 230 can take any desired form. Among other possible forms, reputation information 230 can include a white list of known “good” relying parties, a black list of known “bad” relying parties, and a “shade of grey” list, which identifies known relying parties along the spectrum between “good” and “bad”. Reputation information 230 can also be, for example, a set of comments left by users.
Reputation information store 225 can also store reputation information metadata (not shown in
Computer system 105 also includes reputation information engine 240. Reputation information engine 240 processes reputation information 230 to present the reputation information to the user, and the form in which the reputation information can be presented. For example, if the information is heavily textual in nature (for example, written comments by a number of users who have interacted with the relying party), reputation information 230 can be presented to the user in some box or screen element, allowing the user to peruse the information at his or her leisure. But there are other ways in which the reputation information can be presented. One way in which reputation information 230 can be presented to the user is in the form of a visual or non-visual cue to the user. Co-pending U.S. patent application Ser. No. 12/029,373, titled “VISUAL AND NON-VISUAL CUES FOR CONVEYING STATE OF INFORMATION CARDS, ELECTRONIC WALLETS, AND KEYRINGS”, filed Feb. 11, 2008, which is incorporated by reference, describes how visual and non-visual cues can be used to present information to the user. A person skilled in the art will recognize that the system of co-pending U.S. patent application Ser. No. 12/029,373, titled “VISUAL AND NON-VISUAL CUES FOR CONVEYING STATE OF INFORMATION CARDS, ELECTRONIC WALLETS, AND KEYRINGS”, filed Feb. 11, 2008, can be modified so that instead of providing users with cues about information cards, the cues relate to the reputation of relying parties, as discussed below with reference to
Finally, computer system 105 includes reputation information store updater 245. Reputation information store updater 245 updates reputation information store 225. This update can be based on information provided by the user or any other source of information that affects the data stored in reputation information store 225.
In the above described embodiments of the invention, it is assumed that all the pertinent information (such as the information cards and the reputation information) is stored on computer system 105. But this is not always the case. For example, users sometimes use identity providers to generate the security tokens for the relying party. In such a model, the claim information associated with the information card is not stored on computer system 105: computer system 105 only stores the information card, which is a representation of the information managed by the identity provider. In a similar manner, reputation information might be stored on machines other than computer system 105.
In
In the system of
When and how computer system 105 receives reputation information 230 (and/or reputation information metadata 315) from reputation service 315 depends on the implementation of the system. In one embodiment, computer system 105 can request reputation information 230 from reputation service 315 as soon as the identity of the relying party is known. In another embodiment, computer system 105 can request from reputation service 315 all reputation information 230 about any relying parties. But in such an embodiment, the information received from reputation service 315 can be significant in quantity, to the point of being more information than is useful (especially given the probability that reputation service 315 stores reputation information about a large number of relying parties that the user is not interested in).
While
Reputation information engine 240 can manage reputation information in any desired manner appropriate to the embodiment of the invention. For example, in
Reputation information engine 240 can also be implemented in a manner that provides client 105 with some sense of trust about the accuracy of reputation information 230. For example, reputation information engine 240 can be designed to authenticate the source of the reputation information, such as reputation service 310 in
In embodiments of the invention where identity provider 135 also acts as reputation service 310, computer system 105 can interact with identity provider 135 in both of its separate capabilities. This fact opens the door to computer system 105 requesting reputation information 230 from identity provider 135 at different times, with potentially different results. In one embodiment, computer system 105 requests reputation information 230 from identity provider 135 at the same time that it requests the security token. In this embodiment, computer system 105 cannot inform the user about the reputation information before the user selects the information card, as the information card is selected before the security token is requested. But reputation information 230 can be stored locally (for example, in cache 320) for use by the user in the next transaction with that relying party.
In another embodiment, computer system 105 can request reputation information 230 from identity provider 135 in request that is out-of-band from a request for a security token. In this embodiment, because computer system 105 can request reputation information 230 before requesting the security token, computer system 105 can process the reputation information and let the user use that information in completing the transaction.
In yet another embodiment, computer system 105 can inform identity provider 135 (as the reputation service) that computer system 105 is online. This communication can be part of a broadcast from computer system 105 to a number of identity providers/reputation services. Then, identity provider 135, acting as a reputation service, can make a decision whether it has any reputation information that should be provided to computer system 105. If identity provider 135 has some reputation information to provide to computer system 105, identity provider 135 can transmit this reputation information to computer system 105 in an unsolicited communication. In this embodiment, the responsibility for the decision as to whether to transmit the reputation information lies with identity provider 135. Each reputation service can make this decision independently of any others.
In these embodiments where computer system 105 requests reputation information from identity provider 135 or reputation service 310, computer system 105 can request reputation information from each identity provider or reputation service when the system connects to the network (or at some regular intervals thereafter: for example, once per day). Computer system 105 then uses this information, however requested and whenever received, to update cache 320. A person skilled in the art will recognize other ways in which computer system 105 can update cache 320. A person skilled in the art will also recognize that these update policies mean that cache 320 might be out-of-date when card selector 205 accesses reputation information from cache 320. These concerns exist, but it is better to use accurate (if slightly out-of-date) information in the presentation of information cards than to not have the reputation information at all.
Not shown in
In situations where computer system 105 requests the reputation information from identity provider 135 separately from the request for the security token (which can be called an out-of-band request for the reputation information), there can be multiple channels used for communications between computer system 105 and identity provider 135.
A channel is a means of communication between computer system 105 and identity provider 135. A channel can include the physical constructs connecting computer system 105 and identity provider 135, the protocols used to manage the communication, and an identifier of a particular communication session between computer system 105 and identity provider 135, among other elements. For example, where both computer system 105 and identity provider 135 are connected to the Internet, the physical constructs between computer system 105 and identity provider 135 can include routers and cabling (or wireless routers, if some portion of the channel includes wireless communication). If a channel requires that communications travel between computer system 105 and identity provider 135 along a specific sequence of machines, this information form part of the definition of the channel. On the other hand, if the path between the machines is not critical, communications might travel along different paths, even while part of the same channel. Similarly, communications along different channels might include different protocols used to manage the message traffic. Finally, even if identical paths and protocols are used, communications between computer system 105 and identity provider 135 might involve different channels, if the communications are considered to be part of different sessions between the machines.
In
Reputation information might or might not be secret, but it is helpful that the reputation information not be altered. One way in which alteration of the reputation information can be detected is if the reputation information is encrypted. Another way in which alteration of the reputation information can be detected is if the reputation information is digitally signed. These embodiments are discussed further with reference to
Now that the operation of embodiments of the invention, such as those shown in
Where computer system 105 requests metadata generally from identity provider 135 (as described in co-pending U.S. patent application Ser. No. 12/030,063, titled “INFO CARD SELECTOR RECEPTION OF IDENTITY PROVIDER BASED DATA PERTAINING TO INFO CARDS”, filed Feb. 12, 2008), the sensitivity of the information might or might not be considered important. But reputation information might be sufficiently important that a user would want to protect its use. For example, if computer system 105 requests information about a specific relying party, the obvious conclusion is that the user is considering a transaction with that relying party. If the relying party is known to focus on a particular product or service, the user might find himself or herself subject to advertising by other companies regarding that product or service. If the user does not want such advertising, the user would have to choose between forgoing the use of the reputation information or potentially losing some privacy relating to the transaction with the relying party.
In one embodiment of the invention, to protect the user's privacy, computer system 105 can “disguise” the relying party that is of interest by requesting reputation information about a number of different relying parties.
There are many different ways in which the “dummy” relying parties can be identified. Computer system 105 can access a list of relying parties, and pick a number of them at random. Or, computer system 105 can filter the list, perhaps only selecting relying parties that provide comparable services or products (although such a mechanism might give away some of the user's anonymity, in that it would identify a product or service the user is potentially interested in). Or, computer system 105 can make up some relying party names at random (although this, too, might give away some anonymity, in that the relying party of interest might be the only real relying party in the list). A person skilled in the art will recognize other ways in which computer system 105 can select relying parties to use in attempting to preserve the user's anonymity, along with other techniques that can be used to preserve anonymity.
In another embodiment, as shown in
As discussed above with reference to
As discussed above with reference to
In main area 915, two relying parties 920 and 925 are shown. Relying party 920 is represented with “stink lines” 930, which are a visual representation that relying party 920 is no longer “fresh”. “Stink lines” 930 can be static, or can “shimmer” on screen, as desired. “Stink lines” 930 can be used to represent that there is a problem with relying party 920: for example, that relying party 920 does not have a good reputation. A person skilled in the art will recognize other possible visual cues, some of which are described in co-pending U.S. patent application Ser. No. 12/029,373, titled “VISUAL AND NON-VISUAL CUES FOR CONVEYING STATE OF INFORMATION CARDS, ELECTRONIC WALLETS, AND KEYRINGS”, filed Feb. 11, 2008, which is incorporated by reference herein.
Aside from visual cues, card selector 205 can also preset to the user non-visual cues regarding the state of relying parties. For example, relying party 925 is “shown” with aural sound 935. Aural sound 935 is an aural cue to the user regarding the state of relying party 925. For example, aural information might be a siren sound, alerting the user to a problem with the relying party. Other non-visual cues can include beeps, spoken warning or information messages, and so on. A person skilled in the art will recognize other possible aural cues.
Cues can take other forms as well, such as olfactory or tactile. For example, given the appropriate technology, card selector 205 might use a smell generator to release a “rotten egg”-type smell for a relying party that is does not have a good reputation (i.e., that “stinks”). Or, the user's keyboard might get hotter when the user is visiting a relying party whose reputation is poor. A person skilled in the art will recognize other ways in which card selector 205 can present non-visual cues to the user regarding the reputation of a relying party.
Although the above example uses cues of different types, which permits multiple different types of cues (aural vs. visual) to be applied simultaneously, this does not mean that cues of the same type cannot be used simultaneously. For example, a relying party might be colored red (to indicate it does not deliver products in a timely manner) and have stink lines (to indicate that it does not preserve user privacy). Or the relying party might “phase” between different cues (that is, alternate between the two cues, and gradually changing between the them), so that the user can be presented with both cues in a situation where one cue, if applied all the time, would prevent the presentation of another cue. A person skilled in the art will recognize other ways in which cues can be combined.
On the other hand, if the reputation information is received from an external source, such as an identity provider or reputation service, then at block 1120 (on
In yet another embodiment, such as the push model discussed above with reference to
In any embodiment where the system receives the reputation information from the identity provider or reputation service, if the reputation information was encrypted or otherwise protected against alteration (for example, by having an associated digital signature also transmitted to the client), then the system can verify the integrity of the reputation information, as shown in block 1145 (on
The following discussion is intended to provide a brief, general description of a suitable machine in which certain aspects of the invention can be implemented. Typically, the machine includes a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports. The machine can be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term “machine” is intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.
The machine can include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like. The machine can utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines can be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciate that network communication can utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 545.11, Bluetooth, optical, infrared, cable, laser, etc.
The invention can be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, instructions, etc. which, when accessed by a machine, result in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data can be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, and other tangible, physical storage media. Associated data can also be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and can be used in a compressed or encrypted format. Associated data can be used in a distributed environment, and stored locally and/or remotely for machine access.
Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles, and can be combined in any desired manner. And although the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “according to an embodiment of the invention” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms can reference the same or different embodiments that are combinable into other embodiments.
Consequently, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all such modifications as can come within the scope and spirit of the following claims and equivalents thereto.
This patent application is a continuation-in-part of co-pending U.S. patent application Ser. No. 12/030,063, titled “INFO CARD SELECTOR RECEPTION OF IDENTITY PROVIDER BASED DATA PERTAINING TO INFO CARDS”, filed Feb. 12, 2008, which is a continuation-in-part of co-pending U.S. patent application Ser. No. 12/029,373, titled “VISUAL AND NON-VISUAL CUES FOR CONVEYING STATE OF INFORMATION CARDS, ELECTRONIC WALLETS, AND KEYRINGS”, filed Feb. 11, 2008, both of which are hereby incorporated by reference for all purposes. This patent application is a continuation-in-part of co-pending U.S. patent application Ser. No. 12/029,373, titled “VISUAL AND NON-VISUAL CUES FOR CONVEYING STATE OF INFORMATION CARDS, ELECTRONIC WALLETS, AND KEYRINGS”, filed Feb. 11, 2008, which is hereby incorporated by reference for all purposes. This patent application is also related to co-pending U.S. patent application Ser. No. 11/843,572, filed Aug. 22, 2007, co-pending U.S. patent application Ser. No. 11/843,638, filed August 22, 2007, and to co-pending U.S. patent application Ser. No. 11/843,640, filed Aug. 22, 2007, which claim the benefit of U.S. Provisional Patent Application Serial No. 60/895,325, filed Mar. 16, 2007, of U.S. Provisional Patent Application Ser. No. 60/895,312, filed Mar. 16, 2007, and of U.S. Provisional Patent Application Ser. No. 60/895,316, filed Mar. 16, 2007, all of which are all hereby incorporated by reference for all purposes.
Number | Date | Country | |
---|---|---|---|
Parent | 12030063 | Feb 2008 | US |
Child | 12042205 | US | |
Parent | 12029373 | Feb 2008 | US |
Child | 12030063 | US |