Account linking with privacy keys

A computer system, a method for communicating with a plurality of websites, a method for a first website to link user accounts with a second website, and a computer-readable medium.

<Copyright Notice>

Portions of the specification of this patent document contain copyrighted material. The copyright owner has no objection to facsimile reproduction by anyone of a patent document or patent specification when it is published in a patent file or record of the United States Patent and Trademark Office, but otherwise all copyrights are reserved.

As users continue to increase their dependence on online resources to conduct business and entertainment, the importance of protecting confidentiality and facilitating secure transactions is growing. Encryption of information is one way to provide confidentiality and security in an online environment. One encryption method involves the use of a public key that is shared publicly with others. The public key is used to encrypt messages sent to the owner of the public key. The owner then decrypts the message using the secret key. The use of advanced cryptography such as public keys serves to combat "phishing" attacks, providing a new level of security for online users.

One of the potential drawbacks of this type of cryptography is that when the public key is reused in many online sites, the public key becomes a new form of personally identifiable information. A public key can be thought of as a string of bytes that can be used as a "database" key in addition to an encryption key. In this situation, the public key can be used to correlate and track a user's online activities across multiple online resources. For example, two websites may compare public keys registered on their site, and if a match is found, they may correlate the purchasing profiles of the owners of these keys in a way the user may not have considered or verified.

Also, there are situations in which a user would typically wish to maintain his/her confidentiality when conducting online transactions, but there are situations in which a user may wish to allow websites to share information about the user. For example, if a first website provides a discount product or service to members of a second website, and the user is a member of the second website, the user may request that the first and second websites provide information about the user You may want to give permission to share the .

Accordingly, users need an online environment where confidentiality and security issues are addressed and users can control when and how online resources share user information.

&lt;Summary of the Invention&gt;

This Summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description below. This Summary is not intended to be used to identify key features or essential features of the claimed subject matter or to limit the scope of the claimed subject matter.

According to an aspect, a computer system includes a security module programmed to generate a first private key for use in secure communication with a first website and a second private key for use in secure communication with a second website. and the first and second keys are different. The computer system is further configured to receive a request from the first website to link a first user account associated with the first website to a second user account associated with the second website, and to provide the user with the first and and an identification module programmed to provide an option for linking second user accounts.

According to another aspect, a method for communicating with a plurality of websites includes generating a first private key for secure communication with the first website; generating a second private key for secure communication with a second website; receiving a request for an account link from the first website to share user information with the second website; and providing the user with an option to approve or reject the account link.

According to another aspect, a method for a first website to link user accounts with a second website comprises: sending a request for an account link from the first website to share user information with the second website; step; receiving a response from a user authorizing the account link; and sending a coupon to the second website to initiate the account link, wherein the coupon includes a first private key associated with the first website and a second private key associated with the second website. and a link consent comprising: the first and second private keys are different.

Reference is now made to the accompanying drawings, which are not necessarily drawn to scale.

1 is a diagram illustrating an exemplary computing environment in which a computer system is programmed to communicate with a plurality of websites using a plurality of private keys.

FIG. 2 is a diagram illustrating exemplary communications between a computer system and one of the websites of FIG. 1 .

3 is a diagram illustrating an exemplary method for using private keys.

4 is a diagram illustrating an exemplary coupon used to exchange user information between two websites.

5 is a diagram illustrating an exemplary method for implementing an account link between two websites.

6 is a diagram illustrating an exemplary method for a web site to request an account link with a plurality of other web sites.

7 is a diagram illustrating an exemplary graphical user interface for providing account link information to a user.

8 is a diagram illustrating an exemplary method for a web site to request and implement an account link.

Hereinafter, embodiments will be more fully described with reference to the accompanying drawings. The embodiments are provided so that this disclosure will be thorough and complete. Like numbers refer to like elements throughout.

