Source: http://www.docstoc.com/docs/118681760/Identity-Providers-In-Digital-Identity-System---Patent-8104074
Timestamp: 2013-06-20 00:54:19
Document Index: 659569121

Matched Legal Cases: ['arty11', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'art 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty 120', 'arty120', 'arty 120']

Identity Providers In Digital Identity System - Patent 8104074 Abstract
Inventors:Kim Cameron; Arun K. Nanda
Primary Examiner:Srivastava; Vivek
Assistance Examiner:Truong; Thong
Attorney, Agent of firm:Merchant & Gould PC
US Patent Application: 11/361,281
Patent number: 8104074
Other US Classes:Electrical Computers And Digital Processing Systems: Multicomputer Data Transferring (709/229)Electrical Computers And Digital Processing Systems: Support (713/170)
International Classes:H04L 29/0(20060101)
Tags:Identity providers in digital identit..., Cameron, et al., Kim Cameron, Arun K. Nanda, Application number 11 361-281, Information Security, Electrical Computers And Digital Proc..., Electrical Computers And Digital Proc...
5442704 Secure memory card with programmed controlled security access controlHoltey8/1/1995
5659616 Method for securely using digital signatures in a commercial cryptographic systemSudia8/1/1997
5678015 Four-dimensional graphical user interfaceGoh10/1/1997
5887131 Method for controlling access to a computer system by utilizing an external device containing a hash value representation of a user passwordAngelo3/1/1999
5907838 Information search and collection method and systemMiyasaka et al.5/1/1999
5995625 Electronic cryptographic packingSudia11/1/1999
6005939 Method and apparatus for storing an internet user's identity and access rights to world wide web resourcesFortenberry et al.12/1/1999
6016476 Portable information and transaction processing system and method utilizing biometric authorization and digital certificate securityMaes1/1/2000
6161125 Generic schema for storing configuration information on a client computerTraversat et al.12/1/2000
6442532 Wireless transaction and information systemKawan8/1/2002
6526434 System and method for efficient transfer of data blocks from client to serverCarlson2/1/2003
6754829 Certificate-based authentication system for heterogeneous environmentsButt6/1/2004
6785810 System and method for providing secure transmission, search, and storage of dataLirov et al.8/1/2004
6791583 System and method for providing spatially distributed device interactionTang9/1/2004
6802002 Method and apparatus for providing field confidentiality in digital certificatesCorella10/1/2004
6810480 Verification of identity and continued presence of computer usersParker et al.10/1/2004
6817521 Credit card application automation systemMatada11/1/2004
6836765 System and method for secure and address verifiable electronic commerce transactionsSussman12/1/2004
6839690 System for conducting business over the internetFoth1/1/2005
6879769 Device for processing recorded information and storage medium storing program for sameKawai et al.4/1/2005
6934841 Smart card controlled internet accessBoyles et al.8/1/2005
6934913 Graphical data entry screenLe et al.8/1/2005
6955295 Card issuing systemHosogoe10/1/2005
6957338 Individual authentication system performing authentication in multiple stepsSumino10/1/2005
6981043 Apparatus and method for managing multiple user identities on a networked computer systemBotz12/1/2005
6993659Independent biometric identification systemMilgramm et al.1/1/2006
7000108System, apparatus and method for presentation and manipulation of personal information syntax objectsYarsa2/1/2006
7007298Apparatus and method for authenticating user according to biometric informationShinzaki et al.2/1/2006
7020474System and method for securing short-distance wireless communications, and applications thereofScott3/1/2006
7020778Method for issuing an electronic identityMiettinen3/1/2006
7047418Imaging method and device using biometric information for operator authenticationFerren et al.5/1/2006
7069447Apparatus and method for secure data storageCorder6/1/2006
7083095System for automatic connection to a networkHendrick8/1/2006
7103773Message exchange in an information technology networkErickson et al.9/1/2006
7131583Systems, methods, and apparatus for instant issuance of a credit cardJaros11/1/2006
7146159Over-the-air card provisioning system and methodZhu12/1/2006
7162475Method for user verification and authentication and multimedia processing for interactive database management and method for viewing the multimediaAckerman1/1/2007
7162581Deferred tuple space programming of expansion modulesNewman1/1/2007
7206432Extracting embedded information from digital image dataIwamura4/1/2007
7231371Method and system for ordering and delivering digital certificatesCantini6/1/2007
7266705Secure transmission of data within a distributed computer systemPeck et al.9/1/2007
7356837Centralized identification and authentication system and methodAsghari-Kamrani4/1/2008
7409543Method and apparatus for using a third party authentication serverBjorn8/1/2008
7424457Managing an electronic seal of certificationKhaishgi9/1/2008
7451921Methods, smart cards, and systems for providing portable computer, VoIP, and application servicesDowling11/1/2008
7475429Method of invisibly embedding into a text document the license identification of the generating licensed softwareCarro1/1/2009
7680819Managing digital identity informationMellmer3/1/2010
7788499Security tokens including displayable claimsCameron8/1/2010
0N/ATsakiris10/1/2001
0N/AHoornaert et al.12/1/2001
0N/AEbara1/1/2002
0N/AIeta2/1/2002
0N/ALang4/1/2002
0N/ALyons8/1/2002
0N/AMcLean et al.9/1/2002
0N/ALucovsky et al.9/1/2002
0N/ANichols et al.11/1/2002
0N/ABialick12/1/2002
0N/AKianian12/1/2002
0N/ABrickell1/1/2003
0N/AButler1/1/2003
0N/ABhogal3/1/2003
0N/AAsghari-Kamrani3/1/2003
0N/AWang3/1/2003
0N/AMcCormack4/1/2003
0N/AChevrel et al.7/1/2003
0N/AYared et al.8/1/2003
0N/AAbela9/1/2003
0N/AFaybishenko9/1/2003
0N/AWesley10/1/2003
0N/AWang et al.10/1/2003
0N/AAckerman10/1/2003
0N/AMcBrearty11/1/2003
0N/AHardt12/1/2003
0N/AKeeler12/1/2003
0N/ASingh et al.1/1/2004
0N/AWest3/1/2004
0N/AAngelo et al.4/1/2004
0N/ARonaghi5/1/2004
0N/ABand5/1/2004
0N/AKrantz et al.6/1/2004
0N/ATimmins6/1/2004
0N/AMoore6/1/2004
0N/ACross8/1/2004
0N/AHurvig10/1/2004
0N/ASpelman et al.11/1/2004
0N/AHamid12/1/2004
0N/AMellmer2/1/2005
0N/ANaka3/1/2005
0N/AKammler3/1/2005
0N/ABouron3/1/2005
0N/AWugofski4/1/2005
0N/ACameron4/1/2005
0N/AYung5/1/2005
0N/ACameron5/1/2005
0N/ACromer6/1/2005
0N/AErnst et al.6/1/2005
0N/AMichaelides6/1/2005
0N/AShaw et al.6/1/2005
0N/AZacharia7/1/2005
0N/AKizawa7/1/2005
0N/ARemo8/1/2005
0N/AGrossman et al.8/1/2005
0N/ANash8/1/2005
0N/ASo9/1/2005
0N/AHardt12/1/2005
0N/AHardt1/1/2006
0N/ADenman et al.1/1/2006
0N/ADowling3/1/2006
0N/ADiez4/1/2006
0N/ALe Saint et al.5/1/2006
0N/AGaines et al.6/1/2006
0N/ADua7/1/2006
0N/ABrown8/1/2006
0N/ARoever8/1/2006
0N/ACameron9/1/2006
0N/AGil et al.9/1/2006
0N/ASchaufele et al.9/1/2006
0N/ADunn10/1/2006
0N/ADixon11/1/2006
0N/AKarchov12/1/2006
0N/ALibin1/1/2007
0N/ARutter et al.5/1/2007
0N/AChevrel5/1/2007
0N/ACameron et al.6/1/2007
0N/ADidier et al.8/1/2007
0N/ACameron8/1/2007
0N/ACameron et al.8/1/2007
0N/AAnttila12/1/2007
0N/ANanda1/1/2008
0N/AWahl2/1/2008
0N/ALanc5/1/2008
0N/AGajjala7/1/2008
0N/AShewchuk7/1/2008
0N/ACameron et al.11/1/2008
0N/ALeopold et al.9/1/2010
0N/AMonden11/1/2010
Local Identity Providers
Digital identity in Albania_1
IDENTITY _ ACCESS IDENTITY _ ACCESS - Global Access Partners
ECW97R3
2012 - PKI in Government Digital Identity Management Systems
alkhouri26
uhs127974
Claims What is claimed is: 1. A digital identity system, the digital identity system comprising a first computer, the first computer associated with a principal, the first computer comprising storagemedia that store computer readable instructions, execution of the computer readable instructions causing the first computer to: store a first digital identity at the first computer, the first digital identity associated with the principal and a firstidentity provider, the first digital identity comprising a first XML document, the first XML document containing a first claim list, the first claim list specifying claims that the first identity provider is able to provide; store a second digitalidentity at the first computer, the second digital identity associated with the principal and a second identity provider, the second digital identity comprising a second XML document, the second XML document containing a second claim list, the secondclaim list specifying claims that the second identity provider is able to provide; after storing the first digital identity and the second digital identity at the first computer, send a request to a relying party; receive a security policy from therelying party in response to the request, the security policy comprising a third XML document, the third XML document specifying a security token type required by the relying party and specifying required claims; in response to receiving the securitypolicy, automatically determine, based on a review of the claims specified by the first claim list and the second claim list, that the first claim list specifies each of the required claims; after determining that the first claim list specifies each ofthe required claims, send a first token request to the first identity provider, the first token request requesting a first security token, the first token request indicating one or more of the required claims specified by the security policy; receivethe first security token from the first identity provider, the first security token including a third claim list, the third claim list including the one or more required claims specified by the security policy, the first security token being of thesecurity token type specified by the security policy; and forward the security token to the relying party. 2. The digital identity system of claim 1, wherein one or more of the claims in the security token are semantically altered relative to claims provided by the first identity provider. 3. The digital identity system of claim 2, wherein the claims included in the first security token are semantically altered so that the claims in the first security token reveal less personal information about the principal than the claimsprovided by the first identity provider. 4. The digital identity system of claim 2, wherein execution of the computer readable instructions further causes the first computer to: send a second token request to the first identity provider, the second token request requesting a secondsecurity token; and receive the second security token, the second security token being of a different security token type. 5. The digital identity system of claim 1, wherein the first computer receives the first security token from a second computer, the second computer associated with the identity provider. 6. The digital identity system of claim 1, wherein the first security token includes a computational token and a display token, the computational token including the claims in the third claim list in an encrypted format, the display tokenincluding at least a summary of the claims in the third claim list, the summary in a format that can be reviewed by the principal. 7. The digital identity system of claim 1, wherein the first digital identity includes an inline image that provides a graphical image for the digital identity that can be displayed in user interfaces, a friendly name for the digital identity,and a friendly name for the issuer of the digital identity; and wherein execution of the computer readable instructions further cause the first computer to display the graphical image, the friendly name for the digital identity, and the friendly namefor the issuer of the digital identity to the principle. 8. The digital identity system of claim 1, wherein prior to storing the first digital identity and the second digital identity, execution of the computer readable instructions further causes the first computer to: send a first digital identityrequest to the first identity provider; receive the first digital identity from the first identity provider in response to the first digital identity request; send a second digital identity request to the second identity provider; and receive thesecond digital identity from the second identity provider in response to the second digital identity request. 9. A method for providing a digital identity, the method comprising: sending, by a first computer, a digital identity to a second computer, the first computer associated with an identity provider, the second computer associated with aprincipal, the digital identity comprising a first XML document that contains a listing of claims that an identity provider is able to provide, the digital identity being an artifact that represents a token issuance relationship between the principal andthe identity provider; after sending the digital identity to the second computer, receiving, by the first computer, a token request from the second computer, the token request requesting a security token, the token request comprising a second XMLdocument, the second XML document specifying one or more of the claims indicated by the digital identity, the second XML document specifying a security token type; in response to receiving the token request, generating, by the first computer, claimsspecified by the second XML document; after generating the claims, transforming, by the first computer, the claims; after transforming the claims, generating, by the first computer, the security token, the security token including the claims specifiedby the second XML document, the security token being of the security token type specified by the second XML document; and sending, by the first computer, the security token to the second computer in response to the request. 10. The method of claim 9, wherein transforming the claims comprises altering, by the first computer, the claims included in the security token semantically. 11. The method of claim 10, wherein altering the claims further comprises altering, by the first computer, the claims so that the claims reveal less personal information about the principal. 12. The method of claim 9, wherein transforming the claims comprises formatting, by the first computer, the claims from one format into another format. 13. The method of claim 9, further comprising: sending, by the second computer, a request to a relying party for a security policy; receiving, by the second computer, the security policy from a third computer, the third computer associatedwith the relying party, the security policy comprising a third XML document, the third XML document specifying the security token type as being required by the relying party and specifying the one or more claims related to the identity of the principal; sending, by the second computer, the request for the claims to the first computer; and after receiving the security token from the first computer, forwarding, by the second computer, the security token to the third computer. 14. The method of claim 13, further comprising: receiving, by the second computer, a selection by the principal of a given digital identity of the principal from among a plurality of digital identities of the principal stored at the secondcomputer, each digital identity in the plurality of digital identities comprising an XML document that represents a token issuance relationship between the principal and a particular identity provider; and selecting, by the second computer, the identityprovider based on the given digital identity. 15. The method of claim 9, wherein generating the security token further includes generating, by the first computer, the security token to include a computational token and a display token, the computational token including the claims in anencrypted format, the display token including at least a summary of the claims in a format that can be reviewed by the principal. 16. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by a first computer, cause the first computer to: send a digital identity to a principal, the digital identity comprising afirst XML document, the first XML document containing: a listing of claims that an identity provider is able to provide, a globally unique identifier for the digital identity, a date and time when the digital identity was issued, a hint to be displayedto the principle to help provide a right credential, an unambiguous description of credential to use for authenticating to the identity provider, an inline image that provides a graphical image for the digital identity that can be displayed in userinterfaces, a date and time after which the digital identity is expired, a friendly name for the digital identity, and a friendly name for the issuer of the digital identity, and a list of token types that the identity provider can issue; wherein thedigital identity being an artifact that represents a token issuance relationship between the principal and the identity provider; after sending the digital identity to the principal, receive a token request from a second computer, the second computerassociated with the principal, the token request requesting a security token, the token request comprising a second XML document, the second XML document specifying one or more requested claims, the requested claims related to an identity of theprincipal, the requested claims being among the claims in the listing of claims contained by the digital identity, the second XML document specifying a security token type; generate the requested claims in a first format; transform the requested claimssuch that the requested claims are formatted in a second format and such that the requested claims are altered semantically such that the requested claims reveal less personal information about the principal, the second format being a format required bythe relying party, the second format being different from the first format; after transforming the requested claims into the second format, encrypt the requested claims; after encrypting the requested claims, generate the security token, the securitytoken including a computational token and a display token, the computational token being of the security token type specified by the second XML document, the computational token including the requested claims, the display token including each of therequested claims in a format that can be reviewed by the principal, the display token cryptographically bound to the computational token; and send the security token to the second computer. Description COPYRIGHT NOTICE A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as itappears in the United States Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.BACKGROUND Identity is an important component enabling interactions in everyday life. For example, an individual's credit card enables merchants to identify and allow the individual to purchase products and services on credit. The same is true in thedigital world, where digital identities enable digital interactions. For example, digital identities can be used to authenticate parties to each other in the digital environment. Knowing with whom one is interacting is an important element in decidingwhether or not to trust and provide information to a party. An entity can use a digital identity to authenticate a party's identity or other personal information about the party. A digital identity can be issued by another entity, such as a trusted third party, and can include information about theparty. Examples of such information include the party's name, address, social security number, age, telephone number, etc. A party can have multiple digital identities issued by one or more other entities, similar to that of an individual having adriver's license, a credit card, and a frequent flyer card. In the online environment, a third party, such as an online service, can require that a party authenticate its identity before the third party allows the party to access goods or services. In order to authenticate its identity, the party canforward to the third party a digital identity in the form of a security token issued by another entity trusted by the third party. Once authentication is complete, the third party can provide access to the goods or services requested by the party. In typical systems, it is necessary for the party to manually collect all of the security tokens required by the third party and then provide the information to the third party for authentication. In many cases, the party has little or noability to control the contents of a security token issued by another entity. When the party shares a security token with a third party during authentication of the party's identity, the party's privacy can become a concern. For example, the party canunknowingly share personal information in the security token with the third party that the party does not need to share for authentication. In addition, the party can unknowingly provide personal information that the party does not want to share withthe third party (e.g., social security number, telephone number, etc.).SUMMARY This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subjectmatter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. One aspect relates to a digital identity system including a principal including an identity selector programmed to receive a security policy from a relying party, review a plurality of digital identities associated with the principal, andrequest one or more claims related to an identity of the principal from an identity provider. The principal is further programmed to receive one or more security tokens including the claims from the identity provider, and to forward the security tokensto the relying party. Another aspect relates to method for providing a digital identity, the method including: receiving a request for one or more claims related to an identity of a principal; providing the claims; transforming the claims; and generating a securitytoken including the claims. Another aspect relates to a computer-readable medium having computer-executable instructions for performing steps including: receiving a request for one or more claims related to an identity of a principal; providing the claims; transforming theclaims; and generating a security token including the claims. DESCRIPTION OF THE DRAWINGS Reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein: FIG. 1 illustrates an example digital identity system including a principal, a relying party, and an identity provider; FIG. 2 illustrates a portion of the system of FIG. 1; FIG. 3 illustrates an example computer system of the principal of FIG. 1 programmed to review and select one of a plurality of digital identities; FIG. 4 illustrates another portion of the system of FIG. 1; FIG. 5 illustrates an example security token; FIG. 6 illustrates another portion of the system of FIG. 1; FIG. 7 illustrates an example method for authentication; FIG. 8 illustrates an example method for forwarding a request for one or more claims to an identity provider; and FIG. 9 illustrates an example method for generating a security token including one or more claims.DETAILED DESCRIPTION Example embodiments will now be described more fully hereinafter with reference to the accompanying drawings. These embodiments are provided so that this disclosure will be thorough and complete. Like numbers refer to like elements throughout. Example embodiments disclosed herein relate generally to digital identity systems including digital identities that can be exchanged between a first party and a second party to authenticate an identity and/or information related to the firstparty. In example embodiments herein, the first party can be an individual, a company, an organization, a computer or other device, a service, or any other type of entity. The first party is referred to herein as the principal. In example embodiments,the second party can be an individual, a company, an organization, a computer or other device, a service, or any other type of entity. The second party has goods, services, or other information that the principal desires to access and/or obtain. Thesecond party is referred to herein as the relying party. In example embodiments disclosed herein, digital identity systems enable the exchange of digital identities between parties across different subsystems using different technologies. Generally, the parties/subsystems of these example digitalidentity systems can include one or more of the following attributes: security policies--the ability to specify a set of claims required by a relying party and the issuer of such claims in order to authenticate a principal's identity; negotiation--theability for the various parties of the digital identity system to make agreements regarding mutually acceptable technologies, claims, and other requirements; encapsulation--the ability to exchange requirements and claims in a technology-neutral waybetween parties/subsystems; and transformation--the ability to translate claims between technologies and semantically. One or more of these attributes can be found in the digital identity systems described below. Referring now to FIG. 1, an example digital identity system 100 is shown including a principal 110 and a relying party 120. Principal 110 and relying party 120 can communicate with each other over one or more networks, such as the Internet 112. In example embodiments, principal 110 can request goods, services, or other information from relying party 120. Relying party 120 can require authentication of the identity of or information about principal 110 before or in conjunction with providingthe requested goods, services, or information to principal 110. Also shown in FIG. 1 is an example identity provider 115 including a claims transformer 130 and a claims authority 140. The claims transformer 130 is sometimes referred to as a "security token service." In the example shown, identity provider115 can provide one or more claims about principal 110. A claim is a statement or assertion made about the principal related to the principal's identity or information about the principal such as, for example, name, address, social security number, age,etc. As described further below, identity provider I 15 can provide claims to principal 110 and/or relying party 120 in the form of a signed security token. In example embodiments, identity provider 115 is in a trusted relationship with relying party120, so that relying party 120 trusts the claims in the signed security token from identity provider 115. Although claims transformer 130 and claims authority 140 of identity provider 115 are shown as separate entities in FIG. 1, in alternative embodiments claims transformer 130 and claims authority 140 can be the same entity or different entities. In example embodiments disclosed herein, system 100 is implemented as an InfoCard system provided in the WINFX application programming interface developed by Microsoft Corporation of Redmond, Wash. The InfoCard system allows principals tomanage multiple digital identities from various identity providers. The InfoCard system utilizes a web services platform such as the Windows Communication Foundation in the WINFX application programming interface. In addition, the InfoCard system is built using the Web Services Security Specificationspropagated at least in part by Microsoft Corporation of Redmond, Wash. These specifications include a message security model WS-Security, an endpoint policy WS-SecurityPolicy, a metadata protocol WS-MetadataExchange, and a trust model WS-Trust. Generally, the WS-Security model describes how to attach security tokens to messages. The WS-SecurityPolicy model describes end point policy requirements, such as required security tokens and supported encryption algorithms. Such policy requirementscan be conveyed and negotiated using a metadata protocol defined by WS-MetadataExchange. The WS-Trust model describes a framework for trust models that enables different web services to interoperate. Example embodiments described herein refer to the Web Services Security Specifications described above. In alternative embodiments, one or more other specifications can be used to facilitate communications between the various subsystems insystem 100. In example embodiments, principal 110, relying party 120, and identity provider 115 can each utilize one or more a computer systems. Each computer system includes one or more of volatile and non-volatile computer readable media. Computerreadable media includes storage media, as well as removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. The computersystem also includes communication media that typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any informationdelivery media. Communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within thescope of computer readable media. The computer system includes an operating system, such as the WINDOWS operating system from Microsoft Corporation, and one or more programs stored on the computer readable media. The computer system also includes one or more input and outputcommunications devices that allow the user to communicate with the computer system, as well as allow the computer system to communicate with other devices. Communications between the computer systems used by principal 110, relying party 120, andidentity provider 115 can be implemented using wired and/or wireless technologies. Referring now to FIG. 2, example principal 110 and relying party 120 are again shown. In the example shown, principal 110 sends a request to relying party 120 for goods, services, or other information. For example, in one embodiment, principal110 sends a request to relying party 120 for access to information from relying part 120 that principal 110 desires. The request sent by principal 110 can include a request for the authentication requirements of relying party 120 using, for example, the mechanisms provided in WS-MetadataExchange. In response to the request, relying party 120 sends principal110 requirements for relying party 120 to authenticate its identity or other information about principal 110. The requirements of relying party 120 for authentication are referred to herein as a security policy. The security policy defines the set ofclaims from a trusted identity provider that the principal 110 must provide to relying party 120 for relying party 120 to authenticate principal 110. In one example, relying party 120 specifies its security policy using WS-SecurityPolicy, including both the claim requirements and type of security token required by relying party 120. A basic form for a security policy in accordance withWS-SecurityPolicy is illustrated in the example below. TABLE-US-00001 <sp:IssuedToken ...> <sp:RequestSecurityTokenTemplate> <wst:TokenType> urn:oasis:names:tc:SAML:1.0:assertion </wst:TokenType> <wst:Claims wst:Dialect="http://schemas.microsoft.com/ws/2005/05/identity"> <ic:Claim URI="http://.../ws/2005/05/identity/claims/givenname"/> <wst:Claims> </sp:RequestSecurityTokenTemplate> </sp:IssuedToken> In this example, one claim regarding the given name of the principal is required by the security policy for authentication. Examples of other types of claims include, without limitation, the following: First Name--Type: xs:string--preferredname or first name of a subject; Last Name--Type: xs:string--surname or family name of a subject; Email Address--Type: xs:string--preferred address for the "To:" field of email to be sent to the subject, usually of the form <user>@<domain>;Street Address--Type: xs:string--street address component of a subject's address information; Locality Name or City--Type: xs:string--locality component of a subject's address information; State or Province--Type: xs:string--abbreviation for state orprovince name of a subject's address information; Postal Code--Type: xs:string--postal code or zip code component of a subject's address information; Country--Type: xs:string--country of a subject; Primary or Home Telephone Number--Type:xs:string--primary or home telephone number of a subject; Secondary or Work Telephone Number--Type: xs:string--secondary or work telephone number of a subject; Mobile Telephone Number--Type: xs:string--mobile telephone number of a subject; Date ofBirth--Type: xs:date--the date of birth of a subject in a form allowed by the xs:date data type; Gender--Type: xs:token--gender of a subject that can have any of these exact string values--"Male," "Female" or "Unspecified;" and Private PersonalIdentifier--Type: xs:base64binary--indicates a private identifier that identifies the subject to a relying party. The security policy can also be used to specify the type of security token required by relying party 120, or a default type can be used as determined by the identity provider. For example, the above-noted policy specifies a certain type ofsecurity token that is required by relying party 120 (see the "wst:TokenType" element). In addition to specifying the required claims and token type, the security policy can specify a specific identity provider required by the relying party (see the "sp:Issuer" element), as shown below. TABLE-US-00002 <sp:IssuedToken sp:Usage="xs:anyURI" sp:IncludeToken="xs:anyURI" ...> <sp:Issuer> <!-- Identity provider's service endpoint --> </sp:Issuer> <sp:RequestSecurityTokenTemplate> ... </sp:RequestSecurityTokenTemplate> <wsp:Policy> ... </wsp:Policy> ... </sp:IssuedToken> The policy can omit this element, leaving the determination of the appropriate identity provider up to principal 110. Other elements can be specified in the security policy as well such as, for example, the freshness of the required securitytoken. In some embodiments, principal 110 can require that relying party 120 identify itself to principal 110 so that principal 110 can decide whether or not to satisfy the security policy of relying party 120, as described below. In one example,relying party 120 identifies itself using an X509 certificate. In other embodiments, relying party 120 can identify itself using other mechanisms such as, for example, a Secure Sockets Layer ("SSL") server certificate. For example, in one embodiment, endpoint verification of relying party 120 is provided using the provisions in WS-Addressing, such as the "wsid:Identity" element in the example X509v3 certificate shown below: TABLE-US-00003 <wsa:EndpointReference> <wsa:Address>http://...</wsa:Address> <wsid:Identity> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>...</ds:X509Certificate> </ds:X509Data></ds:KeyInfo> </wsid:Identity> </wsa:EndpointReference> Referring now to FIG. 3, an example computer system 300 of principal 110 includes one or more digital identities 310 for principal 110. These digital identities 310 (sometimes referred to as "InfoCards" in the InfoCard system provided in theWINFX application programming interface developed by Microsoft Corporation of Redmond, Wash.) are artifacts that represent the token issuance relationship between principal 110 and a particular identity provider, such an identity provider 115. In theexamples shown, each digital identity 310 corresponds to a particular identity provider, and principal 110 can have multiple digital identities 310 from the same or different identity providers. Digital identities 310 can include, among other information, the identity provider's issuance policy for security tokens, including the type of tokens that can be issued, the claim types for which it has authority, and/or the credentials to usefor authentication when requesting security tokens. In example embodiments, digital identities 310 are represented as XML documents that are issued by identity providers 115 and stored by principals 110 on a storage device such as computer system 300. An example format for a digital identity 310 is provided below. TABLE-US-00004 <ic:InfoCard xml:lang="xs:language"? ...> <ic:InfoCardReference> <ic:CardId> xs:anyURI </ic:CardId> <ic:CardVersion> xs:unsignedInt </ic:CardVersion> ? </ic:InfoCardReference><ic:CardName> xs:string </ic:CardName> ? <ic:CardImage MimeType= "xs:string"> xs:base64Binary </ic:CardImage> ? <ic:IssuerName> xs:string </ic:IssuerName> <ic:TimeIssued> xs:dateTime </ic:TimeIssued><ic:TimeExpires> xs:dateTime </ic:TimeExpires> ? <ic:TokenServiceReference> (<ic:TokenService> <wsa:EndpointReference ...> ... </wsa:EndpointReference> <ic:CredentialHint>xs:string</ic:CredentialHint> ? (<ic:UserNamePasswordAuthenticate>... </ic:UserNamePass wordAuthenticate> | <ic:KerberosV5Authenticate>... </ic:KerberosV5Authenticate> | <ic:X509V3Authenticate>... </ic:X509V3Authenticate> |<ic:SelfIssuedAuthenticate>... </ic:SelfIssuedAuthenticate> ) </ic:TokenService>) + </ic:TokenServiceReference> <ic:InfoCardPolicy> <ic:SupportedTokenTypes> <ic:TokenType URI="xs:anyURI" /> +</ic:SupportedTokenTypes> <ic:SupportedClaims> (<ic:SupportedClaim URI="xs:anyURI"> <ic:DisplayTag> xs:string </ic:DisplayTag> ? <ic:Description> xs:string </ic:Description> ? </ic:SupportedClaim>) +</ic:SupportedClaims> <ic:RequireAppliesTo /> ? </ic:InfoCardPolicy> ... </ic:InfoCard> The following describes the elements/attributes of the digital identity format shown above: /ic:InfoCard--an InfoCard issued by an identity provider; /ic:InfoCard/@xml:lang--an optional language identifier, using the language codes specified in[RFC 3066]; /ic:InfoCard/ic:InfoCardReference--a specific reference for the InfoCard that should be used in future requests for security tokens from the identity provider based on that InfoCard; /ic:InfoCard/ic:InfoCardReference/ic:CardId--this elementprovides a globally unique identifier in the form of a URI for the specific InfoCard; /ic:InfoCard/ic:InfoCardReference/ic:CardVersion--this optional element provides a versioning epoch for the InfoCard issuance infrastructure used by the identityprovider; /ic:InfoCard/ic:CardName--this optional element provides a friendly textual name for the issued InfoCard; /ic:InfoCard/ic:CardImage--this optional element contains a base64 encoded inline image that provides a graphical image for the issuedInfoCard that can be displayed in user interfaces; /ic:InfoCard/ic:CardImage/@MimeType--this attribute provides a MIME type specifying the format of the included logo image; /ic:InfoCard/ic:IssuerName--this element provides a friendly name for the issuerof the InfoCard; /ic:InfoCard/ic:TimeIssued--this element provides the date and time when the InfoCard was issued; /ic:InfoCard/ic:TimeExpires--this optional element provides the date and time after which the InfoCard should be treated as expired andinvalid; /ic:InfoCard/ic:TokenServiceReference--this element provides an ordered list of child elements that specify the security token service endpoints, the corresponding authentication method and credentials needed to request security tokens;/ic:InfoCard/ic:TokenServiceReference/ic:TokenService--this element provides a security token service reference; /ic:lnfoCard/ic:TokenServiceReference/ic:TokenService/wsa:EndpointReferen- ce--this element provides the endpoint reference for the securitytoken service; /ic:InfoCard/ic:TokenServiceReference/ic:TokenService/ic:Credent- ialHint--this optional element provides a hint (string) to be displayed to the user to help provide the right credential;/ic:InfoCard/ic:TokenServiceReference/ic:TokenService/<credential selector element>--this element provides an unambiguous description of the credentials to use for authenticating to the security token service, with example credential typesincluding Kerberos, X509, or self-issued credentials; /ic:InfoCard/ic:InfoCardPolicy--this element provides the token issuance policy of the identity that allows a principal to determine if the InfoCard satisfies a relying party's token requirements ina given interaction; /ic:InfoCard/ic:InfoCardPolicy/ic:SupportedTokenTypes--this element contains the list of token types, as child elements, that the identity provider can issue; /ic:InfoCard/ic:InfoCardPolicy/ic:SupportedTokenTypes/ic:TokenType (one ormore)--this element indicates an individual token type that is supported; /ic:InfoCard/ic:InfoCardPolicy/ic:SupportedClaims--this element contains the list of claim types, as child elements, that the identity provider can provide in security tokens;/ic:InfoCard/ic:InfoCardPolicy/ic:SupportedClaims/ic:SupportedClaim (one or more)--this element indicates an individual claim type that is supported; and /ic:InfoCard/ic:InfoCardPolicy/ic:RequireAppliesTo--this optional empty element indicates that theservice requester (InfoCard system) must submit the relying party identity to the identity provider. An example digital identity is provided below. TABLE-US-00005 <InfoCard xmlns="http://schemas..." xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy" xml:lang="en-us"> <InfoCardReference><CardId>http://...</CardId> </InfoCardReference> <CardName>...</CardName> <CardImage MimeType="image/gif"> ... </CardImage> <IssuerName>XYZ Identity Provider</IssuerName><TimeIssued>2003-08-24T00:30:05Z</TimeIssued> <TokenServiceReference> <TokenService> <wsa:EndpointReference> <wsa:Address>http://...</wsa:Address> <wsid:Identity> <ds:KeyInfo> <ds:X509Data><ds:X509Certificate>...</ds: X509Certificate> </ds:X509Data> </ds:KeyInfo> </wsid:Identity> </wsa:EndpointReference> <UserNamePasswordAuthenticate> <Username>...</Username></UserNamePasswordAuthenticate> </TokenService> </TokenServiceReference> <ic:InfoCardPolicy> <SupportedTokenTypes> <TokenType URI= "urn:oasis:names:tc:SAML:1.0:assertion"/> </SupportedTokenTypes><SupportedClaims> <SupportedClaim URI="http://.../ws/2005/05/identity/claims/givenname"> <DisplayTag>Given Name</DisplayTag> </SupportedClaim> <SupportedClaim URI="http://.../ws/2005/05/identity/ claims/surname"><DisplayTag>Last Name</DisplayTag> </SupportedClaim> </SupportedClaims> <RequireAppliesTo /> </ic:InfoCardPolicy> </InfoCard> In the example above, the digital identity is issued by "XYZ Identity Provider," and the digital identity states that XYZ Identity Provider supports the Security Assertion Markup Language ("SAML") token type ("SupportedTokenTypes" element)provided in accordance with the SAML standard promulgated by the Organization for the Advancement of Structured Information Standards ("OASIS"). In addition, the digital identity states that XYZ Identity Provider can provide two claims("SupportedClaims" element--including "givenname" and "surname"), requires the relying party's identity be included in the token request ("RequireAppliesTo" element), and requires authentication based on username/password when requesting security tokens("UserNamePasswordAuthenticate" element). Digital identities 310 can be issued to principal 110 using a variety of methods. For example, in some embodiments, principal 110 can request a digital identity 310 over a hypertext transfer protocol connection, or digital identities 310 can beemailed from identity provider 115 to principal 110. In example embodiments, identity provider 115 signs each digital identity 310 sent to principal 110 so that principal 110 can verify that the digital identity 310 is from identity provider 115. Computer system 300 also includes an identity selector 320. Generally, identity selector 320 selects between one or more digital identities 310 of principal 110 on computer system 300 to request and obtain security tokens from one or moreidentity providers, such as identity provider 115. For example, as described further below, when a security policy from relying party 120 is received by computer 300, identity selector 320 is programmed to identify one or more digital identities 310that satisfy one or more of the claims required by the security policy using the information in digital identities 310. In one embodiment, identity selector 320 presents the one or more relevant digital identities 310 to principal 110, and principal 110can decide whether or not to use digital identities 310. Referring now to FIG. 4, once principal 110 receives the security policy from relying party 120, principal 110 can communicate with (using, for example, computer 300) one or more identity providers to gather the claims required by the policy. In the example shown, principal 110 communicates the requirements of the security policy to identity provider 115. In example embodiments, principal 110 requests one or more security tokens from identity provider 115 using the issuance mechanism described in WS-Trust. In one example, principal 110 forwards the claim requirements in the policy of relyingparty 120 to identity provider 115. The identity of relying party 120 can, but need not, be specified in the request sent by principal 10 to identity provider 115 (see the "RequireAppliesTo" element in the example digital identity described above). Therequest can include other requirements as well, such as a request for a display token, as described further below. An example of a request for a security token is provided below. TABLE-US-00006 <wst:RequestSecurityToken> <wst:TokenType> urn:oasis:names:tc:SAML:1.0:assertion </wst:TokenType> <wst:Claims wst:Dialect="http://schemas.microsoft.com/ws/2005/05/ identity"> <ic:ClaimURI="http://.../ws/2005/05/identity/claims/givenname"/> </wst:Claims> </wst:RequestSecurityToken> In another example below, instead of requesting specific claims from identity provider 115, principal 110 can simply provide a reference to one of its digital identities 310 issued by identity provider 115 in its request. TABLE-US-00007 <wst:RequestSecurityToken> ... <ic:InfoCardReference> <ic:CardId>http://xyz.com/CardId/ d795621fa01d454285f9</ic:CardId> <ic:CardVersion>1</ic:CardVersion> </ic:InfoCardReference> ... </wst:RequestSecurityToken> In example embodiments, identity provider 115 has its own security policy as specified in WS-SecurityPolicy and can require authentication of principal 110 before identity provider 115 forwards a security token to principal 110. Generally, claims authority 140 of identity provider 115 can provide one or more of the claims required by the policy from relying party 120. For example, claims authority 140 is programmed to generate one or more claims request by principal110. Claims transformer 130 of identity provider 115 is programmed to transform the claims and to generate one or more signed security tokens 150 that include the claims. In example embodiments, claims transformer 130 is programmed to generate a security token that can be understood by relying party 120. As noted above, principal 110 can request a security token in a certain format (see the "wst:TokenType"element in the example request provided above) in its request to identity provider 115, based on requirements from relying party 120 (see the "wst:TokenType" element in the example security policy provided above). Claims transformer 130 can beprogrammed to generate security tokens in one of a plurality of formats including, without limitation, X509, Kerberos, SAML (versions 1.0 and 2.0), Simple eXtensible Identity Protocol ("SXIP"), etc. For example, in one embodiment, claims authority 140 is programmed to generate claims in a first format A, and the security policy of relying party 120 requires a security token in a second format B. Claims transformer 130 can transform theclaims from claims authority 140 from format A into format B before sending security token 150 to principal 110. In addition, claims transformer 130 can be programmed to refine the semantics of a particular claim. In example embodiments, the semantics of a particular claim are transformed to minimize the amount of information provided in a particularclaim and/or security token to reduce or minimize the amount of personal information that is conveyed by a given claim. For example, in one embodiment, the security policy of relying party 120 requires a claim stating that principal 110 is over 21 years of age. When this requirement is communicated to identity provider 115, claims authority 140 is programmed toprovide a claim of the actual age of principal 110 (e.g., "Birth Date =Jan. 1, 1966"). When this claim is provided to claims transformer 130, claims transformer 130 transforms the semantics of the claim from the actual birth date of principal 110 to aclaim that principal 110 is over 21 years of age (e.g., "Age>21=TRUE"). In this manner, when this claim is packaged into security token 150 that is forwarded through principal 110 to relying party 120, less personal information about principal 110 isshared with relying party 120, while the requirements of relying party 120 are still met. Once security token 150 is generated by claims transformer 130 of identity provider 115, security token 150 can be forwarded to principal 110. In example embodiments, claims transformer 130 forwards the security token 150 to principal 110 usingthe response mechanisms described in WS-Trust. In one embodiment, claims transformer 130 includes a security token service (sometimes referred to as an "STS") such as that disclosed in U.S. patent application Ser. No. 10/436,880 filed on May 12, 2003,the entirety of which is hereby incorporated by reference. Referring now to FIG. 5, an example security token 150 is shown. In the embodiment shown, security token 150 includes a computational token 152 and a display token 154. Computational token 152 includes the claims provided by identity provider115 in an encrypted format. Claims transformer 130 generates computational token 152 in an encrypted format that can be understood (i.e., decrypted) by relying party 120. Claims transformer 130 also generates display token 154. Generally, display token 154 includes at least a summary of the claims that are included in computational token 152 of security token 150. For example, in some embodiments, display token154 includes a list of all of the claims included in computational token 152. Display token 154 can be generated in a format that can be reviewed by principal 110 using, for example, computer system 300. In some examples, display token 154 is generatedin a plain text format or a hypertext markup language format. One example of a display token included as part of a security token response is shown below. TABLE-US-00008 <ic:RequestedDisplayToken> <ic:DisplayToken xml:lang="en-us"> <ic:DisplayClaim URI="http://.../ws/2005/05/identity/claims/givenname"> <ic:DisplayTag>Given Name</ic:DisplayTag><ic:DisplayValue>John</ic:DisplayValue> </ic:DisplayClaim> <ic:DisplayClaim URI="http://.../ws/2005/05/identity/claims/ surname"> <ic:DisplayTag>Last Name</ic:DisplayTag><ic:DisplayValue>Doe</ic:DisplayValue> </ic:DisplayClaim> <ic:DisplayToken> </ic:RequestedDisplayToken> The following is a general description of the elements shown above in the display token: /ic:RequestedDisplayToken/ic:DisplayToken--the returned display token; /ic:RequestedDisplayToken/ic:DisplayToken/@xml:lang--this attribute indicates alanguage identifier, using the language codes specified in RFC 3066, in which the display token content is localized; /ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim--this element indicates an individual claim returned in the security token;/ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim/@URI--this attribute provides the unique identifier (URI) of the individual claim returned in the security token; /ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim/ic:DisplayTag--- thisoptional element provides a common or friendly name for the claim returned in the security token; /ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim/ic:Description-- -this optional element provides a description of the semantics for the claimreturned in the security token; /ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim/ic:DisplayValue- --this optional element provides one or more displayable values for the claim returned in the security token; and /ic :RequestedDisplayToken/ic:DisplayToken/ic:DisplayTokenText (not shown)--this optional element provides an alternative textual representation of the entire token as a whole when the token content is not suitable for display as individual claims. In some embodiments, security token 150 including computational token 152 is issued in accordance with the SAML standard. For example, security token 150 can be issued in accordance with SAML 1.1 or SAML 2.0 standards. Other standards can alsobe used such as, for example and without limitation, an X.509 certificate and a Kerberos ticket. In addition, security token 150 can be cryptographically signed or endorsed by claims transformer 130 using a known algorithm. In one embodiment, for example and without limitation, a 2048-bit asymmetric Rivest-Shamir-Adleman ("RSA") key isused. In other embodiments, other encryption algorithms can be used such as, for example, a base64 encoded symmetric encryption key. In one embodiment, a symmetric key is used by default. In this manner, in the example shown, a party such as relyingparty 120 can cryptographically verify that security token 150 originated from identity provider 115. In example embodiments, computational token 152 is cryptographically bound to display token 154 using one or more known algorithms such as a digital signature over the entire response message from the claims authority containing both thecomputational token 152 and the display token 154. In example embodiments, a display token is provided by default in each security token issued by a claims transformer. In other embodiments, a display token is provided only if the principal requests the display token. An example of such adisplay token request included in a security token request is as follows. TABLE-US-00009 <wst:RequestSecurityToken> <ic:RequestDisplayToken LangId="en-us" /> </wst:RequestSecurityToken> The optional attribute "LangId" indicates a language identifier for the display token using language codes specified in RFC 3066. In example embodiments, a principal can review the display information from the display token and decide whether or not to forward the security token to a relying party. In other embodiments, the principal can review the display information,but does not have the option to stop the forwarding of the security token to the relying party. In other words, once the security token is requested by the principal, the security token is automatically forwarded to the relying party once the securitytoken is received by the principal. In example embodiments, if a security token lacks a display token, the principal is notified of the lack of the display token, and the principal can decide whether or not to forward the security token to the relying party. In other embodiments,if no display token is provided, no display information is presented to the principal. In example embodiments, only the computational token portion of a security token is forwarded by the principal to the relying party. In other embodiments, the principal forwards the entire security token including both the computational tokenand the display token to the relying party. Additional details about example embodiments of security tokens including display tokens can be found in U.S. patent application Ser. No. 11/312,920, filed on Dec. 19, 2005, the entirety of which is hereby incorporated by reference. Referring now to FIG. 6, principal 110 can forward security token 150 to relying party 120 to satisfy all or a part of the security policy of relying party 120. In one example, principal 110 can forward security token 150 to relying party 120by binding security token 150 to an to application message using the security binding mechanisms described in WS-Security. Once relying party 120 receives security token 150, relying party 120 can cryptographically verify the origin of signed security token 150. Relying party 120 can also utilize the claims in computation token 152 of security token 150 to satisfythe security policy of relying party 120 to authenticate principal 110. Once authentication is complete, relying party 120 can provide access to the goods, services, or other information requested by principal 110. In exampled disclosed herein, communication between principal 110, relying party 120, and identity provider 115 can be conducted in a technology-neutral fashion. For example, the embodiments disclosed herein use the mechanisms provided inWS-MetadataExchange and WS-SecurityPolicy to facilitate communication between components using different technologies and communication protocol formats. In this manner, the various components in digital identity system 100 can communicate with oneanother. Referring now to FIG. 7, an example method 400 for authenticating a principal is shown. Method 400 is described with reference to a non-limiting example in which the principal is Employee A. Employee A is an employee of a company referred to as"Company A," and the relying party is a travel agency referred to as "Travel Agency A." Company A has partnered with Travel Agency A for making travel arrangements for employees of Company A at discounted rates. At operation 410 of method 400, a principal requests information from a relying party. In the example embodiment, Employee A utilizes an application program on Employee A's computer to request travel arrangements from the web site of TravelAgency A. Next, at operation 420, Employee A's computer receives the security policy from the web site of Travel Agency A. This policy requires that Employee A submit a security token with a claim establishing that Employee A is an employee of Company Abefore Employee A can access the discounted travel arrangements on the web site of Travel Agency A. At operation 430, Employee A's computer forwards a request based on the security policy to an identity provider, which in the present example is a security token service or STS operated by Company A. The STS of Company A can issue a securitytoken with a claim establishing that Employee A is an employee of Company A. For example, the claim can be "Is Employee of Company A=True." Next, at operation 440, Employee A's computer receives a signed security token from the STS of Company A. Thesecurity token includes a computational token and a display token, with the computational token including the claim establishing that Employee A is an employee of Company A. Control is then passed to operation 450, and Employee A's computer presents the summary of the claims from the display token to Employee A for review. In some embodiments, Employee A is given the option to review the contents of the securitytoken using the display token, and then decide whether or not to forward the security token to the web site of Travel Agency A based on the information in the display token presented to Employee A. In other embodiments, Employee A is not given the optionregarding whether or not to forward the security token to Travel Agency A. Next, at operation 460, the security token is forwarded to the web site of Travel Agency A. Control is then passed to operation 470, and Employee A gains access to the requested discounted travel arrangements on the web site of Travel Agency A. Referring now to FIG. 8, operation 430 of method 400 related to forwarding of a request based on the security policy of a relying party to an identity provider is shown in greater detail. At operation 510, the security policy from relying party120 is reviewed. At operation 520, digital identities 310 for principal 110 are reviewed to identify identity providers 115 that can provide the claims required in the security policy. Next, at operation 530, the relevant identity providers areidentified based on the digital identities. Finally, at operation 540, a request is forwarded to the relevant identity providers for the requested claims. For example, with reference to the non-limiting example provided above, once Employee A's computer receives the security policy from the web site of Travel Agency A, Employee A's computer reviews the digital identities on Employee A's computerto identify the identity providers that can provide the claims required in the security policy. Once the identity providers are identified, Employee A's computer sends requests one or more of the identified identity providers for security tokensincluding the required claims. In some embodiments, relying party 120 identifies a particular identity provider for a particular claim or set of claims (see the "sp:Issuer" element in the example security policy provided above). In this case, principal 110 can forward arequest to the appropriate identity provider for the required claims. In some embodiments, the process of selecting identity providers can be automated by, for example, computer 300. In other embodiments, principal 110 can be involved in the selectionof identity providers. Referring now to FIG. 9, an example method 600 for an identity provider to generate a requested security token is provided. Once again, method 600 is described with reference to the non-limiting example provided above. At operation 610, theidentity provider for Company A receives the request for claims forwarded by Employee A. Next, at operation 620, Company A generates the requested claims. Control is then passed to operation 630, wherein any transformation of the claims is conducted. For example, Travel Agency A can require a claim specifying that Employee A is an employee of Company A. The claims authority of Company A providesa claim stating that Employee A is employee number "9999" of Company A (e.g., "Employee A=9999"). The claims transformer of Company A can transform this claim into a claim that simply indicates that Employee A is an employee of Company A (e.g., "IsEmployee of Company A=True"), thereby minimizing the amount of personal information about Employee A contained in the security token. Next, at operation 640, the security token including the claim is generated. As part of the formation of the security token, the claims transformer of Company A can transform the security token into one of plurality of formats, as required bythe request or default. Finally, at operation 650, the security token is forwarded to Employee A. Although in some of the embodiments disclosed herein the principal is an individual, in alternative embodiments, the principal can be a company, an organization, a computer or other device, a service, or any other type of entity. For example,in one alternative embodiment, the principal is a device that is part of a network. The device can request information, such as a software update, from another device on the network functioning as a relying party. The relying party can requireauthentication of the identity of the device before the relying party provides the requested update. The device can request one or more claims required by the security policy of the relying party from one or more claims transformers, and the claimstransformers can provide one or more security tokens including display tokens to the device. The device can be programmed to review the contents of the display tokens and decide whether or not to forward the security token to the relying party based onits contents. If the device forwards the security token to the relying party, the relying party can then complete the authentication process and provide the requested update to the device. Although example embodiments shown herein illustrate a security token that is forwarded by an identity provider to a principal and then on to a relying party, in alternative embodiments the security token can be forwarded directly from theidentity provider to the relying party. For example, in some embodiments, one security token including a computational token (and possibly a display token) can be forwarded to the relying party, and another security token including a display token (andpossibly the computational token) can be forwarded to the principal. Other configurations are possible. Although the example embodiments shown herein illustrate a security policy requiring only a single claim and a single security token issued by one identity provider, in other embodiments a policy can require multiple claims, and one or moreidentity providers can issue one or more security tokens with one or more claims to satisfy the policy. There can be various advantages associated with digital identities systems configured as disclosed herein. For example, example identity systems disclosed herein utilize various subsystems that communicate or facilitate communication using avariety of protocols and message formats. In addition, such identity systems can automate the process of gathering required authentication information. Further, such systems can increase user control and decrease personal information shared amongsubsystems of the system. The various embodiments described above are provided by way of illustration only and should not be construed to limiting. Those skilled in the art will readily recognize various modifications and changes that may be made to the embodimentsdescribed above without departing from the true spirit and scope of the disclosure or the following claims.* * * * *
Register and get access to “Identity Providers In Digital Identity System - Patent 8104074”
Login to continue downloading: “Identity Providers In Digital Identity System - Patent 8104074”
7+ Documents Related to “Identity Providers In Digital Identity System - Patent 8104074”