Patent Application
20100088753
For users and businesses alike, the Internet continues to be increasingly valuable. More people are using the Internet for everyday tasks, from shopping, banking, and paying bills to consuming media and entertainment. E-commerce is growing, with businesses delivering more services and content across the Internet, communicating and collaborating on-line, and inventing new ways for users to connect with each other. Users can presently access on-line resources from a diverse set of platforms including computers, mobile and smart phones, game consoles, and other devices that have network connectivity.
When accessing some sites and services, users need to be authenticated so that the interaction is appropriate and not misused in some way. For example, a user attempting to access a bank account on-line needs to be authenticated to verify that the user is who he claims to be (i.e., a legitimate bank customer who owns or is otherwise entitled to access the account). Another example is that users of social networking sites need to be authenticated, among other reasons, to prevent impersonators from gaining access to a user's page and posting malicious or false content. Authentication generally involves a user entering a user ID (or login ID, account name, user name, etc.) and a password or personal identification number (“PIN”) which are referred to as “credentials” to verify his or her identity.
While some authentication systems provide satisfactory performance, current systems do not meet all of the needs of the on-line community. For example, users want both flexibility in the identities they project on-line and a straightforward way to maintain the security of their identities without requiring the use of an ever-lengthening list of passwords (which can encourage insecure practices such as reusing account names and passwords across multiple web sites).
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.
An identity and authentication platform utilizes a data model that enables multiple identities such as e-mail addresses, mobile phone numbers, nicknames, gaming IDs′, and other user IDs to be utilized as aliases which are unique sub-identities of a main account name. A user may employ a generic set of authentication credentials or the credentials of the main account to access the aliases supported by the platform and project multiple different on-line identities using the aliases. The platform is further configured to expose the aliases to various client applications and Internet-accessible sites and services such as e-mail, instant messaging, media sharing, gaming and social networks, and the like, to enable the implementation of a variety of usage scenarios that employ aliases.
In various illustrative examples, web sites and services that support the use of aliases rely upon an identity and authentication service to provide authentication for users of the sites and services (collectively referred to as “relying services”). The relying services can operate in combination with applications that run on a web browser (i.e., “thin client” applications) or more feature-rich client applications (i.e., “thick client” applications) to provide a wide range of usage scenarios that employ aliases. For example, users can sign in to a relying service and be authenticated using their main account name and password or by using an alias and the same main account password.
Multiple e-mail accounts can be collectively managed (where each e-mail account identifies a user with a different alias) so that the user can sign in to a main e-mail account, be authenticated, and then receive e-mail messages that are addressed to the different e-mail aliases. And, a user of a relying service can find other users by using the aliases of such users. An invitation generated using an event planning service can be addressed, for example, to a user's alias but still get delivered to the user's main account. Or, a game player can look up and find another player's profile by alias on an on-line game service.
Users are provided with tools to manage their on-line identities using aliases. Users have the ability to create, update, and delete aliases and manage how they are used with the various services. Users may also set one or more attributes that are associated with their aliases to limit the extent to which the association between an alias and main account name is made public on a service. This enables the user to maintain privacy, whenever desired, while still receiving the benefits that aliases provide.
Advantageously, the present identity and authentication platform is extensible and scalable across a variety of services that can be operated by unrelated service providers (for example, e-mail aliases can be applied to e-mail accounts using different domains that are hosted by different providers). The platform provides a convenient and secure way for users to employ and expose aliases to manage how they are perceived in the on-line community while controlling when and how they can be reached and preserving their privacy when desired.
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.
Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated.
Computer users frequently maintain different identities for use with different on-line sites and services. A single user may employ various identifiers such as e-mail addresses, nicknames, user names, mobile phone numbers, gaming names or IDs, and other constructs, at different times and in different settings to reflect the user's on-line identity. So, for example, a user may utilize a mobile phone number with a presence based network service, such as instant messaging (“IM”), which can operate with a mobile phone. In addition, the user might sign in with a user name to an on-line social networking site and use an e-mail address when logging on to a frequent-flyer account.
Users may find the maintenance of multiple identities burdensome. For example, as more sites and services require the creation of an account to use them, the proliferation of different account names and passwords can lead to “password fatigue” for users. For these users it can be difficult to remember their passwords which can lead to users reusing the same credentials across multiple sites and services. Not only can such practice pose a vulnerability to theft and identity fraud, but the user loses flexibility in how they present themselves to the on-line community.
Users often want the ability to represent themselves with different identities because it allows them to tailor their identity to a particular on-line context and, in some cases, broaden the ability for others to reach them. However, users are typically only allowed to have a single identity associated with a given account across most on-line services. While there are existing services where multiple nicknames can be associated with one account, these are presently limited to on-line services involving group discussions and the nicknames cannot be used outside the group. Nor can the nickname be utilized to sign in to the main account. These limitations can frustrate users who want to have rich social interactions on-line.
The present identity and authentication system benefits users and addresses limitations of the current on-line environment. The system provides users with an easy way to manage their on-line identities using aliases to control how they can be reached and when.
Turning now to the drawings,
On-line sites and services are configured to rely upon a service 122 to provide identity and authentication. Hence, the on-line sites and services are referred to as “relying services” and are collectively identified by reference numeral 115 in
In some implementations, one or more of the relying services 115 and the identity and authentication service 122 may be operated by the same entity. However, this is not a requirement as a relying service provider may also delegate user authentication to an unaffiliated third party provider that operates the identity and authentication service 122.
The relying services 115 may comprise a wide variety of different services that may be operated by one or more service providers.
The client devices 112 (
The thin client applications 302 are typically those that can be implemented using a web browser such as Microsoft Internet Explorer® on PCs and Internet Explorer Mobile for mobile devices. Thin client applications are commonly coded in browser-supported languages such as HTML (HyperText Markup Language) and XML (eXtensible Markup Language) and implement features such as scripting and ActiveX controls.
Thick client applications 306 are typically implemented as standalone applications using programming environments such as Win32 on the PC. Thick client applications commonly include applications such as desktop e-mail, blogging, and IM clients that typically provide a richer feature set and more flexibility for local data storage as compared to similar applications that are implemented as thin clients. In some implementations, alias functionality may be exposed to thick client applications 306 using a client-side aliases interface 315 (i.e., a locally installed API). However, such interface 315 is not necessarily used in all implementations, and some thick client applications 306 can be configured to interface directly with alias services, for example by invoking methods exposed through an API (application programming interface) that is supported by the identity and authentication service 122, as described in more detail below in the text accompanying
The identity and authentication service 122 (
The aliases data model 400 further provides that aliases may include various types of identification (420). As shown in
E-mail address aliases 5051, may include e-mail addresses from different domains and may be supported by different and/or unrelated relying service providers. Nickname aliases 5052 and gamertag aliases 505N are names within a domain, although the domain itself will not be exposed to a user 105. For example, although a nickname alias includes the domain for (e.g., “nickname@domain.com”) for the purposes of the system tracking the origin of the alias, the alias used and seen by the user 105 is simply “nickname.”
Referring back to
The data model 400 further provides that aliases may have attributes (435) which form the core for defining an identity for a user 105. An illustrative set of attributes 600 is shown in
The attributes IsEmail 605, IsMobile 610, IsGamertag 615, and IsNickname 620 are used respectively to identify the alias type. Such identification may be utilized to enable the relying service 115 and identity and authentication service 122 to use the aliases in a manner that is appropriate to their type. A message designed for delivery to an e-mail alias would not necessarily work effectively when sent to a mobile phone number alias, for example, due to variations in message protocols and differences in device characteristics such as display and rendering capabilities.
The IsVerified attribute 625 is typically applicable when an e-mail address is used as an alias and the e-mail address is provided by a relying service 115 that is unrelated to the provider of the identity and authentication service 122. In such cases, the service 122 needs to verify the validity of the alias before allowing it to be associated with the main account and used by the relying services 115. An IsVerified attribute flag will be set for an e-mail alias when its user has verified that he or she owns that e-mail address. Otherwise, the e-mail alias is tracked by the service 122 as being unverified which will typically limit the usage scenarios in which the unverified alias can be utilized.
For example, if an invitation is sent using an unverified alias (i.e., the IsVerified attribute flag for that alias is not set) to an invitee from a user of the event planning service 2069, then the invitee will be unable to accept the invitation until the invitee can show that the alias belongs to the invitee and has rights to it. The unverified e-mail alias may get verified through a method in which the identity and authentication service 122 sends a separate e-mail that is addressed to the unverified e-mail alias. The e-mail from the service 122 includes a verification link containing a verification token. When the link is clicked it will open a web page where the invitee can sign in to thereby prove that the verification e-mail was received at a legitimate inbox for the e-mail alias.
Verification can also work for mobile phone numbers that are used as aliases. An SMS (Short Message Service) message containing a code may be sent to the mobile phone number alias. The user can go to a website that is set up using, for example, a PC or the mobile browser on the phone and enter the code from the SMS message into a user interface provided by the site to thereby verify the mobile number alias with the identity and authentication service 122.
The IsPrivate attribute 630 provides an indication as to the preference of the alias user in exposing the relationship between an alias 505 and the main account name 512. If the IsPrivate attribute flag is set, then the identity and authentication service 122 will not expose the main account name 512 underlying any alias 505 to a query from a caller. Thus, use of the IsPrivate attribute 630 enables a user to allow or prevent someone or some service from looking up the main account name that is associated with an alias. In some implementations, the reverse situation may also be supported where a user can allow or prevent a lookup of all aliases or a selected subset of aliases that are associated with a main account name.
The Context attribute 635 may be used to indicate the context in which aliases are utilized. For example, the Context attribute 635 can indicate which particular relying services 115 are being used or are otherwise associated with a given alias 505. Other relying services 115 may then use such context when implementing certain usage scenarios or service features. For example, the Context attribute 635 of an e-mail alias that is created inside a first relying service can be tagged, i.e., Context=service1. A second relying service can then check the Context attribute and see that the e-mail alias has not been used with the second service. It can then notify a user about the option to utilize the e-mail alias with the second relying service. Other uses of the Context attribute 635 may include displaying to a user 105 which aliases are being used with which relying services 115 or sorting aliases based on usage.
As shown in
The Create Alias method 7001 when invoked will create an alias that is associated with the main account name and set an initial set of attributes 600. If a verification token is supplied at the time the alias is created, then the attribute IsVerified 625 will be set so that the created alias 505 is a verified alias. The Delete Alias method 7002 and Rename Alias method 7003 enable an alias to be deleted from the system and renamed, respectively. If a user 105 renames an alias 505, as noted above, its attributes and any other data associated with it will be persisted using the immutable identifier (e.g., AUID). A caller may invoke the Update Alias method 7004 to change the attributes 600 that are associated with an alias. For example, the IsPrivate attribute 630 can be toggled to enable or disable privacy.
Turning now to
The relying service 115 will return a page containing a sign-in link (820). When the user 1051 clicks on the link, the user is redirected to the identity and authentication service 122 (830) to perform authentication of the user on behalf of the relying service 115. The identity and authentication service 122 presents a sign-in dialog box with which the user may sign in. While the user 1051 has the option to sign in using the user's main account name and password, in this scenario the user signs in with an alias and password (840). Typically, the password will be the same password that is associated with the main account name for all the user's aliases for the convenience of the user 1051. However, there is no requirement that the user employ a commonly-utilized password.
The identity and authentication service 122 authenticates the user 1051 using the alias and password supplied and returns an authentication token back to the client (850). The authentication token will contain data, in encrypted form, including the main account name, password, and the AUID associated with the alias. The identity and authentication service 122 then redirects the user 1051 to the relying service 115 (860). Using a secret key that is shared between the identity and authentication service 122 and the relying service 115 beforehand, the relying service 115 can pull and decrypt the data from the authentication token passed from the client to thereby display protected content or provide a personalized service to the user 1051 (870). Since the authentication token includes the authentication credentials of the main account, signing in to the relying service 115 with an alias works to authenticate the user 1051 by authenticating the underlying main account. This feature guarantees the user 1051 access to appropriate content and personalization since the relying service 115 will always recognize the main account name.
The identity and authentication service 122 authenticates the user 1051 using the alias and returns an authentication ticket back to the client (930) that contains data, in encrypted form, including the main account name, password, and the AUID associated with the alias. The thick client application 306 can use the data to request one or more service tickets from the relying service 115 (940). In a similar manner as with the scenario 800 above, the fact that the authentication ticket includes the main account name enables the relying service to appropriately identify the user 1051 even though the user signs in with an alias. The relying service can then return the appropriate service tickets (950).
The thick client application 306 next requests protected and/or personalized content and services from the relying service by passing a service ticket received in the previous step to the relying service (960). The relying service 115 provides the content or service to the user 1051 responsively to the request (970).
The relying service 115 will return a page containing a sign-in link (1020). When the user 1051 clicks on the link, the user is redirected to the identity and authentication service 122 (1030) to perform authentication of the user 1051 on behalf of the relying service 115. The identity and authentication service 122 presents a sign-in dialog box with which the user 1051 signs in with an alias and password (1040).
The identity and authentication service 122 authenticates the user 1051 using the alias and password supplied and returns an authentication token back to the client (1050). The authentication token will contain data, in encrypted form, including the main account name, password, and the AUID associated with the alias. In addition, the authentication token will contain a HasAliases field. (It is noted that for thick-client applications 306, the HasAliases field is also populated into the HTTP header of the response from the identity and authentication service 122). The HasAliases field includes a timestamp to indicate the last change to the alias (e.g., the time it was created, renamed, had its attributes updated, etc.).
The identity and authentication service 122 redirects the user 1051 to the relying service 115 (1060). The relying service 115 can pull the data from the authentication token passed from the client including the main account name. When the relying service 115 reads the HasAliases field from the authentication token, it can invoke the GetAliasesForAccount method that is exposed through the aliases API 704 (
The identity and authentication service 122 returns a list of aliases that the user 1051 has associated with the main account name in response to the API call from the relying service (1080). The relying service 115 can then provide the all of the e-mail addressed to the various e-mail aliases to the user 1051 (1090). The e-mail aliases may be cached by the relying service 115 until the timestamp in the HasAliases field indicates that an alias has been changed. At that point, the relying service 115 can make another GetAliasesForAccount call to get the updated list of aliases.
The scenario begins when the host interacts with the relying service 115 to create an invitation that is addressed to an e-mail alias of the invitee (1110). The relying service 115 invokes the GetAccountForAliases method that is exposed through the aliases API 704 (1120) and passes the e-mail alias named in the invitation as a parameter for the method. The identity and authentication service 122 returns the main account name that is associated with the invitee's e-mail alias (1130). However, if the IsPrivate attribute for the e-mail alias is set (which indicates that the invitee 1051 does not wish to expose the underlying account name to a look up from an alias), then the identity and authentication service 122 will not return the main account name in response to the API call.
Assuming the alias is not set to private, the relying service 115 will index the invitation to the main account name returned from the GetAccountForAliases call. A notification is made, for example by e-mail, so that the invitee can sign in to get the invitation (1140). The invitee may click on a link in the notification to be redirected to the identity and authentication service 122 (1150) and signs in using either the user's main account name and password or an alias and password (1160).
The identity and authentication service 122 authenticates the invitee using the credentials supplied and returns an authentication token back to the client (1170). The authentication token will contain data including the main account name, password, and the AUID associated with the alias. The identity and authentication service 122 then redirects the user invitee to the relying service 115 (1180). The relying service 115 can then provide the event invitation responsively to the data from the authentication token (1190).
In the scenario above, the event invitation is sent to the invitee's e-mail address. In an alternative scenario, if the event invitation is sent to an e-mail address that is not an alias, then the notification can provide the invitee with an option to add the e-mail address as a verified e-mail alias when signing in to the service using the main account name and password.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