Embodiments disclosed herein generally relate to a plurality of different private keys generated by a user's computer system for secure communication with a plurality of websites. Since the private key used to communicate with each website is different, the use of private keys cannot be used to correlate a user's activities on different websites. In certain embodiments, a user may authorize two or more websites to share information about the user that includes different private keys used on the websites.

Referring now to FIGS. 1 and 2 , an exemplary computing environment 100 includes a computer system 110 , a network such as the Internet 130 , and a plurality of websites 152 , 154 , 156 . Computer system 110 may be controlled by a user to communicate with websites 152 , 154 , 156 via Internet 130 .

Computer system 110 may be configured as a personal computer including at least one processor and memory. Computer system 110 may be implemented in either removable and non-removable media, as well as volatile and non-volatile computer storage media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. includes more than Computer system 110 includes an operating system, such as Microsoft's Windows operating system, stored on a computer-readable medium, and one or more programs.

Computer system 110 may also allow a user to interact with computer system 110 as well as prevent computer system 110 from communicating with other devices, such as websites 152 , 154 , 156 . It includes one or more input and output communication devices that allow. A user of computer system 110 may access websites 152 , 154 , 156 using a program on computer system 110 , such as browser 214 . An example of the browser is the Internet Explorer browser provided by Microsoft Corporation. In one embodiment, browser 214 running on computer system 110 uses the Hypertext Transfer Protocol Security ("HTTPS") protocol to access websites 152 , 154 , 156 , although other protocols may be used. communicate with one or more of

In embodiments, system 110 includes an identification module 216 that is programmed to maintain one or more digital identifiers associated with a computer user. In certain embodiments, these digital identifiers are Infocards that form part of the InfoCard system provided in the WINFX application programming interface developed by Microsoft Corporation of Redmond, Washington. The Infocard system allows the user to manage multiple digital identifiers associated with the user, referred to as Infocards. The Infocard system utilizes a web service platform such as the Windows Communication Foundation in the WINFX application programming interface. In addition, the Infocard system is built using web services security specifications that are at least partially propagated by Microsoft Corporation of Redmond, Washington. These specifications include WS-Security, a message security model, WS-SecurityPolicy, an endpoint policy, WS-MetadataExchange, a metadata protocol, and WS-Trust, a trust model.

Computer system 110 also includes a security module 218 that is programmed to generate private keys 112 , 114 , 116 . For example, system 110 generates a private key 112 that is shared with website 152 . In embodiments, the private key 112 is a pair-wise key between the user of the system 110 and the website 152 . The security module 218 of the system 110 is programmed to generate a different private key for each website 152 , 154 , 156 . System 110 and websites 152 , 154 , 156 may then use their respective private keys 112 , 114 , 116 for secure communication. For example, system 110 may use private key 112 to generate encrypted message 220 that is sent to website 152 . The website 152 may then decrypt the message 220 as described above.

Although all of the private keys 112 , 114 , 116 are associated with a user of the system 110 , each private key 112 , 114 , 116 is different. Due to this pair-wise nature, private keys 112 , 114 , and 116 can be transferred to computer system 110 via different websites 152 , 154 , 156 based solely on the use of private keys 112 , 114 , 116 . Minimizes the ability of websites 152 , 154 , 156 to correlate user activities. For example, since the private key 112 used to communicate with the website 152 is different from the private key 114 used to communicate with the website 154 , the websites 152 , 154 are It is not possible to correlate user activities on websites 152 , 154 based solely on the keys used to communicate with websites 152 , 154 .

In embodiments, each private key 112 , 114 , 116 may be a symmetric key or an asymmetric key. An exemplary private key is structurally similar to a public key in that it is a binary number of a specific length that is 40 bits to 256 bits long for a symmetric key, 512 to 4096 bits for an asymmetric key, and so on. The main difference between private key and public key is that the private key is transmitted to a website or a selected group of websites instead of being publicly disseminated. A user may have a plurality of different private keys, one for each of the websites with which the user communicates (or for each group of websites).

