Patent Publication Number: US-8117459-B2

Title: Personal identification information schemas

Description:
RELATED APPLICATIONS 
     This application is a continuation-in-part of a U.S. patent application entitled, “IDENTITY PROVIDERS IN DIGITAL IDENTITY SYSTEM,” Ser. No. 11/361,281 by inventors Cameron et al., and filed Feb. 24, 2006 and is hereby incorporated by reference. 
    
    
     BACKGROUND 
     Identity is an important component enabling interactions in everyday life. For example, an individual&#39;s credit card enables merchants to identify and allow the individual to purchase products and services on credit. The same is true in the digital 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 deciding whether or not to trust and provide information to a party. 
     An entity can use a digital identity to authenticate a party&#39;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 the party. Examples of such information include the party&#39;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 a driver&#39;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 can forward 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 no ability 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&#39;s identity, the party&#39;s privacy can become a concern. For example, the party can unknowingly 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 with the 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 subject matter, 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 and an identity selector programmed to receive a security policy from a relying party, review a plurality of digital identities associated with the principal, and request 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 tokens to 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 security token 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 the claims; 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; 
         FIG. 9  illustrates an example method for generating a security token including one or more claims; 
         FIG. 10  illustrates an exemplary digital identity data structure; 
         FIG. 11  illustrates an exemplary capability data structure for encapsulation by the digital identity data structure of  FIG. 10 ; 
         FIG. 12  illustrates an exemplary connection data structure for encapsulation by the digital identity data structure of  FIG. 10 ; 
         FIG. 13  illustrates an exemplary cognitive data structure for encapsulation by the digital identity data structure of  FIG. 10 ; and 
         FIG. 14  illustrates an exemplary method for providing a digital identity data structure, such as the digital identity data structure of  FIG. 10 . 
     
    
    
     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 first party. 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. The second 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 digital identity 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&#39;s identity;   negotiation—the ability 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 way between 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 providing the 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 provider  115  can provide one or more claims about principal  110 . A claim is a statement or assertion made about the principal related to the principal&#39;s identity or information about the principal such as, for example, name, address, social security number, age, etc. As described further below, identity provider  115  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 party  120 , 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 WINDOWS operating system developed by MICROSOFT Corporation of Redmond, Wash. The InfoCard system allows principals to manage 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 Specifications propagated 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 requirements can 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 in system  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. Computer readable 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 computer system 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 information delivery 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 the scope 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 output communications 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 , and identity 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, principal  110  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 principal  110  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 of claims 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 with WS-SecurityPolicy is illustrated in the example below. 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;sp:IssuedToken ...&gt; 
               
               
                   &lt;sp:RequestSecurityTokenTemplate&gt; 
               
               
                     &lt;wst:TokenType&gt; 
               
               
                       urn:oasis:names:tc:SAML:1.0:assertion 
               
               
                     &lt;/wst:TokenType&gt; 
               
               
                     &lt;wst:Claims 
               
               
                       wst:Dialect=“http://schemas.microsoft.com/ws/2005/05/ 
               
               
                     identity”&gt; 
               
               
                       &lt;ic:Claim 
               
               
                       URI=“http://.../ws/2005/05/identity/claims/givenname”/&gt; 
               
               
                     &lt;/wst:Claims&gt; 
               
               
                   &lt;/sp:RequestSecurityTokenTemplate&gt; 
               
               
                 &lt;/sp:IssuedToken&gt; 
               
               
                   
               
            
           
         
       
     
     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—preferred name or first name of a subject;   Last Name—surname or family name of a subject;   Email Address—preferred address for the “To:” field of email to be sent to the subject, usually of the form &lt;user&gt;@&lt;domain&gt;;   Street Address—street address component of a subject&#39;s address information;   Locality Name or City—locality component of a subject&#39;s address information;   State or Province—abbreviation for state or province name of a subject&#39;s address information;   Postal Code—postal code or zip code component of a subject&#39;s address information;   Country—country of a subject;   Primary or Home Telephone Number—primary or home telephone number of a subject;   Secondary or Work Telephone Number—secondary or work telephone number of a subject;   Mobile Telephone Number—mobile telephone number of a subject;   Date of Birth—the date of birth of a subject in a form allowed by the xs:date data type;   Gender—gender of a subject that can have any of these exact string values—“Male,” “Female” or “Unspecified;” and   Private Personal Identifier—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 of security 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. 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;sp:IssuedToken sp:Usage=“xs:anyURI” 
               
               
                   
                 sp:IncludeToken=“xs:anyURI” ...&gt; 
               
               
                   
                   &lt;sp:Issuer&gt; 
               
               
                   
                     &lt;!-- Identity provider&#39;s service endpoint --&gt; 
               
               
                   
                   &lt;/sp:Issuer&gt; 
               
               
                   
                   &lt;sp:RequestSecurityTokenTemplate&gt; 
               
               
                   
                     ... 
               
               
                   
                   &lt;/sp:RequestSecurityTokenTemplate&gt; 
               
               
                   
                   &lt;wsp:Policy&gt; 
               
               
                   
                     ... 
               
               
                   
                   &lt;/wsp:Policy&gt; 
               
               
                   
                   ... 
               
               
                   
                 &lt;/sp:IssuedToken&gt; 
               
               
                   
                   
               
            
           
         
       
     
     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 security token. 
     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 with an X509v3 certificate in the example shown below: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;wsa:EndpointReference&gt; 
               
               
                   
                   &lt;wsa:Address&gt;http://...&lt;/wsa:Address&gt; 
               
               
                   
                   &lt;wsid:Identity&gt; 
               
               
                   
                     &lt;ds:KeyInfo&gt; 
               
               
                   
                       &lt;ds:X509Data&gt; 
               
               
                   
                         &lt;ds:X509Certificate&gt;...&lt;/ds:X509Certificate&gt; 
               
               
                   
                       &lt;/ds:X509Data&gt; 
               
               
                   
                     &lt;/ds:KeyInfo&gt; 
               
               
                   
                   &lt;/wsid:Identity&gt; 
               
               
                   
                 &lt;/wsa:EndpointReference&gt; 
               
               
                   
                   
               
            
           
         
       
     
     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 the WINDOWS operating system developed by MICROSOFT Corporation of Redmond, Wash.) are artifacts that represent the token issuance relationship between principal  110  and a particular identity provider, such as identity provider  115 . In the examples 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&#39;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 use for 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. 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;ic:InfoCard xml:lang=“xs:language”? ...&gt; 
               
               
                   &lt;ic:CardReference&gt; 
               
               
                     &lt;ic:CardId&gt; xs:anyURI &lt;/ic:CardId&gt; 
               
               
                     &lt;ic:CardVersion&gt; xs:unsignedInt &lt;/ic:CardVersion&gt; ? 
               
               
                   &lt;/ic:CardReference&gt; 
               
               
                   &lt;ic:CardName&gt; xs:string &lt;/ic:CardName&gt; ? 
               
               
                   &lt;ic:CardImage MimeType=“xs:string”&gt; xs:base64Binary 
               
               
                 &lt;/ic:CardImage&gt; ? 
               
               
                   &lt;ic:IssuerName&gt; xs:string &lt;/ic:IssuerName&gt; 
               
               
                   &lt;ic:TimeIssued&gt; xs:dateTime &lt;/ic:TimeIssued&gt; 
               
               
                   &lt;ic:TimeExpires&gt; xs:dateTime &lt;/ic:TimeExpires&gt; ? 
               
               
                   &lt;ic:TokenServiceReference&gt; 
               
               
                     (&lt;ic:TokenService&gt; 
               
               
                       &lt;wsa:EndpointReference ...&gt; ... 
               
               
                     &lt;/wsa:EndpointReference&gt; 
               
               
                       &lt;ic:CredentialHint&gt;xs:string&lt;/ic:CredentialHint&gt; ? 
               
               
                       ( 
               
               
                         &lt;ic:UserNamePasswordAuthenticate&gt;...&lt;/ic:UserNamePasswordAuthenticate&gt; | 
               
               
                         &lt;ic:KerberosV5Authenticate&gt;...&lt;/ic:KerberosV5Authenticate&gt; | 
               
               
                         &lt;ic:X509V3Authenticate&gt;...&lt;/ic:X509V3Authenticate&gt; | 
               
               
                         &lt;ic:SelfIssuedAuthenticate&gt;...&lt;ic:SelfIssuedAuthenticate&gt; 
               
               
                       ) 
               
               
                     &lt;/ic:TokenService&gt;) + 
               
               
                   &lt;/ic:TokenServiceReference&gt; 
               
               
                   &lt;ic:CardPolicy&gt; 
               
               
                     &lt;ic:SupportedTokenTypes&gt; 
               
               
                       &lt;ic:TokenType URI=“xs:anyURI” /&gt; + 
               
               
                     &lt;/ic:SupportedTokenTypes&gt; 
               
               
                     &lt;ic:SupportedClaims&gt; 
               
               
                       (&lt;ic:SupportedClaim URI=“xs:anyURI”&gt; 
               
               
                         &lt;ic:DisplayTag&gt; xs:string &lt;/ic:DisplayTag&gt; ? 
               
               
                         &lt;ic:Description&gt; xs:string &lt;/ic:Description&gt; ? 
               
               
                       &lt;ic:SupportedClaim&gt;) + 
               
               
                     &lt;/ic:SupportedClaims&gt; 
               
               
                     &lt;ic:RequireAppliesTo /&gt; ? 
               
               
                   &lt;/ic:CardPolicy&gt; 
               
               
                   ... 
               
               
                 &lt;/ic:InfoCard&gt; 
               
               
                   
               
            
           
         
       
     
     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:CardReference—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:CardReference/ic:CardId—this element provides a globally unique identifier in the form of a URI for the specific InfoCard;   /ic:InfoCard/ic:CardReference/ic:CardVersion—this optional element provides a versioning epoch for the InfoCard issuance infrastructure used by the identity provider;   /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 issued InfoCard 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 issuer of 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 and invalid;   /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:InfoCard/ic:TokenServiceReference/ic:TokenService/wsa:EndpointReference—this element provides the endpoint reference for the security token service;   /ic:InfoCard/ic:TokenServiceReference/ic:TokenService/ic:CredentialHint—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/&lt;credential selector element&gt;—this element provides an unambiguous description of the credentials to use for authenticating to the security token service, with example credential types including Kerberos, X509, or self-issued credentials;   /ic:InfoCard/ic:CardPolicy—this element provides the token issuance policy of the identity that allows a principal to determine if the InfoCard satisfies a relying party&#39;s token requirements in a given interaction;   /ic:InfoCard/ic:CardPolicy/ic:SupportedTokenTypes—this element contains the list of token types, as child elements, that the identity provider can issue;   /ic:InfoCard/ic:CardPolicy/ic:SupportedTokenTypes/ic:TokenType (one or more)—this element indicates an individual token type that is supported;   /ic:InfoCard/ic:CardPolicy/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:CardPolicy/ic:SupportedClaims/ic:SupportedClaim (one or more)—this element indicates an individual claim type that is supported; and   /ic:InfoCard/ic:CardPolicy/ic:RequireAppliesTo—this optional empty element indicates that the service requester (InfoCard system) must submit the relying party identity to the identity provider.       

     An example digital identity is provided below. 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;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”&gt; 
               
               
                   &lt;CardReference&gt; 
               
               
                     &lt;CardId&gt;http://...&lt;/CardId&gt; 
               
               
                   &lt;/CardReference&gt; 
               
               
                   &lt;CardName&gt;...&lt;/CardName&gt; 
               
               
                   &lt;CardImage MimeType=“image/gif”&gt; ... &lt;/CardImage&gt; 
               
               
                   &lt;IssuerName&gt;XYZ Identity Provider&lt;/IssuerName&gt; 
               
               
                   &lt;TimeIssued&gt;2003-08-24T00:30:05Z&lt;/TimeIssued&gt; 
               
               
                   &lt;TokenServiceReference&gt; 
               
               
                     &lt;TokenService&gt; 
               
               
                       &lt;wsa:EndpointReference&gt; 
               
               
                         &lt;wsa:Address&gt;http://...&lt;/wsa:Address&gt; 
               
               
                           &lt;wsid:Identity&gt; 
               
               
                             &lt;ds:KeyInfo&gt; 
               
               
                               &lt;ds:X509Data&gt; 
               
               
                                 &lt;ds:X509Certificate&gt;...&lt;/ds:X509Certificate&gt; 
               
               
                               &lt;ds:X509Data&gt; 
               
               
                             &lt;/ds:KeyInfo&gt; 
               
               
                           &lt;/wsid:Identity&gt; 
               
               
                       &lt;/wsa:EndpointReference&gt; 
               
               
                       &lt;UserNamePasswordAuthenticate&gt; 
               
               
                         &lt;Username&gt;...&lt;/Username&gt; 
               
               
                       &lt;/UserNamePasswordAuthenticate&gt; 
               
               
                     &lt;/TokenService&gt; 
               
               
                   &lt;/TokenServiceReference&gt; 
               
               
                   &lt;ic:CardPolicy&gt; 
               
               
                     &lt;SupportedTokenTypes&gt; 
               
               
                       &lt;TokenType 
               
               
                     URI=“urn:oasis:names:tc:SAML:1.0:assertion”/&gt; 
               
               
                     &lt;/SupportedTokenTypes&gt; 
               
               
                     &lt;SupportedClaims&gt; 
               
               
                       &lt;SupportedClaim 
               
               
                     URI=“http://.../ws/2005/05/identity/claims/givenname”&gt; 
               
               
                       &lt;DisplayTag&gt;Given Name&lt;/DisplayTag&gt; 
               
               
                       &lt;/SupportedClaim&gt; 
               
               
                       &lt;SupportedClaim 
               
               
                     URI=“http://.../ws/2005/05/identity/claims/surname”&gt; 
               
               
                     &lt;DisplayTag&gt;Last Name&lt;/DisplayTag&gt; 
               
               
                       &lt;/SupportedClaim&gt; 
               
               
                     &lt;/SupportedClaims&gt; 
               
               
                     &lt;RequireAppliesTo /&gt; 
               
               
                   &lt;/ic:CardPolicy&gt; 
               
               
                 &lt;/InfoCard&gt; 
               
               
                   
               
            
           
         
       
     
     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&#39;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 be emailed 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 more identity 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  310  that 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  110  can 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 relying party  120  to identity provider  115 . The identity of relying party  120  can, but need not, be specified in the request sent by principal  110  to identity provider  115  (see the “RequireAppliesTo” element in the example digital identity described above). The request 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. 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;wst:RequestSecurityToken&gt; 
               
               
                  &lt;wst:TokenType&gt; 
               
               
                   urn:oasis:names:tc:SAML:1.0:assertion 
               
               
                  &lt;/wst:TokenType&gt; 
               
               
                  &lt;wst:Claims 
               
               
                   wst:Dialect=“http://schemas.microsoft.com/ws/2005/05/identity”&gt; 
               
               
                   &lt;ic:Claim 
               
               
                   URI=“http://.../ws/2005/05/identity/claims/givenname”/&gt; 
               
               
                  &lt;/wst:Claims&gt; 
               
               
                 &lt;wst:RequestSecurityToken&gt; 
               
               
                   
               
            
           
         
       
     
     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. 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;wst:RequestSecurityToken&gt; 
               
               
                  ... 
               
               
                  &lt;ic:CardReference&gt; 
               
               
                   &lt;ic:CardId&gt;http://xyz.com/CardId/d795621fa01d454285f9&lt;/ic: 
               
               
                  CardId&gt; 
               
               
                    &lt;ic:CardVersion&gt;1&lt;/ic:Card Version&gt; 
               
               
                  &lt;ic:CardReference&gt; 
               
               
                  ... 
               
               
                 &lt;/wst:RequestSecurityToken&gt; 
               
               
                   
               
            
           
         
       
     
     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 principal  110 . 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 be programmed 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 the claims 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 particular claim 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 to provide 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 a claim that principal  110  is over 21 years of age (e.g., “Age&gt;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  is shared 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  using the 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 provider  115  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 token  154  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 generated in 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. 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;ic:RequestedDisplayToken&gt; 
               
               
                   
                  &lt;ic:DisplayToken xml:lang=“en-us”&gt; 
               
               
                   
                   &lt;ic:DisplayClaim 
               
               
                   
                  URI=“http://.../ws/2005/05/identity/claims/givenname”&gt; 
               
               
                   
                    &lt;ic:DisplayTag&gt;Given Name&lt;/ic:DisplayTag&gt; 
               
               
                   
                    &lt;ic:DisplayValue&gt;John&lt;/ic:DisplayValue&gt; 
               
               
                   
                   &lt;/ic:DisplayClaim&gt; 
               
               
                   
                   &lt;ic:DisplayClaim 
               
               
                   
                  URI=“http://.../ws/2005/05/identity/claims/surname”&gt; 
               
               
                   
                    &lt;ic:DisplayTag&gt;Last Name&lt;/ic:DisplayTag&gt; 
               
               
                   
                    &lt;ic:DisplayValue&gt;Doe&lt;/ic:DisplayValue&gt; 
               
               
                   
                   &lt;/ic:DisplayClaim&gt; 
               
               
                   
                  &lt;ic:DisplayToken&gt; 
               
               
                   
                 &lt;/ic:RequestedDisplayToken&gt; 
               
               
                   
                   
               
            
           
         
       
     
     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 a language 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—this optional 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 claim returned 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 also be 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 is used. 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 relying party  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 the computational 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 a display token request included in a security token request is as follows. 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;wst:RequestSecurityToken&gt; 
               
               
                   
                   &lt;ic:RequestDisplayToken LangId=“en-us” /&gt; 
               
               
                   
                 &lt;wst:RequestSecurityToken&gt; 
               
               
                   
                   
               
            
           
         
       
     
     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 security token 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 token and 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  10  can forward security token  150  to relying party  120  by 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 the computational token  152  of security token  150  to satisfy the 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  10 , 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 in WS-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 one another. 
     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&#39;s computer to request travel arrangements from the web site of Travel Agency A. Next, at operation  420 , Employee A&#39;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 A before Employee A can access the discounted travel arrangements on the web site of Travel Agency A. 
     At operation  430 , Employee A&#39;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 security token 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&#39;s computer receives a signed security token from the STS of Company A. The security 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&#39;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 security token 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 option regarding 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 party  120  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 are identified 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&#39;s computer receives the security policy from the web site of Travel Agency A, Employee A&#39;s computer reviews the digital identities on Employee A&#39;s computer to identify the identity providers that can provide the claims required in the security policy. Once the identity providers are identified, Employee A&#39;s computer sends requests one or more of the identified identity providers for security tokens including 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 a request 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 selection of 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 , the identity 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 provides a 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., “Is Employee 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 by the 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 require authentication 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 claims transformers 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 on its 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 the identity 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 (and possibly 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 more identity providers can issue one or more security tokens with one or more claims to satisfy the policy. 
     Exchanging digital identities provides a robust mechanism for identification of a principal to a relying party while limiting the information a relying party may utilize to the information allowed by the principal. Organizing digital identity into a data structure further improves data processing efficiency, standardization, platform independence, and usability. 
     In one embodiment, principal  10  retrieves claims from identity provider  115  in response to receiving a security policy from relying party  120 . Once the claims have been obtained, subsequent requests for claims can be retrieved directly from principal  110  in the form a data structure. Identity provider need not be contacted again unless the claims expire or the security policy of relying party  120  is changed to require additional claims. 
     Referring now to  FIG. 10 , digital identity data structure  1000  encapsulates capability data structure  1002 , connection data structure  1004 , and cognitive data structure  1006 . In one embodiment, in response to receiving a security policy from relying party  120 , a digital identity data structure  1000  is sent from principal  110  to relying party  120 . Relying party  120  may then evaluate the claims in digital identity data structure  1000  to determine the principal&#39;s  110  identity. 
     In an alternative embodiment, digital identity data structure  1000  comprises the InfoCard structure as described above. In a first further embodiment, capability data structure  1002  comprises the CardPolicy structure. In a second further embodiment, connection data structure  1004  comprises the KeyInfo structure. In a third further embodiment, cognitive data structure  1006  comprises at least one of the CardImage and CardName data elements. 
     Referring now to  FIG. 11 , capability data structure  1002  contains a number of capability records  1100 . In another embodiment, at least one capability data record  1100  is a claim. In another embodiment, at least one capability record  1100  is a descriptor of the identity provider  115  that originated at least one claim. In other embodiments, capability records  1100  includes, without limitation, CardPolicy, SupportedTokenTypes, TimeIssued, IssuerName, and SupportedClaimTypes record types. 
     Referring now to  FIG. 12 , connection data structure  1004  contains connection records  1200 . In one embodiment, at least one connection record  1200  links at least one claim back to the identity provider  115  fulfilling that claim. In another embodiment, at least one connection record  1200  contains cryptographic data elements. In other embodiments, connection records  1200  include, without limitation, network location, connection protocol, encryption key, encryption methodology, and authentication credential. 
     Referring now to  FIG. 13 , cognitive data structure  1006  contains cognitive records  1300 . In one embodiment, at least one cognitive record  1300  identifies digital identity data structure  1000  to a human user. In another embodiment, at least one cognitive record  1300  identifies digital identity data structure  1000  to a machine executing instructions. In other embodiments, cognitive records  1300  include, without limitation, the name, a textual identifier and a graphic identifier of the data structure. 
     In one embodiment, the textual identifier provides principal  110  with a textual identifier of the data structure. Examples of text identifiers include, without limitation, “ABC Bank,” “XYZ Travel Agency,” and “My Retirement Account.” In another embodiment, a graphical image provides a graphical means to identify the data structure. Examples of graphical identifiers may include corporate logos or purpose-descriptive icons. Examples of purpose-descriptive icons include, without limitation, an airplane, such as to represent a travel agency or frequent flyer program; an automobile, such as to represent a rental car agency; and a currency symbol, such as to represent a bank account or other financial data. 
     Referring now to  FIG. 14 , a method for providing a digital identity is shown. Method  1400  may be initiated by relying party  120 , which may in turn be initiated by principal&#39;s  110  request for access to goods, services, or information controlled by relying party  120 . At operation  1402  of method  1400 , a request is received for one or more claims. The claims identify principal  110 . 
     Next, at operation  1404  of method  1400 , one or more claims are received. In one embodiment, identity provider  115  is the source of the claims. In another embodiment, the one or more claims are acquired, such as by accessing information available to principal  110 . Next, at operation  1406  of method  1400 , the claims are transformed. Next at operation  1408  of method  1400 , a security token is generated which includes the claims. In another embodiment, such as when the transformation of claims is not required, operation  1406  is omitted. In still other embodiments, such as when the encryption of the claims is not required, operation  1408  is omitted. 
     At operation  1410  of method  1400 , a computer-readable medium is encoded with digital identity data structure  1000 . Digital identity data structure  1000  comprising capabilities data structure  1004 . Capabilities data structure  1004 , in turn, comprises the claim records. At operation  1412 , the data structure is provided. 
     In another embodiment, one or more cognitive records  1300  are generated. Digital identity data structure  1000  comprises cognitive data structure  1006 , which comprises the cognitive records  1300 . In a further embodiment, at least one cognitive record  1300  identifies digital identity data structure  1000 . In another further embodiment, at least one cognitive record  1300  identifying digital identity data structure  1000  is determined in response to a user&#39;s input. In another embodiment at least one cognitive record  1300  identifying digital identity data structure  1000  is a graphical image. In one embodiment, the user&#39;s input is text entered by a keyboard, touch-pad, mouse, selection box, check box, radio button, directory, speech-to-text processor, or other entry or selection device. 
     In another embodiment, one or more connection records  1200  are generated. Digital identity data structure  1000  comprises connection data structure  1006 , which comprises connection records  1200 . In one embodiment, at least one connection record  1200  is generated with encryption/decryption token data associated with the identity provider. In further embodiments, the encryption/decryption data is an encryption/decryption key or methodology. In another embodiment, at least one connection record is generated with server connection data associated with the source of the security token. 
     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 a variety 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 among subsystems 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 embodiments described above without departing from the true spirit and scope of the disclosure or the following claims.