US7921456B2 - E-mail based user authentication - Google Patents

E-mail based user authentication Download PDF

Info

Publication number
US7921456B2
US7921456B2 US11/275,429 US27542905A US7921456B2 US 7921456 B2 US7921456 B2 US 7921456B2 US 27542905 A US27542905 A US 27542905A US 7921456 B2 US7921456 B2 US 7921456B2
Authority
US
United States
Prior art keywords
authentication ticket
service provider
user
mail
authentication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related, expires
Application number
US11/275,429
Other versions
US20070157291A1 (en
Inventor
Fei Chua
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US11/275,429 priority Critical patent/US7921456B2/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHUA, FEI
Publication of US20070157291A1 publication Critical patent/US20070157291A1/en
Application granted granted Critical
Publication of US7921456B2 publication Critical patent/US7921456B2/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0807Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60Digital content management, e.g. content distribution

Abstract

E-mail based user authentication is described herein. A user can access resources of a service provider by submitting only an e-mail address to which the user has access. The service provider generates an authentication ticket corresponding to the user's login request, and transmits the authentication ticket to the e-mail service provider indicated by the submitted e-mail address. The e-mail service provider processes the authentication ticket, and enables either approval or denial of the authentication ticket, whether by explicit user action or by automated processing.

Description

BACKGROUND

Many websites available on the internet may ask visitors to register or otherwise establish an account in order to access some or all of the content or services offered by the websites. As a given user visits a variety of different sites, he or she may be asked to register at numerous different sites. If the user wises to register under his or her own name, the user may find that a preferred name is already taken at one or more given sites. Thus, a user named “John Doe” may have to register under “John Doe1” at one site, under “John Doe11” at another site, under “J_Doe” at a third site, and so on. These different user names may prove burdensome for users to remember, and may be forgotten over time. Accordingly, some users may choose to maintain a written or recorded list of the usernames under which they are registered at different websites.

Another complication is that different websites may implement different password policies, in terms of overall length, complexity, and alphanumeric composition. Thus, if a user has a favorite password, this favorite password may be acceptable to some websites, but not acceptable to others. Thus, the user may have to create and remember a variety of different passwords to comply with password polices in effect at different sites. Once again, these different passwords may prove difficult to remember, and users may record them to avoid relying entirely on memory.

Users may also consider the content or subject matter of a given website when choosing a user name under which to register. For a variety of reasons, the users may wish to register under a relatively anonymous user name. Thus, John Doe, from the example above, may wish to sign on to a discussion forum under the name “User A” to preserve his privacy. Because these anonymous user names may also be difficult to remember over time, users may either forget their anonymous user names, or choose to record them for later reference.

SUMMARY

Systems and/or methods (“tools”) are described that enable e-mail based user authentication. A user can access resources of a service provider by submitting only an e-mail address to which the user has access. The service provider generates an authentication ticket corresponding to the user's login request, and transmits the authentication ticket to the e-mail service provider indicated by the submitted e-mail address. The e-mail service provider processes the authentication ticket, and allows only the user indicated by the submitted e-mail address access to the authentication ticket, thus enabling that specific user access to the service provider's resources. During this authentication process, the approval or denial of the authentication ticket can either be automated or by explicit user action.

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 or essential features of the claimed is subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTIONS OF THE DRAWINGS

The same numbers are used throughout the disclosure and figures to reference like components and features.

FIG. 1 is a combined block and data flow diagram of an operating environment for performing e-mail based user authentication.

FIG. 2 is a block diagram of a data structure that may be suitable for implementing an authentication request as shown in FIG. 1.

FIG. 3 is a flowchart of an overall process flow for performing e-mail based user authentication.

FIG. 4 is a flowchart of a process flow that may be executed by a service provider in performing e-mail based user authentication.

FIG. 5 is a flowchart of a process flow that may be executed by an e-mail server in performing e-mail based user authentication.

DETAILED DESCRIPTION

Overview

The following document describes system(s) and/or method(s) (“tools”) capable of many techniques and processes. The following discussion describes exemplary ways in which the tools enable e-mail based user authentication. This discussion also describes ways in which the tools perform other techniques as well.

This document is organized into sections for convenience, with the sections introduced by headings chosen for convenience, but not limitation. First, an illustrative Operating Environment for performing e-mail based user authentication is described. Then, illustrative Data Structures are described, followed by illustrative Process Flows.

Operating Environment

Before describing the tools in detail, the following discussion of an exemplary operating environment is provided to assist the reader in understanding one way in which various aspects of the tools may be employed. The environment described below constitutes but one example and is not intended to limit application of the tools to any one particular operating environment. Other environments may be used without departing from the spirit and scope of the claimed subject matter.

FIG. 1 illustrates one such operating environment for performing e-mail based user authentication, generally at 100. The operating environment 100 can comprise a workstation 102 having one or more processor(s) 104 and computer-readable media 106. The workstation 102 can comprise a computing device, such as a cell phone, desktop computer, personal digital assistant, server, or the like. The processor 104 can be configured to access and/or execute the computer-readable media 106. The computer-readable media 106 can comprise or have access to an application 108, which may be implemented as a module, program, or other entity capable of interacting with a network-enabled entity. The application 108 may take the form of a browser such as, for example, the Internet Explorer® web browser available from Microsoft Corporation of Redmond, Wash. The application 108 may also take the form of an e-mail client, such as, for example, the Outlook® or Outlook Express® e-mail application or web-based email such as the Hotmail® service, also available from Microsoft. It is understood that the applications 108 may take forms other than the specific examples given above.

A user 110 may interact with the application 108 to request access to content or services offered by, published by, or otherwise associated with a service provider 112. For example, the service provider 112 may be a website accessible to a plurality of users 110 over a network (not shown), such as the Internet. Non-limiting examples of such a website can include a retail website offering goods or service for on-line purchase by the users 110, an on-line discussion forum relating to goods or services of interest to some segment of the users 110, a website listing real estate or other properties for sale, or the like.

Typically, to access at least some content or services offered by the service provider 112, the user 110 can log in to the service provider 112. In the context of the operating environment 100, the user 110 can request access to the service provider 112 by providing his or her e-mail address 114. The e-mail address 114 may be considered an authentication request, for the purposes of this description. It is assumed that the user 110 has an e-mail address and related account with an e-mail or Internet service provider (ISP), which is represented in FIG. 1 by e-mail server 116.

Returning to the service provider 112, having received the user's e-mail address 114, the service provider 112 can authenticate the user 110 by passing an authentication ticket 118 to the e-mail server 116. More specifically, the authentication ticket 118 can be directed to a user name extracted from the e-mail address 114. For example, assume that the user 110 provides an e-mail address 114 in the form of “john.doe@hotmail.com”. The e-mail server 116 in this example would be identified by “hotmail.com”, and the e-mail server 116 would direct the authentication ticket 118 to the username “john.doe” on this ISP.

The authentication ticket 118 can include, for example, a key 120 and a pass code 122. The service provider 112 can create a unique instance of the key 120 and the pass code 122 for each authentication request (114) received from the users 110. The key 120 may be, for example, a GUID (globally unique ID) or a hash which uniquely identifies the authentication ticket. The pass code 122 is paired with each key 120, and assuming that the user 110 is properly authenticated to the e-mail/authentication server 116 in the operating environment 100, the ticket 122 is eventually retrieved by the user 110 and returned to the service provider 112, as described in further detail below.

The e-mail server 116 can receive the authentication ticket 118, with the related key 120 and pass code 122 embedded in it. Assuming that the e-mail address 114 is valid on the e-mail server 116, the e-mail server 116 can then forward the authentication ticket 118 to the user name indicated in the e-mail address 114. The authentication ticket 118 can be transmitted in the form of, for example, an e-mail message or an XML message over HTTP/HTTPS or an instant message (IM) directed to the user name that was extracted from the input e-mail address 114. Thus, the authentication ticket 118 can be made available to a user 110 on, for example, the workstation 102, using the application 108. This authentication ticket delivery process can be initiated either by the server 116 or by the user 110, depending on whether a push or pull model is employed.

Assume that a given user 110 has requested access to the service provider 112, and has submitted the e-mail address/authentication request 114 in connection with that request, as discussed above. Assume further that this user 110 also has access to messages sent to the e-mail address 114, and is logged in his e-mail account at the workstation 102 when he provides his e-mail address 114 to the service provider 112. The user 110 can be presented with a user interface 124 that is displayed on the workstation 102, in response to receiving the authentication ticket 118. As described further below, some implementations of the operating environment 100 may not include the user interface 124. Thus, the block representing the user interface 124 in FIG. 1 is shown in dashed outline to convey its optional status. Generally herein, for convenience only, dashed outlines in the drawing figures suggest that the corresponding features may be considered optional in some implementations. However, this convention does not mean that other features are to be considered mandatory in nature.

The user interface 124 can include text, such as that shown in FIG. 1, asking whether the user 110 wishes to access resources associated with a particular service provider 112. For example, the user interface 124 may prompt the user 110 whether he or she wishes to log in to a particular website having a given URL. The user interface 124 may include a “Yes” field 126 that is responsive to user input to indicate that the user 110 wishes to grant the authentication ticket 118, and a “No” field 128 that is responsive to user input to indicate that the user 110 wishes to deny the authentication ticket 118.

If a given user 110 submits the e-mail address 114 in connection with a request to access the service provider 112, and also has access to the e-mail address 114, then this user 110 will see the user interface 124 appear on the workstation 102 shortly after submitting the request to access the service provider 112. This same user 110 can click the “Yes” field 126, indicating approval of the authentication ticket 118. Recall that the authentication ticket 118 as sent by the e-mail server 116 can include the key 120 and the pass code 122. In response to a click on the “Yes” field 126, the application 108 presenting the user interface 124 can extract the key 120 the pass code 122 from the authentication ticket 118, and forward the key 120 pass code 122 to the service provider 112. The data sent from the application 108 to the service provider 112 is represented generally as disposition data 130.

Recall further that the service provider 112 generated the key 120 and pass code 122 when previously sending the authentication ticket 118 to the e-mail server 116. In some implementations, the service provider 112 can store this key 120/pass code 122 pair for later reference.

To authenticate a given user, the service provider 112 can compare a key 120 and pass code 122 that are received from the application 108 to the key 120 and pass code 122 that were transmitted as part of the authentication ticket 118. If the pass code 122 and key 120 as received from the application 108 correspond to the ticket 118 that was sent previously in connection with the authentication request 114, then the service provider 112 can be reasonably certain that the user 110 is authenticated by the e-mail server. Therefore, the service provider 112 can log the user 110 in, and allow the user 110 to access the resources or content of the service provider 112. These resources or content are represented generally in FIG. 1 by content 132, which may be web pages and/or cookies, for example.

In some implementations, when defining the authentication ticket 118 with related key 120 and/or pass code 122, the service provider 112 can specify a time limit or expiration period associated with the ticket 118. If the ticket 118 is defined with a time limit, then the ticket can be treated as invalid after that time limit expires. The service provider 112 can be adapted not to accept the authentication ticket 118 from the user 110 after this period expires, even if the ticket is otherwise valid and is returned to the service provider 112 as otherwise described herein. The duration of this time interval can be chosen, for example, based on security considerations or based on the performance of the network connecting the service provider 112, the user 110, and the e-mail server 116. The protocols chosen for implementing the communications among the service provider 112, the user 110, and the e-mail server 116 may also be factors in defining the time interval.

The foregoing description assumes that the same user 110 requested access to the service provider 112, and also had access to messages sent to the e-mail address 114. Thus, the user 110 could be authenticated to access the service provider 112, because he or she received and responded to the authentication ticket 118 via the e-mail address 114 and/or the e-mail server 116.

In other instances, the user 110 may not have access to the e-mail address 114, or may fail to respond to the user interface 124 in a timely manner. For example, the user 110 may innocently provide the wrong e-mail address 114, or may willfully provide an invalid e-mail address 114 in an effort to access the service provider 112 under someone else's name. More particularly, assume that a user 110 named “John Doe” wishes to access a given website having a URL <badsite.com>, and that the badsite.com website implements the operating environment 100. To access badsite.com, John Doe provides an e-mail address 114 in the form of “Jane Smith@hotmail.com”. However, John Doe does not know Jane Smith, and is not authorized to access Jane Smith's e-mail account. Nevertheless, John tries Jane's e-mail, just in case it might work. In this example, the authentication ticket 118 is sent to Jane's e-mail account. In response to the authentication ticket 118, a user interface 124 may or may not be displayed by an application 108 on Jane Smith's workstation 102.

As discussed above, the user interface 124 may ask Jane if she wishes to log into badsite.com. In some implementations, assuming that the authentication ticket 118 indicates the name of the website, the user interface 124 may indicate that Jane Smith is requesting permission to access badsite.com via Jane's e-mail address 114. If Jane is logged into her e-mail account, she may see the user interface 124. If she has not submitted a request to access badsite.com, she can click on the “No” field 128 of the user interface 124 to reject John Doe's access request.

Continuing with this example, assume that the badsite.com website defines a time limit for the key 120/pass code 122 generated for John's authentication ticket 118. If Jane is not at her workstation 102 or is not logged in to the application 108 when the authentication ticket 118 arrives, she will most likely not see the user interface 124 before the time limit expires. Thus, she will not approve the authentication ticket 118 in time, and the ticket 118 will expire. Even if the ticket 118 is later sent to the service provider 112, the ticket 118 will have expired, and John's authentication request, corresponding to his submitted e-mail address 114, is denied.

It is understood that in the above example, Jane could also accidentally approve John's authentication ticket 118 in the case where the implementation calls for the log-in UI 124. In this case, she would click the “Yes” field 126 in a timely manner, and the pass code 120 would be sent to the service provider 112, as discussed above. Jane would then gain access to the service provider's 112 resources, not John who initiated the request. Other implementations may not include the UI 124. In such cases, (i.e., those implementations without the UT 124), the authentication ticket 118 initiated by John's log-in request would simply expire because: (1) John is denied access when he tries to retrieve the ticket 118, and/or (2) Jane never see the UI 124 and thus does not retrieve the ticket 118.

Having provided the above description of the operating environment 100, several observations are now noted. The operating environment 100 enables the e-mail server 116 to become an authentication server for the service provider 112. More particularly, the operating environment 100 enables the service provider 112 to log-in the users 110 by leveraging pre-existing, authenticated relationships between the users 110 and their respective e-mail servers 116. In addition, the users 110 can log-in to the service provider 112 using only an e-mail address, and need not provide any password to the service provider 112.

Additionally, the user 110 can log in to the service provider 112 without previously establishing a username-password combination with the service provider 112, or establishing any other ongoing relationship or registration with the service provider 112. Also, the user 110 need not provide a username-password combination to the service provider 112 when logging in. Instead, the user 110 provides only the e-mail address 114 to the service provider 112. While the user 110 may provide a username-password combination to access the e-mail server 116 in order to receive and respond to the authentication ticket 118, this is distinguished from providing such a username-password combination to the service provider 112. Accordingly, the operating environment 100 relieves the user 110 from having to remember a multitude of different username-password combinations under which the user 110 logs in to various service providers 112. Instead, the user 110 need only remember his or her e-mail address to access a plurality of different service providers 112.

It is also noted that the user 110 may choose to define a plurality of different e-mail addresses 114, and then choose which e-mail address 114 to use when logging in to different service providers 112. For example, the user 110 may assign a different level of trust or care to each of his or her different e-mail addresses 114, and may factor that into account when accessing the different service providers 112. Additionally, the user 110 may compose the e-mail addresses 114 differently, depending on the context or the environment of the different service providers 112 that the user 110 intends to visit using the e-mail addresses 114. For example, if the user 110 anticipates visiting hacker discussion forums, the user 110 might define an anonymous e-mail address 114, such as UserA@hotmail.com, for use in such forums.

Data Structures

The tools described and illustrated herein may utilize data structures as part of their implementation and/or operations to perform e-mail based user authentication. Examples of such data structures are now described.

FIG. 2 illustrates a data structure 200 that may be suitable for implementing the authentication ticket 118. As noted above, the authentication ticket 118 can reference a key 120 and/or pass code 122. Thus, the data structure 200 can contain fields 120 and 122 for these values. In addition, however, some implementations of the authentication ticket 118 can reference the name or other identification of the user 110 who requesting access to the service provider 112. The authentication ticket 118 could also reference a URL or other identification of the service provider 112 or website to which the user 110 is requesting access. Accordingly, some implementations of the data structure 200 can include a field 202 for the identification of the user 110, and a field 204 for the identification of the service provider 112 or website. Both of the fields 202 and 204 are shown in FIG. 2 in dashed outline, for convenience only.

The data structure 200 can enable the user interface 124 to be tailored to each particular authentication ticket 118, so that the user 110 being asked to approve or deny the authentication ticket 118 can do so in a more informed manner. More specifically, the application 108 may extract the contents of the fields 202 and 204 when populating the user interface 124 for presentation to the user 110.

Having described the foregoing examples of the fields 120, 122, 202 and 204, it is understood that various implementations of the data structure 200 could include one or more of these example fields 120, 122, 202 and 204, or may contain additional data, fields, or sub-fields other than those illustrated in FIG. 2. In addition, the layout, names, and configuration of the fields or sub-fields of the data structure 200 are illustrative only, and are chosen only for convenience of illustration and description, and do not limit possible implementations of the data structure 200. It is further understood that given instances of the data structure 200 may be associated with the authentication tickets 118, but each instance of the data structure 200 need not have populated each field and/or sub-field as shown in FIG. 2.

Process Flows

The tools as described herein can implement various process flows to perform e-mail based user authentication. Examples of such process flows are now described.

FIG. 3 illustrates an overall process flow 300 that may be performed to conduct e-mail based user authentication. For convenience and ease of discussion, the process flow 300 is described here in connection with certain aspects of the operating environment 100. However, it is understood that the process flow 300 may be implemented on devices or components other than those shown in the operating environment 100 without departing from the spirit and scope of the description herein.

Block 302 obtains an e-mail address 114 from the user 110, in connection with the user's request to access resources associated with a service provider 112. Block 304 sends the authentication ticket 118 to the user as indicated by the input e-mail address 114 via the corresponding e-mail server 116 to authenticate the user 110. Block 306 presents a user interface 124 to a user 110 as indicated by the input e-mail address 114. Block 306 can enable the user 110, to whom the authentication ticket 118 was sent, to approve or deny the authentication ticket 118, by clicking or otherwise interacting with the user interface 124. In implementations that do not include the user interface 124, a counterpart to block 306 could be performed automatically by a client process running on the workstation 102.

Block 308 tests whether the authentication ticket 118 was approved. In some implementations, block 308 can test whether the user 110 seeking access to the service provider 112 is the same as the user 110 to whom the authentication ticket 118 was sent. In other implementation, these two users 110 may not be the same, but the user 110 receiving the authentication ticket 118 may nevertheless approve the authentication ticket 118, allowing access to the service provider 112. In any event, if the authentication ticket 118 was approved, block 310 grants the user specified by the e-mail address 114 login or other access to the service provider 112.

Returning to block 308, if the authentication ticket 118 is expressly denied, or if the authentication ticket 118 is not approved in a timely manner, then block 312 denies the user 110 access to the service provider 112. Recall that the service provider 112 can establish a time limit within which the authentication ticket 118 is to be approved. If the time limit expires before the authentication request 118 is approved, any pass code 122 or other such item associated with authentication request 118 can expire and not serve as a basis for authenticating the user 110.

FIG. 4 illustrates a process flow 400 for performing e-mail based user authentication. While the process flow 400 is described herein in connection with tools such as the service provider 112, the process flow 400 could also be implemented by or with other tools without departing from the spirit and scope of the description herein.

Block 402 receives the e-mail address 114 from the user 110, in connection with a request from the user 110 to access the service provider 112. To obtain the e-mail address 114 from the user 110, the service provider 112 might present a user interface 404, as shown also in FIG. 4.

In some implementations, the user interface 404 may support e-mail based user authentication and username-password login, allowing the user 110 to choose which login method to use. Accordingly, the example user interface 404 shown in FIG. 4 includes a field 406 for a username, a field 408 for a password, and a field 410 for an e-mail address. If the user 110 enters data into the field 410, the fields 406 and 408 may be grayed-out so as not to accept user input. However, in other implementations, the user interface 404 can be configured to support only e-mail based user authentication. In this implementation, fields 406 and 408 may be deleted entirely.

In another implementation, block 402 can recognize that a user 110 wishes to perform e-mail based authentication by testing for input into field 406 for any occurrence of the “@” symbol entered. In this case, field 410 can be omitted from the user interface 404.

Block 412 sends an authentication ticket 118 to an e-mail server 116, which is identified based on the input e-mail address 114. As discussed above, the contents of the data structure 200, at least in part, can be used in connection with the authentication ticket 118.

Block 414 dispositions the authentication ticket 118. More particularly, block 416 can test whether a data element such as the pass code 122 was received by the service provider 112. Block 416 can also check whether the received ticket 118 was well-formatted, i.e., free from any corruption or violation that may have occurred during transmission. In addition, recall that some implementations of the ticket 118, and related elements such as the key 120 and the pass code 122, can expire after some interval of time. In such implementations, block 416 can check whether the ticket 118 was received before it expired. If yes, then block 418 can test whether the correct pass code 122 and key 120 was received. If yes from block 418, then block 420 approves the authentication ticket 118.

From block 418 or block 416, if the “no” branch is taken, then block 422 denies the authentication ticket 118.

Block 424 dispositions the request from the user 110 to access the service provider 112, based on how the authentication ticket 118 was dispositioned in block 414 (e.g., via blocks 416-422). For example, block 426 can test how the authentication ticket 118 was dispositioned. If the authentication ticket 118 was approved, then block 428 can grant the user 110 access to the resources provided by the service provider 112. Otherwise, block 430 can deny the user 110 access to the resources provided by the service provider 112.

FIG. 5 illustrates a process flow 500 for performing e-mail based user authentication. While the process flow 500 is described herein in connection with tools such as the e-mail server 116, the process flow 500 could also be implemented by or with other tools without departing from the spirit and scope of the description herein.

Block 502 enables a user 110 to log into the e-mail server 116 so as to access any incoming messages addressed to the user 110. Recall that the authentication ticket 118 can be routed to the e-mail address 114 provided by a user 110 who is requesting access to the service provider 112. Recall also that the ticket 118, and/or related elements such as the key 120 and pass code 122, as issued by the service provider 112 may be valid only for a limited period of time. Thus, it may be advisable for the user 110 to be logged-in with his or her e-mail server 116 when he or she submits a request to access the service provider 112 using e-mail based user authentication.

Block 504 receives the authentication ticket 118, which may be sent by, for example, the service provider 112. Block 506 validates the contained e-mail address 114 provided by the user 110. If the user name in the input e-mail address 114 does not exist in the domain of the e-mail server 116, then the e-mail server 116 can choose to report or not report this error condition back to the service provider 112 based on the e-mail provider's policies. In such an implementation, the authentication ticket 118 is not forwarded to the user's 110 email server 116, because such user 110 does not exist on the e-mail server 116. This condition would result in denying the authentication ticket 118, with an appropriate message being provided to the user 110. Block 506 is shown in dashed outline because it may be considered an optional error check. Some implementations of the process flow 500 may instead transmit the authentication ticket 118 without first error-checking the e-mail address 114.

Block 508 presents a user interface, such as the user interface 124 shown in FIG. 1, to the user 110 who logged into the e-mail server 116 in block 502. This user interface 124 presents data related to the authentication ticket 118, and may operate in connection with a data structure such as the data structure 200. Block 508 is shown in dashed outline to suggest its optional status. In some implementations, the ticket 118 may be approved by a client or browser on the workstation 102 that is active when the user 110 is logged in to his or her e-mail account. Block 510 enables the user 110 or the client to approve or deny the authentication ticket 118.

Having provided the foregoing description, the following further observations are noted. The message flows between the workstation 102 and the service provider 112 can be implemented using, for example, the Hypertext Transfer Protocol (HTTP). The message flows between the e-mail server 116 and the service provider 112, as well as the message flows between the e-mail server 116 and the workstation 102, can be implemented using, for example, the Hypertext Transfer Protocol (HTTP), the Simple Mail Transfer Protocol (SMTP) or the Extensible Messaging and Presence Protocol (XMPP).

It is noted that some implementations of SMTP may not guarantee delivery of messages within a given time interval. Recall that the authentication ticket 118 and the ticket 122 may be valid only for a limited time. Accordingly, some implementations of the operating environment 100 may extend SMTP to provide header-level information for any messages relating to e-mail based user authentication, such as the authentication ticket 118, for example. This header-level information may be processed so as to give additional priority to those messages relating to e-mail based user authentication, to enable the authentication ticket 118 to be acted upon before it expires.

In those implementations of the application 108 that take the form of browser software, the browser may be adapted with a light or thin instant-message (IM) client. This IM client may enable the operating environment 100 to execute with quality of service (QoS) guarantees sufficient to prevent expiration of authentication ticket 118 due to message transmission or protocol errors. Additionally, for added security, messages passed within the operating environment 100 may be encrypted using key pairs or the Secure Sockets Layer (SSL) protocol.

In some implementations of the application 108 that take the form of browser software, the browser may be adapted to proactively recognize that the user 110 is using e-mail based authentication. In this case, the browser may extract the e-mail address 114 provided by the user 110, and determine which e-mail server 116 is associated with that e-mail address 114. The browser may then poll the e-mail server 116 once every time interval, for example once every second for about 5-6 seconds, asking the e-mail server 116 for the authentication ticket 118. If the user 110 is logged into the e-mail server 116 using the workstation 102 on which the browser is executing, then the browser can communicate with the e-mail server 116. When the browser receives the authentication ticket 118, the browser can forward it to the service provider 112. This implementation relieves the user 110 from any e-mail or IM interactions with the user interface 124, thereby automating the process to some degree, in exchange for a more complex and sophisticated browser.

It is also noted that typical e-mail servers may be configured to communicate primarily via an e-mail port. Accordingly, in some implementations of the operating environment 100, the e-mail server 116 may be configured with one or more additional, non-e-mail ports, so as to communicate with components such as the service provider 112.

CONCLUSION

Although the system and method has been described in language specific to structural features and/or methodological acts, it is to be understood that the system and method defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed system and method.

In addition, regarding certain flow diagrams described and illustrated herein, it is noted that the processes and sub-processes depicted therein may be performed in orders other than those illustrated without departing from the spirit and scope of the description herein.

Claims (10)

1. A method comprising:
receiving at least one e-mail address from a given user in connection with a request submitted by the given user to access resources of a service provider, the e-mail address corresponding to one of a plurality of email addresses, each email address corresponding to a different third-party e-mail server to which the given user has access, wherein each e-mail address is associated with a different level of trust relative to the other e-mail addresses;
sending at least one authentication ticket to a third-party e-mail server corresponding to the at least one e-mail address, the third-party e-mail server being chosen based upon the at least one e-mail address received from the given user, wherein sending the at least one authentication ticket includes:
sending a key, a pass code, and an associated predefined time interval with the at least one authentication ticket, wherein the key uniquely identifies the at least one authentication ticket, and wherein the at least one authentication ticket is sent as header-level information to the third-party e-mail server and the third party e-mail server processes authentication tickets sent as header-level information with a high priority as compared to e-mail messages that enable the authentication ticket to be acted upon prior to an end of the associated predefined time interval; and
referencing a first field for the identification of the given user and a second field for the identification of the service provider;
receiving at least one of an additional key and an additional pass code, from a user device, after sending the at least one authentication ticket to the third-party e-mail server corresponding to the at least one e-mail address;
dispositioning the authentication ticket; and
dispositioning the request submitted by the user device based upon the disposition of the authentication ticket, wherein dispositioning the authentication request includes approving the authentication ticket when the at least one of the additional key and pass code matches one of the key and the pass code of the at least one authentication ticket sent to the third-party e-mail server.
2. The method of claim 1, wherein receiving at least one e-mail address includes receiving the e-mail address in connection with a request to login to a website associated with the service provider.
3. The method of claim 1, wherein dispositioning the authentication request includes denying the authentication request when neither of the additional key and pass code matches the key and pass code of the authentication ticket.
4. The method of claim 1, wherein dispositioning the authentication request includes denying the authentication request when no additional key or pass code is received within the predefined time interval.
5. The method of claim 1, wherein dispositioning the request includes granting the request when the authentication ticket is approved.
6. The method of claim 1, wherein dispositioning the request includes denying the request when the authentication ticket is denied.
7. The method of claim 1, wherein dispositioning the request is performed without obtaining a password from the given user.
8. A method comprising:
presenting an interface on a computing device to a given user;
receiving, through the interface, a request for access to a resource of a service provider;
obtaining, through the interface, an e-mail address from a plurality of e-mail addresses associated with the given user, and wherein each e-mail address corresponds to a different third-party e-mail server and is associated with a different level of trust relative to the other email addresses;
authenticating, by the computing device, with an e-mail server associated with the e-mail address;
sending the request for access and the e-mail address to the service provider;
receiving, by the computing device, an authentication ticket from the e-mail server, the receiving comprising polling the email server about every second for about 5 seconds by querying the email server for the authentication ticket, the authentication ticket comprising:
a key,
a pass code,
an associated expiration period, and
a first field referencing the identification of the given user and a second field referencing the identification of the service provider;
sending, by the interface, at least a portion of the authentication ticket to the service provider, wherein the at least a portion of the authentication ticket is sent as header-level information to the service provider and the service provider processes the at least a portion of the authentication ticket sent as header-level information with a high priority as compared to an e-mail message, enabling the authentication ticket to be acted upon prior to an end of the associated expiration period;
receiving, by the interface, an indication of a disposition of the request for access, wherein the disposition is based on the at least a portion of the authentication ticket; and
receiving, by the computing device, access to the resource of the service provider.
9. The method of claim 8, further comprising after receiving the authentication ticket from the e-mail server, providing an interface element that allows a user to either grant permission to the computing device to send the at least a portion of the authentication ticket to the service provider or deny permission to the interface to send the at least a portion of the authentication ticket to the service provider.
10. The method of claim 1, wherein each of the plurality of email addresses is composed differently to conform to use in different environments and contexts of different service providers.
US11/275,429 2005-12-30 2005-12-30 E-mail based user authentication Expired - Fee Related US7921456B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/275,429 US7921456B2 (en) 2005-12-30 2005-12-30 E-mail based user authentication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/275,429 US7921456B2 (en) 2005-12-30 2005-12-30 E-mail based user authentication
US13/029,563 US8533792B2 (en) 2005-12-30 2011-02-17 E-mail based user authentication

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/029,563 Continuation US8533792B2 (en) 2005-12-30 2011-02-17 E-mail based user authentication

Publications (2)

Publication Number Publication Date
US20070157291A1 US20070157291A1 (en) 2007-07-05
US7921456B2 true US7921456B2 (en) 2011-04-05

Family

ID=38226244

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/275,429 Expired - Fee Related US7921456B2 (en) 2005-12-30 2005-12-30 E-mail based user authentication
US13/029,563 Active US8533792B2 (en) 2005-12-30 2011-02-17 E-mail based user authentication

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/029,563 Active US8533792B2 (en) 2005-12-30 2011-02-17 E-mail based user authentication

Country Status (1)

Country Link
US (2) US7921456B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060026438A1 (en) * 2004-07-29 2006-02-02 Microsoft Corporation Anonymous aliases for on-line communications
US20090288153A1 (en) * 2008-05-15 2009-11-19 Canon Kabushiki Kaisha Information processing apparatus and control method
US9154473B1 (en) * 2011-07-06 2015-10-06 CRRC, Inc. Electronic communications management system and method
US9191369B2 (en) 2009-07-17 2015-11-17 Aryaka Networks, Inc. Application acceleration as a service system and method
US10044735B2 (en) * 2015-04-09 2018-08-07 Secure Information Devices Inc. System and method for authentication of electronic communications

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8151116B2 (en) * 2006-06-09 2012-04-03 Brigham Young University Multi-channel user authentication apparatus system and method
US20080228675A1 (en) * 2006-10-13 2008-09-18 Move, Inc. Multi-tiered cascading crawling system
EP2332053B1 (en) * 2008-09-30 2015-12-02 Hewlett-Packard Development Company, L.P. Authentication of services on a partition
US8521821B2 (en) * 2009-03-17 2013-08-27 Brigham Young University Encrypted email based upon trusted overlays
JP5703791B2 (en) * 2011-01-31 2015-04-22 セイコーエプソン株式会社 Printing system and printer
US9542545B2 (en) 2011-03-21 2017-01-10 Webcetera, L.P. System, method and computer program product for access authentication
US8839400B2 (en) 2012-09-27 2014-09-16 International Business Machines Corporation Managing and controlling administrator access to managed computer systems
US20140101733A1 (en) * 2012-10-09 2014-04-10 Troy Jason Cain System and method for secure user authentication with a single action
US20140172985A1 (en) * 2012-11-14 2014-06-19 Anton G Lysenko Method and system for forming a hierarchically complete, absent of query syntax elements, valid Uniform Resource Locator (URL) link consisting of a domain name followed by server resource path segment containing syntactically complete e-mail address
US9704190B2 (en) * 2013-02-01 2017-07-11 @Pay Ip Holdings Llc Email checkout system for completing website cart checkout
US9088562B2 (en) 2013-09-09 2015-07-21 International Business Machines Corporation Using service request ticket for multi-factor authentication
JP6248641B2 (en) * 2014-01-15 2017-12-20 株式会社リコー Information processing system and authentication method
US10218701B2 (en) * 2016-03-09 2019-02-26 Avaya Inc. System and method for securing account access by verifying account with email provider

Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5684950A (en) 1996-09-23 1997-11-04 Lockheed Martin Corporation Method and system for authenticating users to multiple computer servers via a single sign-on
US6115040A (en) 1997-09-26 2000-09-05 Mci Communications Corporation Graphical user interface for Web enabled applications
US6134658A (en) * 1997-06-09 2000-10-17 Microsoft Corporation Multi-server location-independent authentication certificate management system
US6182227B1 (en) * 1998-06-22 2001-01-30 International Business Machines Corporation Lightweight authentication system and method for validating a server access request
US6360254B1 (en) * 1998-09-15 2002-03-19 Amazon.Com Holdings, Inc. System and method for providing secure URL-based access to private resources
US20020073343A1 (en) 1999-12-14 2002-06-13 Ziskind Benjamin H. Integrated internet messenger system and method
US20020087649A1 (en) * 2000-03-16 2002-07-04 Horvitz Eric J. Bounded-deferral policies for reducing the disruptiveness of notifications
US6460141B1 (en) * 1998-10-28 2002-10-01 Rsa Security Inc. Security and access management system for web-enabled and non-web-enabled applications and content on a computer network
US6463533B1 (en) * 1999-04-15 2002-10-08 Webtv Networks, Inc. System for generating site-specific user aliases in a computer network
US20020156905A1 (en) 2001-02-21 2002-10-24 Boris Weissman System for logging on to servers through a portal computer
US6496931B1 (en) * 1998-12-31 2002-12-17 Lucent Technologies Inc. Anonymous web site user information communication method
US6535586B1 (en) * 1998-12-30 2003-03-18 At&T Corp. System for the remote notification and retrieval of electronically stored messages
US20030126259A1 (en) 2001-12-27 2003-07-03 Fuji Xerox Co., Ltd. Mail server, electronic mail transmission control method for the mail server, and electronic mail system
US6591291B1 (en) * 1997-08-28 2003-07-08 Lucent Technologies Inc. System and method for providing anonymous remailing and filtering of electronic mail
US20030163691A1 (en) * 2002-02-28 2003-08-28 Johnson Ted Christian System and method for authenticating sessions and other transactions
US20030182383A1 (en) * 2002-02-12 2003-09-25 Xiaopeng He Enterprise electronic mail filtering and notification system
US6725269B1 (en) * 1999-12-02 2004-04-20 International Business Machines Corporation System and method for maintaining multiple identities and reputations for internet interactions
US20040088357A1 (en) * 2002-11-01 2004-05-06 Harding Michael A. Method and apparatus for applying personalized rules to e-mail messages at an e-mail server
US6895558B1 (en) 2000-02-11 2005-05-17 Microsoft Corporation Multi-access mode electronic personal assistant
US20050114453A1 (en) * 2003-11-17 2005-05-26 Hardt Dick C. Pseudonymous email address manager
US20050188008A1 (en) 2001-02-21 2005-08-25 Boris Weissman System for communicating with servers using message definitions
US20050193211A1 (en) 2003-11-12 2005-09-01 Hiroyasu Kurose Management of user authentication information together with authentication level
US20050204011A1 (en) * 2004-03-12 2005-09-15 Hewlett-Packard Development Company, L.P. Dynamic private email aliases
US20050273843A1 (en) 2004-06-02 2005-12-08 Canon Kabushiki Kaisha Encrypted communication method and system
US20060026438A1 (en) * 2004-07-29 2006-02-02 Microsoft Corporation Anonymous aliases for on-line communications
US7003661B2 (en) 2001-10-12 2006-02-21 Geotrust, Inc. Methods and systems for automated authentication, processing and issuance of digital certificates
US20060048212A1 (en) 2003-07-11 2006-03-02 Nippon Telegraph And Telephone Corporation Authentication system based on address, device thereof, and program
GB2418330A (en) 2004-09-17 2006-03-22 Jeroen Oostendorp E-mail filter with user specific rules for virus, spam and content filtering and pre-filtering operations
US7054906B2 (en) * 2000-12-29 2006-05-30 Levosky Michael P System and method for controlling and organizing Email

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5822526A (en) * 1996-06-03 1998-10-13 Microsoft Corporation System and method for maintaining and administering email address names in a network
US6192407B1 (en) * 1996-10-24 2001-02-20 Tumbleweed Communications Corp. Private, trackable URLs for directed document delivery
US6038597A (en) * 1998-01-20 2000-03-14 Dell U.S.A., L.P. Method and apparatus for providing and accessing data at an internet site
US6266692B1 (en) * 1999-01-04 2001-07-24 International Business Machines Corporation Method for blocking all unwanted e-mail (SPAM) using a header-based password
US6615348B1 (en) * 1999-04-16 2003-09-02 Intel Corporation Method and apparatus for an adapted digital signature
US6640301B1 (en) * 1999-07-08 2003-10-28 David Way Ng Third-party e-mail authentication service provider using checksum and unknown pad characters with removal of quotation indents
JP3297037B2 (en) * 2000-10-31 2002-07-02 サイボウズ株式会社 Information registration support system, information registration support device and method, and information storage medium
FR2832846B1 (en) * 2001-11-26 2005-12-09 Commissariat Energie Atomique Compact nuclear water reactor under pressure
US20030163423A1 (en) * 2002-02-27 2003-08-28 Teleglobal International Ltd. Method and apparatus for secure electronic payment
US20030194968A1 (en) * 2002-04-15 2003-10-16 Young Steven Jay System and method for local modulation and distribution of stored audio content
US20040054741A1 (en) * 2002-06-17 2004-03-18 Mailport25, Inc. System and method for automatically limiting unwanted and/or unsolicited communication through verification
US6999962B2 (en) * 2002-08-13 2006-02-14 Xerox Corporation Shared document repository with coupled recommender system
US6895568B2 (en) * 2002-09-30 2005-05-17 Sun Microsystems, Inc. Correction of spacing violations between pure fill via areas in a multi-wide object class design layout
US7353282B2 (en) * 2002-11-25 2008-04-01 Microsoft Corporation Methods and systems for sharing a network resource with a user without current access
JP2004341883A (en) * 2003-05-16 2004-12-02 Hitachi Ltd Transaction approval and refusal determination system and method therefor
US20050172229A1 (en) * 2004-01-29 2005-08-04 Arcot Systems, Inc. Browser user-interface security application
US20050266798A1 (en) * 2004-05-31 2005-12-01 Seamus Moloney Linking security association to entries in a contact directory of a wireless device
US7519670B2 (en) * 2004-08-12 2009-04-14 International Business Machines Corporation Method for disappearing ink for text messaging

Patent Citations (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5684950A (en) 1996-09-23 1997-11-04 Lockheed Martin Corporation Method and system for authenticating users to multiple computer servers via a single sign-on
US6134658A (en) * 1997-06-09 2000-10-17 Microsoft Corporation Multi-server location-independent authentication certificate management system
US6591291B1 (en) * 1997-08-28 2003-07-08 Lucent Technologies Inc. System and method for providing anonymous remailing and filtering of electronic mail
US6115040A (en) 1997-09-26 2000-09-05 Mci Communications Corporation Graphical user interface for Web enabled applications
US20050210296A1 (en) 1997-09-26 2005-09-22 Mci, Inc. Secure customer interface for Web based data management
US6606708B1 (en) 1997-09-26 2003-08-12 Worldcom, Inc. Secure server architecture for Web based data management
US6182227B1 (en) * 1998-06-22 2001-01-30 International Business Machines Corporation Lightweight authentication system and method for validating a server access request
US6360254B1 (en) * 1998-09-15 2002-03-19 Amazon.Com Holdings, Inc. System and method for providing secure URL-based access to private resources
US6460141B1 (en) * 1998-10-28 2002-10-01 Rsa Security Inc. Security and access management system for web-enabled and non-web-enabled applications and content on a computer network
US6535586B1 (en) * 1998-12-30 2003-03-18 At&T Corp. System for the remote notification and retrieval of electronically stored messages
US6496931B1 (en) * 1998-12-31 2002-12-17 Lucent Technologies Inc. Anonymous web site user information communication method
US6463533B1 (en) * 1999-04-15 2002-10-08 Webtv Networks, Inc. System for generating site-specific user aliases in a computer network
US6725269B1 (en) * 1999-12-02 2004-04-20 International Business Machines Corporation System and method for maintaining multiple identities and reputations for internet interactions
US20020073343A1 (en) 1999-12-14 2002-06-13 Ziskind Benjamin H. Integrated internet messenger system and method
US6895558B1 (en) 2000-02-11 2005-05-17 Microsoft Corporation Multi-access mode electronic personal assistant
US20020087649A1 (en) * 2000-03-16 2002-07-04 Horvitz Eric J. Bounded-deferral policies for reducing the disruptiveness of notifications
US7054906B2 (en) * 2000-12-29 2006-05-30 Levosky Michael P System and method for controlling and organizing Email
US20050188008A1 (en) 2001-02-21 2005-08-25 Boris Weissman System for communicating with servers using message definitions
US20020156905A1 (en) 2001-02-21 2002-10-24 Boris Weissman System for logging on to servers through a portal computer
US7003661B2 (en) 2001-10-12 2006-02-21 Geotrust, Inc. Methods and systems for automated authentication, processing and issuance of digital certificates
US20030126259A1 (en) 2001-12-27 2003-07-03 Fuji Xerox Co., Ltd. Mail server, electronic mail transmission control method for the mail server, and electronic mail system
US20030182383A1 (en) * 2002-02-12 2003-09-25 Xiaopeng He Enterprise electronic mail filtering and notification system
US20030163691A1 (en) * 2002-02-28 2003-08-28 Johnson Ted Christian System and method for authenticating sessions and other transactions
US20040088357A1 (en) * 2002-11-01 2004-05-06 Harding Michael A. Method and apparatus for applying personalized rules to e-mail messages at an e-mail server
US20060048212A1 (en) 2003-07-11 2006-03-02 Nippon Telegraph And Telephone Corporation Authentication system based on address, device thereof, and program
US20050193211A1 (en) 2003-11-12 2005-09-01 Hiroyasu Kurose Management of user authentication information together with authentication level
US20050114453A1 (en) * 2003-11-17 2005-05-26 Hardt Dick C. Pseudonymous email address manager
US20050204011A1 (en) * 2004-03-12 2005-09-15 Hewlett-Packard Development Company, L.P. Dynamic private email aliases
US20050273843A1 (en) 2004-06-02 2005-12-08 Canon Kabushiki Kaisha Encrypted communication method and system
US20060026438A1 (en) * 2004-07-29 2006-02-02 Microsoft Corporation Anonymous aliases for on-line communications
GB2418330A (en) 2004-09-17 2006-03-22 Jeroen Oostendorp E-mail filter with user specific rules for virus, spam and content filtering and pre-filtering operations

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
Adida et al., "Fighting Phishing Attacks: A Lightweight Trust Architecture for Detecting Spoofed Emails" Available at http://theory.Ics.mit.edu/~rivest/AdidaHohenbergerRivest-FightingPhishingAttacks.pdf.
Adida et al., "Fighting Phishing Attacks: A Lightweight Trust Architecture for Detecting Spoofed Emails" Available at http://theory.Ics.mit.edu/˜rivest/AdidaHohenbergerRivest-FightingPhishingAttacks.pdf.
Garfinkel, "Email-based Identification and authentication: an alternative to PKI?" Available at http://ieeexplore.ieee.org/search/srchabstract.jsp? arnumber=1253564&isnumber=28051&punumber=8013&k2dockey=1253564@ieeejrns&query=%28+%28+email-based+identification+and+authentication%3Cin%3Eab+%29+%3Cor%3E+%28+email-based+identification+and+authentication%3Cin%3Eti+%29+%29%3Cor%3E+%28+email-based+identification+and+authentication%3Cin%3E.
Gieben, "Chain of Trust the parent-child and keyholder-keysigner relations and thier communication in DNSSEC" Available at http://www.miek.nl/publications/thesis/CSI-report.pdf.
Tiarnaigh, "Adaptive Moodle" Available at https://www.cs.tcd.ie/courses/csll/tiarnaigh0405.pdf.

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060026438A1 (en) * 2004-07-29 2006-02-02 Microsoft Corporation Anonymous aliases for on-line communications
US20090288153A1 (en) * 2008-05-15 2009-11-19 Canon Kabushiki Kaisha Information processing apparatus and control method
US8528044B2 (en) * 2008-05-15 2013-09-03 Canon Kabushiki Kaisha Information processing apparatus and control method
US9191369B2 (en) 2009-07-17 2015-11-17 Aryaka Networks, Inc. Application acceleration as a service system and method
US9832170B2 (en) 2009-07-17 2017-11-28 Aryaka Networks, Inc. Application acceleration as a service system and method
US9154473B1 (en) * 2011-07-06 2015-10-06 CRRC, Inc. Electronic communications management system and method
US10044735B2 (en) * 2015-04-09 2018-08-07 Secure Information Devices Inc. System and method for authentication of electronic communications

Also Published As

Publication number Publication date
US8533792B2 (en) 2013-09-10
US20070157291A1 (en) 2007-07-05
US20110145907A1 (en) 2011-06-16

Similar Documents

Publication Publication Date Title
US9712497B2 (en) Method and system for creation and verification of anonymous digital credentials
US10003667B2 (en) Profile and consent accrual
US10333941B2 (en) Secure identity federation for non-federated systems
US9692747B2 (en) Authenticating linked accounts
US9832185B2 (en) Request-specific authentication for accessing web service resources
US8955082B2 (en) Authenticating using cloud authentication
US8893293B1 (en) Elevating trust in user identity during RESTful authentication
US8954730B2 (en) Establishing historical usage-based hardware trust
US9838380B2 (en) Visualization of trust in an address bar
US9401918B2 (en) User to user delegation service in a federated identity management environment
US10560454B2 (en) Authentication system and method
Dhamija et al. The seven flaws of identity management: Usability and security challenges
ES2601009T3 (en) Procedures for authorizing access to protected content
US20160065552A1 (en) Method and system for interoperable identity and interoperable credentials
Leiba Oauth web authorization protocol
US8122251B2 (en) Method and apparatus for preventing phishing attacks
US8528066B2 (en) Methods and apparatus for enabling context sharing
US7797413B2 (en) Digital identity registration
KR100856674B1 (en) System and method for authenticating clients in a client-server environment
JP4988701B2 (en) Method, apparatus and computer program for runtime user account creation operation
US8225385B2 (en) Multiple security token transactions
US7747856B2 (en) Session ticket authentication scheme
US9143502B2 (en) Method and system for secure binding register name identifier profile
JP4579546B2 (en) Method and apparatus for handling user identifier in single sign-on service
JP4856755B2 (en) Customizable sign-on service

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CHUA, FEI;REEL/FRAME:017287/0779

Effective date: 20060206

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034543/0001

Effective date: 20141014

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FP Expired due to failure to pay maintenance fee

Effective date: 20190405