In one embodiment, one or more of the private keys 112 , 114 , 116 is a symmetric key based on algorithms such as, for example, the Data Encryption Standard ("DES") or the Advanced Encryption Standard ("AES"). For example, a symmetric private key, such as private key 112 , is known by both the user of computer system 110 and website 152 . Symmetric keys can be used to sign and encrypt, but since they are shared between system 110 and website 152, it is impossible to determine which one signed or encrypted a particular communication. Further, the private key 112 cannot be shared with a third party (eg, websites 154 , 156 ) because the third party can impersonate one or both of the user and website 152 . .

In an alternative embodiment, one or more of the private keys 112 , 114 , 116 is an asymmetric key based, for example, on the Rivest-Shamir-Adleman ("RSA") algorithm. In this embodiment, the user of system 110 has a private key that is not shared, and website 152 has a private key that can be used to encrypt messages sent to the user and verify signatures made using the private key. (112). Since only the user of the system 110 can sign with the private key, it is possible for the resource to prove that the user has signed a particular communication. This is commonly referred to as non-repudiation.

Additional details regarding the generation of private keys are set forth in US Patent Application Serial No. 11/074,885, filed March 7, 2005, which is incorporated herein by reference in its entirety.

Referring now to FIG. 3 , an exemplary method for using private keys is shown. At operation 310 , the user's system generates a first private key. The first private key is transmitted to the first website in operation 320 . For example, in certain embodiments, the first private key may be securely transmitted to the first website by encrypting a message including the first private key using a public associated with the first website. Then, in operation 330, the user uses the first private key (using the first private key if the first private key is symmetric, or using the private key if the first private key is asymmetric) the signed message may be transmitted to the first website. Then, in operation 340 , the user's system generates a second private key, which is transmitted to the second website in operation 350 . Then, in operation 360, the user sends the signed message to the second website (using the second private key if the second private key is symmetric, or using the private key if the second private key is asymmetric) can be transmitted In embodiments, the first and second websites correlate transactions by the user between the first and second websites based solely on private keys used for communication between the user and the first and second websites. This cannot be done because the first and second private keys are different.

Referring back to FIG. 1 , computing environment 100 includes websites 152 that correlate information about a user of system 110 based on keys associated with communication between the user and websites 152 , 154 , 156 . , 154, 156), but in certain circumstances it may be desirable for the user to permit correlation.

For example, if website 152 is an airline reservation website, and website 154 is a vehicle rental website that offers discounts to customers of the airline reservation website, then the user can use websites 152, 154 ) may want to allow them to share user information so that they can receive a discount.

In such situations, the user may authorize the account link 158 between the websites 152 , 154 . The account link allows the user to determine when information about the user on the website 152 will be shared with the website 154 and vice versa. The shared user information may include profile information such as name, address, and phone number, as well as transaction information such as information about products and/or services purchased by the user. In the example shown, account link 158 enables website 152 to share information about a user, such as profile and transaction information, with website 154 . In embodiments, private keys 112 , 114 may be used to facilitate account linking 158 .

For example, in one embodiment, two pair-wise asymmetric private keys "K<sb>1</sb>" and "K<sb>2</sb>"A Websites R<sb>1</sb> and R<sb>2</sb>is used in A human readable policy "P" defining an account link is provided to the user for review. Policy "P" refers to websites R<sb>1</sb> and R<sb>2</sb> Defines how information is shared between For example, policy "P" may define what information is shared, how long the information is updated/shared, whether sharing is unidirectional or bidirectional, and what can be done with the shared information. "S<sb>K</sb>(L)" represents the signature for the content L using key K, and "T" represents the timestamp. Based on this information, the security module 218 can provide a coupon according to the account link consent "L" as follows: It is programmed to generate "C".

L = {P,R<sb>1</sb>,K<sb>1</sb>,R<sb>2</sb>,K<sb>2</sb>,T} and

C = L + S<sb>K1</sb>(L) + S<sb>K2</sb>(L)

