Patent Application
20090077655
This invention pertains to performing on-line business transactions requiring identity information, and more particularly to processing identity information at an identity agent rather than a relying party.
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 for 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.) It is estimated that an average user has over 100 accounts on the Internet. For users, this is becoming an increasingly frustrating problem to deal with. Passwords and account names are too hard to remember. 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, and essentially no recourse after the fact.
Recently, the networking industry has developed the concept of information cards to tackle these problems. Information cards are a familiar metaphor for users and the idea is gaining rapid momentum. Information cards allow users to manage their identity information and control how it is released. This gives users greater convenience in organizing their multiple personae, their preferences, and their relationships with vendors and identity providers. Interactions with on-line vendors are greatly simplified. A system that uses information cards for identity purposes will referred to herein as an Identity Metasystem.
There are currently two kinds of information cards: 1) personal cards (or self-issued cards), and 2) managed cards—or cards that are issued by an identity provider. A personal card contains self-asserted identity information—the person issues the card and is the authority for the identity information it contains. The managed card is issued by an identity provider. The identity provider provides the identity information and asserts its validity.
When a user wants to release identity information to a relying party (i.e. a web site that the user is interacting with), a tool known as a card selector assists the user in selecting an appropriate information card. When a managed card is selected, the card selector communicates with the identity provider to obtain a security token that contains the needed information. This interaction between the card selector and the identity provider typically is secure. The identity provider is provided with authentication materials (such as username/password, X.509 certificate, etc.) to authenticate the user before it will return a security token.
As discussed above, it is common that a relying party takes the form of a web site. In order for a web site to act as a relying party, the web site must be altered from its standard form. Namely, the web site must place content on a web page which will trigger a web browser to invoke an information card selector. This trigger content is typically in the form of a hidden object within a form where the object's type is “application/x-informationCard”. When this object causes an information card selector to be invoked at the web browser, the resulting identity information is returned in the form of a response to a request for a security token. This security token requires there to be code at the web server which is capable of parsing the token, validating signatures, decomposing and evaluating its contents. All of these changes to the web site are needed, and require manual customization.
Other relying parties take the form of enterprise and legacy applications, which are comprised of some process which needs identity information input. These enterprise and legacy applications are also required to perform the tasks of parsing, validating, decomposing, and evaluating a security token. Therefore, these applications also must be considerably altered to participate as a relying party. Further, it may not even be possible to make the modifications to make these applications suitable to act as a relying party.
The above requirements on a web server or other application wishing to participate as a relying party present a roadblock to adoption of the Identity Metasystem. Therefore, a need remains for a way to address these and other problems associated with the prior art.
Embodiments of the invention address how identity information is obtained and processed. Embodiments of the invention include a method for providing identity information to a relying party by processing a security token at an identity agent rather than at the relying party. The invention uses HTML extensions and a web browser extension to trigger processing of the security token at the identity agent. The identity information from the security token can then be provided to the relying party in a form fill operation.
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.
Before explaining embodiments of the invention, it is important to understand the context.
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. Alternatively, 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. Relying party 130 can take the form of a web site. The web site includes content on a web page which will trigger a web browser (on computer system 105) to invoke an information card selector. The web page may include a web-based form for the user to enter identity 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 130. 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 130. 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. Alternatively, identity provider 135 might be a third party that is in the business of managing identity information on behalf of users.
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 username and password combination, the information cards that 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.
A card selector (described below with respect to
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 to 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 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 (also called a personal 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.
Once relying party 130 receives security token 160, relying party 130 parses the token, validates the signature, decomposes the contents, and evaluates the information provided in the security token 160. All of the steps required to obtain identity information from a security token, such as parsing, validating, and decomposing, may be collectively referred to as extracting the identity information from the token.
As described above, conventional implementations of the Identity Metasystem require a relying party to parse a security token, validate signatures, decompose the contents of the token, and associate the contents with the requested information. Thus, a conventional website must be altered considerably to participate as a relying party. However, according to embodiments of the invention, the Identity Metasystem can be implemented without requiring the relying party to perform all of these functions by moving the processing functions to the identity agent.
A person of ordinary skill in the art will appreciate that web page 305 comprises HTML code. The HTML code can include a plurality of HTML tags. These HTML tags control such features of the web page as how it is displayed and what links to other web pages will be included. As an example, the HTML code can include an input tag and the input tag can include various attributes, such as type, name, and size. Each of the input tag attributes may have a value. For example, the ‘type’ input tag attribute may have a value of ‘file’, indicating a file input type. The HTML code used to generate a portion of a web page including a form might look like the following:
The HTML tags and attributes that are supported by web browsers are generally defined in an HTML specification. Additional tags and attributes can be defined before being included in the HTML specification and these additional tags and attributes can be referred to generally as HTML extensions. HTML extensions are not required to be included in the HTML specification to be useful, as long as a web browser is capable of interpreting the HTML extensions. As described below, according to embodiments of the invention, HTML extensions can be used to implement the Identity Metasystem.
According to some embodiments of the invention, the Identity Metasystem can be implemented by moving the processing of security tokens to the identity agent. This is accomplished through three concepts: 1) extensions to HTML elements; 2) a web browser extension that, upon sensing the above extensions, performs form-fill or submit operations; and 3) a process (card selector invoker) which performs operations on security tokens that a traditional relying party would otherwise have to perform. Each of these is described below.
For purposes of triggering a web browser extension to perform the tasks traditionally performed by a relying party, a number of HTML extensions can be employed. One of ordinary skill in the art will appreciate that the extensions described below are examples and that any extension could be employed as long as it conveys information sufficient to allow a web browser extension (see Web Browser Extension below) to be triggered when a relying party is requesting identity information.
According to a first embodiment of the present invention, an HTML extension can be an input field attribute. The input field attribute can be called “claim”. The value of the input field attribute can be in the form of a Uniform Resource Identifier (URI). Claim URIs can be the actual claim names which will ultimately be requested by the web browser extension. Claim names identify some attribute of an identity. For example, a claim name can be the age of a user or the user's address.
HTML code to generate a form with an input field including a claim attribute might look like this:
In this case, the input field attributes “type”, “name”, and “size” are already included in the HTML specification. The input field attribute “claim” is an HTML extension. In the example shown above, the value of the “claim” input field attribute is “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/age”.
According to a second embodiment of the present invention, an HTML extension can be an input field element. The input field element can be a new element which is subordinate to the HTML input element. The input field element name can be “claim” and it can contain an attribute called “name”. The value of the name attribute is in the form of a URI and contains the claim name being requested. Other attributes and sub-elements of this claim element can be introduced to convey other information such as a list of preferred identity providers, a prioritization of claims, etc.
HTML code to generate a form with a claim input field element might look like this:
In this case, “claim” is the input field element, “name” is an attribute of the claim element, and “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/age” is the value of the attribute.
A further aspect of the present invention is that by providing standard claim names to be used with either the claim input field element or the claim input field attribute, the relying party can ensure that proper identity information is retrieved. Specifically, the card selector invoker will receive the claim names, obtain the appropriate identity information corresponding to the claim names, and then provide that identity information to the relying party. Thus, the relying party will receive the correct identity information for each claim, whereas in conventional systems, the relying party has to parse the security token and attempt to associate the provided identity information with the appropriate input fields.
By using the HTML extensions according to any of these embodiments, a relying party can easily modify a web page to use the Identity Metasystem. For example, the relying party could simply update the web page so that each input field includes either a “claim” attribute or a “claim” input field element, leaving responsibility for processing the security token and input of the fields to the card selector invoker. This is a much easier upgrade than incorporating new processing functionality to process security tokens by the relying party.
According to some embodiments, the web browser extension is triggered by the HTML extensions described above. The web browser detects the use of the HTML extensions, and invokes the web browser extension. Once triggered, the web browser extension gathers claims from the HTML extensions. In other words, the web browser extension finds claims in the web page (either as input field attributes or input field elements) and gathers the claims together. Next, the web browser extension calls the card selector invoker (the card selector invoker is further described below) with a list of the claims. As further described below, the card selector invoker will return a results list to the web browser extension. The web browser extension then performs form-fill or submit with the results from the card selector invoker. A person of ordinary skill in the art will appreciate that a submit operation can include an HTTP Post. The operations performed (whether form fill, submit, HTTP Post, or otherwise) at this step can be configurable and may depend on the claims in the web page.
According to embodiments of the invention, the web browser extension can use XHTML Embedding Attributes Modules to map the claims to the standard input fields. According to other embodiments, the web browser extension can use an online identity attribute dictionary to map the claims to the standard input fields.
By having the web browser extension handle the claim gathering and the form fill, the relying party only has to modify the web page to include the HTML extensions (as described above) and thus implementation of the Identity Metasystem is drastically simplified.
According to embodiments of the invention, the card selector invoker is called by the web browser using the web browser extension described above. Also, the card selector invoker can be called by any application, such as an enterprise or legacy application, that needs to make use of an information card to gather identity information. The card selector invoker performs the following tasks: takes as input the needed identity information as a list of claims; invokes the card selector with standard card selector inputs; receives a Request for Security Token Response (RSTR) from the card selector; extracts identity information from the RSTR; and returns claim value(s) to the caller (for example, the web browser or other application). The card selector invoker can also take as inputs additional information such as, but not limited to, a list of preferred identity providers, etc. The standard card selector inputs include, at a minimum, the claims being requested, but they may also include other items such as trusted identity providers, a security policy, etc.
As described above, according to some embodiments of the invention, the card selector invoker handles operations, such as security token parsing, validation, and decomposition, that conventionally have to be handled by the relying party. Therefore, these operations do not have to be implemented by the relying party in order to implement the Identity Metasystem. A person of ordinary skill in the art will appreciate that the card selector invoker can be incorporated into the web browser as a web browser extension. Alternatively, the card selector invoker can be a separate application on the identity agent that communicates with the web browser.
As described above, some embodiments of the invention displace certain processing, which conventionally takes place at a relying party, to the identity agent (the party which acts with the information card selector). This approach can be generalized to any embodiment of the Identity Metasystem. Specifically, an enterprise or legacy application could request data from a client application where that data is not in the form of a security token. The client application could bear the work of causing an information card selector to be invoked, and the subsequent work of parsing, validating, evaluating, etc. the data returned in the security token, and then return the appropriate data to the relying party (which is an enterprise or legacy application).
According to embodiments of the invention, a relying party can implement the Identity Metasystem by simply adding claims (either as input field elements or input field attributes) to a web page that requests information from an identity agent. All of the other necessary processing is carried out at the identity agent using a web browser extension and a card selector invoker. Thus, widespread adoption of the Identity Metasystem is facilitated.
Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles, and may 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 may 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 may come within the scope and spirit of the following claims and equivalents thereto.
This patent application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/973,679, filed Sep. 19, 2007, which is hereby incorporated by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60973679 | Sep 2007 | US |
