|Publication number||US20090300714 A1|
|Application number||US 12/472,502|
|Publication date||Dec 3, 2009|
|Filing date||May 27, 2009|
|Priority date||May 27, 2008|
|Also published as||US8402526, US8793757, US8799984, US8850548, US8869257, US8984584, US9130915, US20090300512, US20090300715, US20090300716, US20090300742, US20090300746, US20090300747|
|Publication number||12472502, 472502, US 2009/0300714 A1, US 2009/300714 A1, US 20090300714 A1, US 20090300714A1, US 2009300714 A1, US 2009300714A1, US-A1-20090300714, US-A1-2009300714, US2009/0300714A1, US2009/300714A1, US20090300714 A1, US20090300714A1, US2009300714 A1, US2009300714A1|
|Original Assignee||Open Invention Network Llc|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (12), Referenced by (11), Classifications (12), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims the benefit of prior filed U.S. Provisional Application Ser. No. 61/056,249, filed May 27, 2008, incorporated herein by reference thereto, and relates to U.S. Provisional Application Ser. No. 60/947,708, incorporated herein by reference thereto.
This application is co-pending with United States Patent Applications entitled “USER-PORTABLE DEVICE AND METHOD OF USE IN A USER-CENTRIC IDENTITY MANAGEMENT SYSTEM”; “IDENTITY SELECTOR FOR USE WITH A USER-PORTABLE DEVICE AND METHOD OF USE IN A USER-CENTRIC IDENTITY MANAGEMENT SYSTEM”; and “SYSTEM INTEGRATING AN IDENTITY SELECTOR AND USER-PORTABLE DEVICE AND METHOD OF USE IN A USER-CENTRIC IDENTITY MANAGEMENT SYSTEM,” all filed concurrently herewith by the same inventors as this application and assigned to the same assignee as this application, all such co-pending applications incorporated herein by reference thereto.
1. Field of the Invention
The present invention relates to privacy controls in identity management systems, and, more particularly, to a privacy enforcement engine that exercises privacy management over user identities by evaluating user privacy preferences against privacy policies.
2. Description of the related art.
The collection of vast amounts of personal data via the Internet has raised a variety of privacy related concerns. Online interactions with web service providers, during which the user discloses information to the service provider to facilitate the transaction, raise issues relating to the collection of personal information, the use of personal information, the level of control exercised over the information, the sharing of personal information, and user access to disclosed personal information.
Privacy over the internet involves the ability to control what information one reveals about oneself during an online session, and to control who can access such information once disclosed. Many e-commerce websites declare their intended use of information they collect in the form of privacy policies. The policies let customers know about a site's privacy practices. Based on an examination of the policy, a user can decide whether or not the practices are acceptable, when to opt-in or opt-out (i.e., specify the conditions under which disclosure is approved), and ultimately who to do business with (i.e., interact with on the internet). The presence of privacy policies increases a user's trust level, especially in a consumer-oriented transaction.
Nevertheless, there are drawbacks. Typical policies are often difficult to understand, hard to find, take a long time to read, and can change without notice. To help the user understand the privacy policies, user agents have become available to parse the policies and present the privacy practices to the user. However, these user agents are browser-based, and so as standardized modules do not give the user any flexibility or robustness to develop user preferences in any kind of tailored or customized fashion.
P3P adopts a peer-to-peer strategy, which can make it difficult for a user to interact with the policy. The policies composed by P3P can have significant amounts of information present in them, much of which a user might not find relevant. Further P3P itself provides no proper algorithm to collect and match user preferences with the policies. Regarding APPEL, this language can be difficult for the average internet user to understand. It is possible, then, that organizations with otherwise good privacy policies may encounter problems having users approve of the policies, without an adequate was for the user to readily evaluate the policy. By default, perhaps, it may happen that if a policy cannot be appropriately examined, especially when a user attempts to subject the policy to a preference test, it might be rejected.
An identity selector, as part of an identity management system, affords the user control over what information is sent to a relying party. However, the identity selector does not allow users to have control over the information once it is sent to the relying party. For example, the identity selector has no feature that determines how information would be used or the purpose of information collection. The identity selector can manage disclosures at the point of origin, but not at the point of receipt. What is needed is a way for the user to measure the trust of a relationship—the interaction between a user and service provider—that satisfies the privacy requirements of the user.
Further, it is important to develop a privacy process more tailored and focused to the precise disclosures that are being contemplated. For example, in applications that use an identity selector to manage a portfolio of information cards (digital user identities), there are no user-managed privacy processes specifically suited to disclosures involving the information cards. The identity selector does indeed have a generalized privacy option available through the user interface (e.g., browser), but this privacy channel may not address the more sensitive privacy concerns surrounding the disclosure of identity information.
The above-mentioned and other features and advantages of this invention, and the manner of attaining them, will become more apparent and the invention will be better understood by reference to the following description of an embodiment of the invention taken in conjunction with the accompanying drawings, wherein:
Corresponding reference characters indicate corresponding parts throughout the several views. The exemplification set out herein illustrates one preferred embodiment of the invention, in one form, and such exemplification is not to be construed as limiting the scope of the invention in any manner.
The system, according to the invention, includes a user agent 10 having a privacy enforcement engine 12, a rule evaluator 14, a privacy language preference editor 16, and a privacy preference ruleset 18. The system further includes an identity manager 20 having an identity selector 22 and an information card storage 24. In one exemplary form, the combination of user agent 10 and identity manager 20 is resident on a common host machine or computing platform 8.
By way of overview, the privacy management processes of the invention are resident in user agent 10, while the identity management processes are resident in identity manager 20. According to the invention, user agent 10 implements privacy controls relative to the identity-related disclosures pertaining to the operation of identity manager 20, specifically those involving information cards 24.
According to the invention, privacy language editors 16 and 34 are implemented respectively at the client-side and server-side of an interactive online relationship. These editors find particular application with user-centric identity management systems, namely, by working in conjunction with identity manager 20. The privacy protection processes afforded by the invention can supplement and complement the security measures conducted by client-side identity management processes (i.e., identity manager 20), thereby providing a measure of both security and privacy safeguards on one common platform (host 8).
According to one working example of the invention,
Referring now to
In brief, the identity selector 22: (i) receives and processes a security policy from relying party 30 (service provider), sent as part of a request for a security token replying to a user's request for access, (ii) retrieves and determines which information cards 24 satisfy the identity requirements of the security policy, (iii), enables the user to select one of the eligible cards determined to satisfy the security policy, (iv) requests the issuance of a security token from the appropriate identity provider 40, in reference to the card selected by the user, and (v) receives and forwards the security token to the relying party 30, as the response to the relying party's request for a security token.
In one exemplary operating scenario, a user attempts to access or request a web service or resource. In order to authenticate the user, and as a condition to deciding whether to authorize the access, the relying party 30 responds with a security policy describing the identity requirements needed to facilitate this online interaction or transaction. This response is typically a request for a security token that contains certain specified claim assertions necessary for the authentication process. The security policy is received at the user's host machine 8, and this event invokes the identity selector 22 to handle the processing of the security token and to formulate a response (i.e., directing the issuance of an appropriate security token).
The identity selector 22 examines the security policy and determines whether any of the user identities available to it satisfy the security policy. For this purpose, the available user identities can include third-party managed cards resident with the identity selector (i.e., stored on the local machine); self-issued identity cards (the editor allows the user to create such cards); and information cards retrieved from a user-portable personal security device plugged into the machine (e.g., a Java-powered iButton smart card). Information card storage 24 furnishes managed cards and self-issued cards to identity selector 22.
The identity selector 22 then presents to the user, in visual form, the portfolio of cards available for use in the authentication process, i.e., the eligible cards are those determined to satisfy the identity requirements of the security policy. The user is then prompted to select one of the cards from a user-interactive screen that displays the eligible cards. The identity selector 22 generates a token request in reference to the selected information card. The token request is forwarded to the appropriate identity provider 40 associated with the selected card, i.e., the identity provider that issued the managed card. If the token request is approved, the identity provider 40 issues a security token and returns it to the identity selector 22. The identity selector 22 then forwards the security token to the relying party 30 to comply with the identity requirements of the security policy.
Referring still to
Based on this evaluation, engine 12 enables the user to supervise and directly control the disclosure of user identity information. For example, the user, relying upon the evaluation results, can make a decision about whether to release user identity information. In this manner, the user exercises privacy controls over the information cards of identity manager 20, and so is able to determine which user identity, represented by a corresponding information card, is to be disclosed. Thus, privacy engine 12, like identity selector 22, performs a filtering function.
Editor 16 allows the user to establish preference expressions (ruleset 18) according to any type of setting criteria. For example, the user can be provided with certain preset privacy levels (privacy labels) from which to choose. Each privacy level would reflect a different degree of privacy control. Accordingly, each privacy level would be implemented by a respective ruleset having user privacy preferences that appropriately reflect the privacy level.
For example, the user can assign or apply attributes chosen by the user to certain corresponding preset privacy levels, thereby populating each privacy level with a certain group of selected attributes. These attributes correspond to certain types of disclosures over which the user desires to exercise privacy controls, namely, elements of user identity. The domain of user identity attributes is organized so that each attribute belongs to one (or perhaps more) privacy protection levels. The ruleset 18 is thus organized according to preset privacy levels (labels) each covering a certain sphere of disclosures. In an operating scenario involving the identity selector 22, the attributes would reflect information that the relying party is calling for in the token request; for example, the contents of the claims required by the relying party. The assignment between privacy levels and attributes (i.e., items for disclosure) reflects the user's commensurate degrees of privacy protection expected from the relying party.
The schemes of
Alternately, the determination of which privacy level to use can be coordinated with the process that processes the security policy and determines which cards satisfy the security policy requirements. For example, the reference in the ruleset of
In different forms, it is possible to invoke privacy engine 12, and consequently the rule evaluation, on the basis of claims data in the security policy, and, alternatively, on the basis of the information cards. However, other interaction schemes are also possible.
In one configuration, for example, the identity selector 22 receives the security policy from the relying party. The security policy specifies the claims that are needed to authenticate the user. These claims indicate assertions of information about the user. The identity selector 22 processes the security policy to identify the underlying claims. On the basis of the requested claims, the identity selector 22 (or other suitable agent) can invoke the privacy engine 12 to check whether the proposed disclosure of user identity information encompassed by each claim is authorized by the user. In particular, the summons of information called for by a claim invokes a certain privacy preference rule that addresses the very information referenced by the claim. For example, a claim that requests a user's first name, credit card no., or address causes the privacy engine 12 to use that rule from ruleset 18 that applies to this information, i.e., the strict privacy rule.
Editor 16 offers other ways to organize the preferences (i.e., ruleset 18) apart from using preset privacy level categories. For example, editor 16 may be operated in a custom mode allowing the user to manually change or create each preference. Additionally, ruleset 18 can be populated with imported rulesets obtained from other platforms.
In addition to the schemes set forth in
In the card-based preference scheme, a privacy preference is assigned to the card, while in the category-based preference scheme, a preference is assigned to a category populated by attributes. Each attribute is mapped to a category (and thus a preference), and so each card effectively has a preference attached to it by way of the attributes that is contains. These preference schemes provide a way to index privacy preferences to information cards and to attributes (e.g., a categorized group of attributes or a one-to-one per-attribute assignment).
The privacy editor 16 of
Referring now to
In one form of this scheme, the privacy preferences will be stored within the information card file, making the preferences portable with the card. The card-specific ruleset need not be contained in ruleset 18. Instead, the ruleset expressing the card-specific privacy preferences is stored on the relevant information card. So, when the privacy engine 12 is invoked with respect to a certain card, the card-specific ruleset is retrieved from the card file and used by rule evaluator 14.
A query-reply format similar to that shown in
Referring now to
According to the category-based scheme, a set of illustrative categories 600 are established. The attributes are then assigned, as appropriate, to each category. A mapping facility maps each attribute to its appropriate category. A category typically will have a definition or scope that indicates the kind of attributes belonging to it, and so facilitates the mapping or assignment of the attribute to its relevant category. The collection of attributes 604 covered by a certain category 600 forms a category-specific group 602. An attribute may belong to more than one category. In a user-interactive implementation, the user conducts the mapping operation by selectively assigning each attribute to a category. Thus, the categories are populated by the user.
Users can create categories like FINANCIAL or PERSONAL, typically oriented towards a certain subject matter. Attributes are then grouped under each category as appropriate. An attribute, for example, is properly assigned or mapped to a certain category when the attribute falls within the subject matter domain of the category. Examples of attributes, which are user identity elements, include information such as given name and first name. Because a preference is set to each category, each attribute within the category also receives the same preference association (i.e., designation or assignment). The category preferences are preferably portable from one user agent to another, relative to building ruleset 18.
All of the unique attributes present at a given instant in the operating environment are grouped into the categories. A given attribute can be covered by more than one category, so that the attribute will be located in each relevant category. A privacy label, indicative of category preference, is attached to each unique attribute within a category. A privacy label indicates what category the attribute belongs to, i.e., the category it has been mapped to or grouped under. These preference labels are reflected over all the attributes of the information cards. By propagating these preference labels throughout the cards, each user identity attribute of each information card becomes linked to a corresponding privacy label, and so becomes linked to one or more categories that cover the attribute. The card attributes, then, can be indexed to user privacy preferences, by virtue of the relationship between a card and a category, i.e., each attribute is grouped under a category. This assignment of attribute to category, and so also to privacy preference, makes the policy evaluation process more fine-tuned since the privacy preferences that are invoked are correlated to the very information (user attributes) that are subject to a disclosure request.
The combination of a card-based preference and a category-based preference enables two levels of preference expression to be applied to the use of a card. A user can decide which mode of preference expression to use. For a given attribute, it is possible to have more than one privacy label attached to it, if the attribute has been mapped to more than one category. In this event, the card-based preference can be compared to the competing, category-based preference labels attached to the attribute, in order to resolve the conflict. A proper resolution, for example, might give precedence to the preference dictated by the card-based scheme. Any other means of conflict resolution can be employed.
Reference is now made to
The outcome from the editing functions of FIGS. 7 and 8—creation of a category and populating it with attributes—is a category-based preference scheme, such as shown in
The preference management scheme for implementing the preference selections shown in
An incoming security policy is processed by the identity selector, including a determination of the claims required by the policy. These claim requirements specify required attributes that need to be contained in any security token sent to the relying party. The identity selector filters the information cards available to it, in order to determine which information cards satisfy the security policy requirements. The filter operation yields the indicated cards 200.
According to the invention, the preference settings for the categories can be appropriately mapped to the information cards, depending upon the attributes that make up the card. The preference mapping occurs on the basis of the specific set of identity attributes that populate a certain card. Since attributes are grouped into categories having preference labels (
For each information card 200 that passes the security policy test, the privacy labels of the required attributes (i.e., privacy preference of the category to which it belongs) are preferably compared with the relevant preference labels of the cards (i.e., the card-based preference setting of
The card-based and category-based approaches to privacy preference rule-making each have their own characteristics. In the card-based scheme, the preferences will be applied or assigned to the card as a whole and not for the attributes. In this sense, the card-based preference assignment is relatively agnostic regarding the attributes contained in the card. Each information card is associated with a respective rulest specified by the preference setting. For this scheme, the privacy control over the card attributes is more gross than fine-grained, since the preference setting is applied on the basis of the card, not the underlying attributes. Accordingly, while a card-based preference might typically be reflective of or commensurate with privacy interests of the underlying attributes, the preference setting nevertheless is specific to the card.
By comparison, in a category-based scheme, the preference is assigned to a category that is populated by attributes. Each attribute is mapped to one of the categories, allowing the user to exercise fine-grained control over the attributes and their preference assignments. In effect, by virtue of its category assignment, each attribute effectively has a preference mapped to it. Additionally, the user can map the preferences settings of the relevant categories, based on the attributes contained in the card, to the information card, making it portable with the card. The implementation for the category-based scheme is user-friendly.
Reference is now made to
A subject machine 210 receives a security policy from a relying party 212 (steps 250, 252). Receipt of the security policy by the browser 214 invokes a process 216 conducted by the identity selector (identity manager 20 of
The identity selector generates a token request based on the information card selected by the user (step 270). The token request is forwarded to the appropriate identity provider corresponding to the selected information card. The identity provider processes the token request, then issues and returns a security token to the identity selector (step 272). In turn, the identity selector presents the security token to the relying party in fulfillment of the security policy identity requirements (step 274).
The process of
According to another aspect of the invention, in reference to
Additionally, the privacy controls may be exercised on a per-card basis, particularly in regard to the cards deemed to satisfy the identity requirements of the security policy. For example, depending upon the transactional context and the nature of the specific interaction that calls for authentication, the invention may offer different privacy controls for different cards based on the sensitivity of the information pertaining to the cards. For example, potential disclosures of information having varying degrees of sensitivity vis-à-vis expected privacy protections will be addressed by proportionally measured privacy preferences to circumscribe the privacy expectations. For this purpose, the preferences editor of the invention allows the user to formulate privacy preferences, in the form of corresponding rulesets, that are card-specific and card-correlated. Thus, when the enforcement engine conducts the rules evaluation relative to a certain card, it applies the ruleset associated with that card.
Any means known to those skilled in the art can be used to implement user agent 10 and identity manager 20. For example, as a client program, the identity manager 20 can be configured to include and otherwise implement user agent 10, which itself is a client program. In general, user agent 10 and identity manager 20 are resident on a common host computing system 8 that the user engages and otherwise interacts with to access web services and resources from internet environment 28. Preferably, identity manager 20, and specifically identity selector 22, can be modified or otherwise adapted to integrate the privacy management modules of user agent 10. The privacy control process could then be readily and efficiently coordinated with the filtering of information cards relative to processing of the security policy.
The use of the invention can be further enhanced in connection with the user-centric identity management system described in
The user device 56 features a plug-in capability allowing it to connect to the user host machine (identity manager 20). Accordingly, the identity selector 22 resident on the host machine can access the information cards on the user device and use them in the same manner as the managed cards resident with the identity selector. If an information card imported from the user device is chosen for use in the authentication process, the identity selector sends an appropriate token request to the user device. The STS in the user device issues a security token in response to the token request, so that the user device effectively operates as an identity provider. The identity selector receives the issued security token from the user device, and uses it to respond to the request for a security token. In particular, the identity selector presents the security token to the relying party in proposed satisfaction of the identity requirements specified by the security policy.
According to the invention, the user can exercise privacy control management over the disclosure of any user identities that are based on the information cards stored on the user device and the security tokens issued by the STS resident on the user device. The manner of privacy control is similar to that discussed in connection with
The user portable device 50 is disclose in the co-pending applications indicated above in the Cross-Reference to Related Applications section herein.
Reference materials include the documents: “The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, W3C Recommendation 16 Apr. 2002,” with the latest version found at http://www.w3.org/TR/P3P/; and “A P3P Preference Exchange Language 1.0 (APPEL1.0), W3C Working Draft 15 Apr. 2002,” with the latest version found at http://www.w3.org/TR/P3P-preferences, both incorporated herein by reference thereto.
While this invention has been described as having a preferred methodology and design, the present invention can be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the invention using its general principles. Further, this application is intended to cover such departures from the present disclosure as come within known or customary practice in the art to which this invention pertains and which fall within the limits of the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4554141 *||May 14, 1984||Nov 19, 1985||Ethyl Corporation||Gas stream purification|
|US6898711 *||Jan 13, 1999||May 24, 2005||International Business Machines Corporation||User authentication system and method for multiple process applications|
|US7350139 *||Jun 16, 2000||Mar 25, 2008||American Express Travel Related Services Company, Inc.||System and method for utilizing a drag and drop technique to complete electronic forms|
|US7395244 *||Jun 23, 2004||Jul 1, 2008||Symantec Corporation||Criticality classification system and method|
|US7523071 *||Sep 16, 2003||Apr 21, 2009||Yahoo! Inc.||On-line software rental|
|US7703128 *||Feb 13, 2003||Apr 20, 2010||Microsoft Corporation||Digital identity management|
|US20040043758 *||Aug 29, 2002||Mar 4, 2004||Nokia Corporation||System and method for providing context sensitive recommendations to digital services|
|US20040215964 *||May 14, 2004||Oct 28, 2004||Doug Barlow||Configuring and managing resources on a multi-purpose integrated circuit card using a personal computer|
|US20050177731 *||Feb 9, 2004||Aug 11, 2005||International Business Machines Corporation||Secure management of authentication information|
|US20060179007 *||Nov 6, 2003||Aug 10, 2006||Visa U.S.A.||Centralized electronic commerce card transactions|
|US20060179404 *||Feb 8, 2005||Aug 10, 2006||Microsoft Corporation||Method for a browser auto form fill|
|US20080229411 *||Aug 22, 2007||Sep 18, 2008||Novell, Inc.||Chaining information card selectors|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8073783||Aug 22, 2007||Dec 6, 2011||Felsted Patrick R||Performing a business transaction without disclosing sensitive identity information to a relying party|
|US8079069||Mar 24, 2008||Dec 13, 2011||Oracle International Corporation||Cardspace history validator|
|US8083135||Jan 12, 2009||Dec 27, 2011||Novell, Inc.||Information card overlay|
|US8087060||Aug 22, 2007||Dec 27, 2011||James Mark Norman||Chaining information card selectors|
|US8353002||Nov 22, 2011||Jan 8, 2013||Apple Inc.||Chaining information card selectors|
|US8561172 *||Aug 29, 2008||Oct 15, 2013||Novell Intellectual Property Holdings, Inc.||System and method for virtual information cards|
|US8632003||Jan 27, 2009||Jan 21, 2014||Novell, Inc.||Multiple persona information cards|
|US8875997||Nov 30, 2011||Nov 4, 2014||Novell, Inc.||Information card overlay|
|US8893287 *||Mar 12, 2012||Nov 18, 2014||Microsoft Corporation||Monitoring and managing user privacy levels|
|US9015204 *||Jul 15, 2009||Apr 21, 2015||Hewlett-Packard Development Company, L.P.||Onboarding resources to an identity management system|
|US20130239220 *||Mar 12, 2012||Sep 12, 2013||Microsoft Corporation||Monitoring and Managing User Privacy Levels|
|Cooperative Classification||H04L63/08, G06F21/34, G06F21/6263, H04L63/20, H04L63/102|
|European Classification||H04L63/10B, H04L63/08, H04L63/20, G06F21/62B5B, G06F21/34|
|Jun 2, 2009||AS||Assignment|
Owner name: OPEN INVENTION NETWORK LLC, NORTH CAROLINA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AHN, GAIL-JOON;REEL/FRAME:022763/0711
Effective date: 20090526