As described below, coupon "C" can be used to facilitate sharing of user information between two websites. In embodiments, the link permission "L" is implemented as part of the Infocard system using an XML fragment containing the policy, site identifiers and associated private keys.

Referring now to FIGS. 1 and 4 , an exemplary coupon 410 is shown. Coupon 410 encodes signatures 430, 440 on link consent 420 using link consent 420, and private keys 112, 114, respectively, used by websites 152, 154, respectively. A three-part Extensible Markup Language ("XML") document containing In certain embodiments, coupon 410 may be encoded as a security token according to a Security Assertion Markup Language ("SAML") or Extensible Rights Markup Language ("XrML"), although other languages may be used. .

Coupon 410 may be used on website 152 or website 154 , and may be provided to websites 152 , 154 in any order. The user of the system 110 provides the coupon 410 directly to each website 152, 154, or one website 152, 154 sends the coupon to another website to link the account 158 can create In this embodiment, non-repudiation is possible, and the user of the system 110 may maintain a copy of the coupon 410 to indicate the policy by which the user has authorized the account link.

Symmetrical private keys "K<sb>1</sb>" and "K<sb>2</sb>In an alternative embodiment using ", since the secret key cannot be disclosed to third parties, each website R<sb>1</sb> and R<sb>2</sb>A second pairwise key is introduced that functions as an identifier, which can be shared with selected third parties similar to an asymmetric private key. For example, the identifier key "I" may be used. A coupon, such as coupon 410, may be generated from link acceptance "L" as follows.

L = {P,R<sb>1</sb>,I<sb>1</sb>,R<sb>2</sb>,I<sb>2</sb>,T} and

C = L + S<sb>K1</sb>(L) + S<sb>K2</sb>(L)

In this symmetric private key context, coupon 410 operates on any website and may be provided to websites 152 and 154 in any order. The user of the system 110 may provide the coupon 410 directly to each website 152 , 154 , or one website 152 , 154 may provide the coupon to another website. However, evidence that the consumer possesses the identifier used on one website 152 , 154 is not provided on the other website. To ensure this, website 152 provides a coupon to website 154 before linking accounts on the two sites. The website 154 may then verify the signature and existence of the account. Non-repudiation is not possible, since the user as well as the websites 152 and 154 may use the associated signature.

Referring now to FIG. 5 , an exemplary method 500 for implementing account linking is shown. Beginning at operation 510 , the user receives a policy regarding an account link with a second website from a first website. Then, in operation 520, the user determines whether to allow the account link based on the policy. If the user decides to authorize the account link, control passes to operation 530, where the user sends a response authorizing the account link to the first website. In embodiments, the user's computer may generate the coupon as described above and send the coupon to the first website to authorize the account link. Alternatively, if the user determines in operation 520 not to allow the account link, control passes to operation 540, and a response denying the account link is sent to the first website.

Referring now to FIG. 6 , in certain embodiments, an example method 600 permits a website to request an account link with a plurality of other websites. For example, beginning at operation 610, the website transmits to the user's computer a policy and a plurality of identifiers associated with websites for which the website desires an account link. In embodiments, identifiers are public keys associated with websites, although other unique identifiers such as domain names may be used.

Then, in operation 620, the user's computer searches the list of websites with which the user has an existing relationship to determine if any identifier matches any website in the list. Then, in operation 630, the policy and a list of any matching websites are provided to the user. Then, at 640 the user is permitted to determine whether to allow the account link to any website in the matched list. If the user decides to authorize the account link to any of the websites listed, control passes to operation 650 where a coupon is generated that includes the link acceptance and interactive signature to the selected websites. Alternatively, if the user determines in operation 640 not to authorize account links to any of the websites listed, control passes to operation 660 where account links to these websites are not permitted.

In embodiments, method 600 may be implemented as part of an Infocard system provided in the WINFX application programming interface developed by Microsoft Corporation of Redmond, Washington. A number of digital identifiers stored by identification module 216 on computer system 110 may be retrieved when a website requests an account link to determine whether the user has existing accounts with any website in the request.

