Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/31—User authentication
  • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers

Definitions

• 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.
• PIN personal identification number
• 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.
• 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.
• applications 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.
• Each e-mail account identifies a user with a different alias
• 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.
• 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.
• a game player can look up and find another player's profile by alias on an on-line game service.
• aliases 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.
• 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.
• FIG 1 shows an illustrative on-line services environment in which users at client devices may interact with on-line sites and services that rely upon an identity and authentication service that supports aliases;
• FIG 2 shows an illustrative set of sites and services that may be used with aliases
• FIG 3 shows illustrative thin client applications and thick client applications that may run on a client device
• FIG 4 shows an illustrative aliases data model
• FIG 5 shows an illustrative set of aliases that may be associated with a main account name
• FIG 6 shows an illustrative set of attributes that may be associated with an alias
• FIG 7 shows an illustrative set of methods that are exposed by an API
• FIG 8 shows a first illustrative usage scenario in which a user may sign in to a service with an alias using a thin client application
• FIG 9 shows a second illustrative usage scenario in which a user may sign in to a service with an alias using a thick client application
• FIG 10 shows a third illustrative usage scenario in which a user may receive e- mail messages sent to multiple different e-mail aliases; and [0021]
• FIG 11 shows a fourth illustrative usage scenario in which a user may be reached by others through an alias.
• 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.
• 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.
• IM instant messaging
• 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.
• FIG 1 shows an illustrative on-line services environment 100 in which users 105i, 2 N at respective client devices 112 ⁇ 2 N may interact over a network such as the Internet 120 with various on-line sites and services.
• the client devices 112 may take a variety of form factors and be configured with different capabilities and resources.
• the client devices 112 include a desktop PC 112i, a laptop PC 112 2 , a mobile device 112 3 (e.g., smart phone, mobile phone, etc.), and a video game console 112 N .
• these devices are intended to be illustrative and that other types of devices may also be utilized as may be required to meet the needs of a particular implementation.
• 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 FIG 1.
• the client devices 112, relying services 115, and the identity and authentication service typically communicate using HTTP (HyperText Transfer Protocol).
• 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.
• FIG 2 shows illustrative examples of specific relying services that may be used in some implementations. The examples are intended to be illustrative as not all the examples shown in FIG 2 need to be utilized in every application, and there could be other services used in a given implementation that are not shown.
• the illustrative relying services 115 include services which support: instant messaging 206i; desktop e-mail 206 2 ; personal web pages 206 3 ; hosted e-mail 206 4 ; online file storage and/or sharing 206 5 ; media content (e.g., pictures, audio, or video) sharing 20O 6 ; web forums and/or discussion groups 2O67; blogs (i.e., weblogs) 206s; event planning 2O69; or social networking 2O6io.
• Websites which provide services other than those listed above and which rely on the identity and authentication service 122 may also be utilized (as collectively identified by reference numeral 206 N in FIG 2).
• the client devices 112 will interact with the relying services 115 (and the identity and authentication service 122) through client applications that are installed and run on the devices in order to render a particular experience to a user 105 that employs aliases.
• the client devices (as represented by desktop PC 112i) can run a variety of client applications including both thin client applications 302i, 2... N and thick client applications 306i, 2... N - While N thick client and thin client applications are shown in FIG 3, the particular type and number of applications utilized on a given client device 112 can vary by implementation and client device capabilities. For example, a mobile device might not run as many client applications as compared with PCs and game consoles, and those it does run will be tailored to the more resource-constrained runtime environment that is supported by the mobile device.
• 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. [0033] 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.
• alias functionality may be exposed to thick client applications 306 using a client-side aliases interface 315 (i.e., a locally installed API).
• client-side aliases interface 315 i.e., a locally installed API
• 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 FIG 7.
• the identity and authentication service 122 (FIG 1) is arranged to expose aliases to the relying services 115 and client applications 302 and 306 under a flexible data model that may support a wide range of alias usage scenarios (several of which are shown in FIGs 8 - 11 and described in the accompanying text).
• FIG 4 shows an illustrative aliases data model 400 which provides that aliases are sub-identities of a main account (as indicated by reference numeral 415).
• the main account may be provided by the identity and authentication service 122.
• the identity and authentication service 122 may be implemented as part of Microsoft Windows Live IDTM service so that the main account comprises a Windows Live ID, such as an e-mail address (e.g., "user@live.com", “user@hotmail.com”, etc.), that a user employs to access a variety of on-line services including those that Microsoft Corporation provides as well as those of third parties.
• the main account may be supported by a provider of one of the relying services 115.
• the relying services 115 will agree (for example, through appropriately-scoped service contracts) that a given user 105 will be able to access all the relying services 115 and be authenticated by the identity and authentication service 122 using the main account and its associated aliases.
• the aliases data model 400 further provides that aliases may include various types of identification (420).
• a user (representatively indicated as user 105i) may have available for use one or more aliases 505 that are associated with a main account name 512 (i.e., user@hotmail.com).
• the aliases illustratively include, but are not necessarily limited to e-mail addresses 5051, nicknames 505 2 , mobile phone numbers 5053, and game player profile names referred to as "Gamertags" 505 N in the case of Microsoft Corporation's Xbox LIVE® on-line game service.
• Gamertags game player profile names
• E-mail address aliases 505i may include e-mail addresses from different domains and may be supported by different and/or unrelated relying service providers.
• Nickname aliases 505 2 and gamertag aliases 505 N are names within a domain, although the domain itself will not be exposed to a user 105.
• 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.”
• a user 105 may wish to restrict the exposure of the main account name based on an inquiry using an alias.
• This restriction can be associated with the AUID so that if the name of the alias is changed (e.g., from "Nicknamel" to "Nickname2”), the user's preference regarding privacy is maintained for the new alias name.
• the data model 400 further provides that aliases may have attributes (435) which form the core for defining an identity for a user 105.
• attributes 435
• An illustrative set of attributes 600 is shown in FIG 6.
• the attributes in this example include:
• IsEmail (as indicated by reference numeral 605)
• 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.
• 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 2O69
• 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.
• 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.
• 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.
• 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.
• the aliases data model 400 may be used to define various methods 700 that may be exposed by the identity and authentication service 122 through an API 704 to remote calls from the relying services 115 and applications 302 and 306 (respectively indicated by reference numerals 710 and 714).
• the methods 700 illustratively include:
• the Create Alias method 70Oi 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 IsVerif ⁇ ed 625 will be set so that the created alias 505 is a verified alias.
• the Delete Alias method 70O 2 and Rename Alias method 70O 3 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 70O 4 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.
• FIG 8 shows a first illustrative usage scenario 800 in which a user (representatively shown as user 105i) may sign in to a relying service 115 with an alias using a thin client application 302 running on a desktop client device ⁇ ⁇ 2 ⁇ . While a desktop client device 1 ⁇ 2 ⁇ is used in this example, the usage scenario would be similar for the other client devices shown in FIG 1 and described in the accompanying text. The scenario begins when the user 105i attempts to access the relying service 115 using a web browser with which the thin client application 302 is implemented (as indicated by reference numeral 810).
• the relying service 115 will return a page containing a sign-in link (820).
• the user 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 105i 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).
• 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 105i. However, there is no requirement that the user employ a commonly-utilized password.
• the identity and authentication service 122 authenticates the user 105i 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 redirects the user 105i to the relying service 115 (860).
• 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 105i (870).
• 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 105i by authenticating the underlying main account. This feature guarantees the user 105i access to appropriate content and personalization since the relying service 115 will always recognize the main account name.
• FIG 9 shows a second illustrative usage scenario 900 in which the user 105i may sign in to a relying service 115 with an alias using a thick client application 306 running on a desktop client device 1
• This usage scenario is similar to scenario 800 that employs a thin client application but varies in implementation detail.
• the scenario begins when the user 105i attempts to access the relying service 115 through the application 306 (as indicated by reference numeral 910).
• a sign-in UI user interface
• the user signs in to the UI with an alias and password and the captured credentials are sent to the identity and authentication service 122 (920).
• the client- side aliases interface 315 shown in FIG 3 and described in the accompanying text, can be configured to expose an API to the thick client application to enable the capture and sending functions.
• the identity and authentication service 122 authenticates the user 105i 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).
• the fact that the authentication ticket includes the main account name enables the relying service to appropriately identify the user 105i 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 105i responsively to the request (970).
• FIG 10 shows a third illustrative usage scenario 1000 in which a user may receive e-mail messages that are sent to multiple different e-mail aliases.
• a user 105i at desktop client 112i uses thin client application 302 to interact with a relying service 115 which comprises, in this scenario, a hosted e-mail service.
• the user 105i requests access to a feature of the relying service 115 that enables e-mail messages addressed to multiple different aliases to be collectively retrieved (1010).
• the relying service 115 will return a page containing a sign-in link (1020).
• the identity and authentication service 122 When the user 105i clicks on the link, the user is redirected to the identity and authentication service 122 (1030) to perform authentication of the user 105i on behalf of the relying service 115.
• the identity and authentication service 122 presents a sign-in dialog box with which the user 105i signs in with an alias and password (1040).
• the identity and authentication service 122 authenticates the user 105i 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.
• 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 105i 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.
• 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 (FIG 7) (1070).
• the identity and authentication service 122 returns a list of aliases that the user 105i 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 105i (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.
• FIG 11 shows a fourth illustrative usage scenario 1100 in which a user may be reached by others through an alias.
• a user 105 2 at a laptop client device 112 2 running a thin-client application 302 interacts with a relying service 115 which comprises, in this scenario, an event planning service.
• the user 105 2 wishes to send an invitation to an event to another user 105i (accordingly, and for purposes of clarity in the description that follows the user 105 2 will be referred to as the "host” and the user 105i will be referred to as the "invitee").
• 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).
• the identity and authentication service 122 will not return the main account name in response to the API call.
• 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 redirects the user invitee to the relying service 115 (1180).
• the relying service 115 can then provide the event invitation responsive Iy to the data from the authentication token (1190).
• the event invitation is sent to the invitee's e-mail address.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• Computer Security & Cryptography (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Information Transfer Between Computers (AREA)
• Telephonic Communication Services (AREA)

Applications Claiming Priority (2)

Publications (2)

Family

ID=42074095

Family Applications (1)

Country Status (5)

Families Citing this family (86)

Family Cites Families (40)

• 2008
  • 2008-10-03 US US12/245,580 patent/US20100088753A1/en not_active Abandoned
• 2009
  • 2009-09-18 EP EP09818228A patent/EP2332104A4/de not_active Withdrawn
  • 2009-09-18 WO PCT/US2009/057473 patent/WO2010039460A2/en not_active Ceased
  • 2009-09-18 CN CN2009801398297A patent/CN102171712A/zh active Pending
  • 2009-10-02 TW TW098133608A patent/TW201019676A/zh unknown

Also Published As

Similar Documents

Legal Events