For example, in response to receiving a request from a website to link an account with a plurality of websites, the user's computer system is stored on the user's system and used to set up accounts at any website in the request. programmed to retrieve infocards associated with the user. Infocards matching the websites in the request are presented to the user. A user can decide whether to authorize an account link by reviewing matched infocards against policies and websites.

In certain embodiments, the account link is implemented as part of a registration process for a website, such as website 152 . For example, when a user registers with website 152 , the policy for the website requests account link information in addition to other registration information. Such account link information may include identifiers (eg, public keys or domain names) of websites for which an account link is required, such as website 154 . If the user has an existing account with website 154 , the user is presented with an option for linking an account with website 154 during the registration process of website 152 , and the user is presented with websites 152 , 154 . ) can approve/reject account links between Additionally, the identification module 216 may be programmed to allow tracking of which sites the user has approved for account linking.

For example, referring now to FIG. 7 , during the registration process with website 152 , a user is presented with a graphical user interface 700 . User interface 700 may be provided within browser 214 or as a separate interface on computer system 110 . Interface 700 provides window 610 with a list of all websites with which website 152 requests an account link and with which the user has an existing relationship. For example, window 610 lists websites 154 for which an account link is requested by website 152 and the user has an existing account with. The user may authorize account links to websites 152 , 154 by checking box 620 . Alternatively, the user may reject the account link by continuing the registration process on website 152 without checking box 620 . If multiple websites are listed in window 610, multiple check boxes may be provided so that the user can select which websites, if any, to allow account links with.

Referring now to FIG. 8 , illustrated is an exemplary method 900 for a first website to request and implement an account link. In operation 910 , the first website sends a request for an account link to the user. Then, in operation 920 , the website receives a response from the user. At operation 930 , the website determines whether the user has approved the account link. If the account link is not authorized, control passes to operation 950 and the account link is not implemented.

Alternatively, if the account link is approved by the user, control passes to operation 940, where the first website evaluates the coupon received from the user, such as coupon 410 described above, and verifies the signature therein. Then, in operation 960 , the first website exchanges the coupon with the second website to implement an account link, and obtains profile information for the user from the second website.

In embodiments, a first website exchanges coupons with a second website using protocols defined in a web services platform, such as the Windows Communication Foundation, provided in the WINFX application programming interface developed by Microsoft Corporation of Redmond, Washington. can do. For example, a first website may send coupon and profile information to a second website by sending a request security token ("RST") according to an issuance mechanism provided by WS-Trust. An example RST including a coupon is shown below.

<img file="KR20080098372A_D0001.tif" />

<img file="KR20080098372A_D0002.tif" />

The second website may respond to such a request by sending a request security token response ("RSTR") to the first website, an example of an RSTR is provided below.

<img file="KR20080098372A_D0003.tif" />

In embodiments, the security tokens issued by the first and second websites include, but are not limited to, X509, Kerberos, SAML (versions 1.0 and 2.0), Simple Extensible Identification Protocol ("SXIP"), etc. It may be generated in one or more formats among a plurality of formats.

One or more advantages are associated with the systems and methods described herein. For example, the use of private keys enhances the secrecy of users in an online environment. Additionally, the use of account links allows users to determine when and how information associated with users will be shared between websites.

While the examples described herein refer to websites, in alternative embodiments private keys and account links may also be used in connection with other online resources. For example, in alternative embodiments, rich client applications accessing web services via the Internet using the web services standard protocols defined in WS-*suite may use private keys and account link. For example, in one alternative embodiment, a dedicated rich client application that allows a user to trade stocks and manage a portfolio using a brokerage may initiate an account link between the brokerage account and the user's bank account. have. Other alternatives are possible.

The various embodiments described herein are provided by way of example only and should not be construed as limiting. Those skilled in the art will readily recognize various modifications and changes that may be made to the above-described embodiments without departing from the true spirit and scope of the specification or the claims below.