US20160065552A1 - Method and system for interoperable identity and interoperable credentials - Google Patents

Abstract

Method, system, and programs for interoperable identity and interoperable credentials. In one example, an authentication request is received. The authentication request originated from an online user in connection with an application having a first LOA. The authentication request includes the online user's input. A digital identity is searched based on the online user's input. A GUID associated with the digital identity is obtained when the digital identity is found. One or more credentials that are bound to the GUID at the first LOA or a higher LOA are provided. A selection of at least one credential is received. Information of the selected credential that includes a credential verification service capable of verifying the selected credential is received. Verification of the selected credential of the online user based on the GUID is requested. A verification response is received. The online user is authenticated at the first LOA when the verification response indicates that the selected credential is successfully verified.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• The present application claims priority to the U.S. Provisional Patent Application No. 62/042,973, filed on Aug. 28, 2014, entitled “METHOD AND SYSTEM FOR INTEROPERABLE IDENTITY AND INTEROPERABLE CREDENTIALS,” which is incorporated herein by reference in its entirety.
BACKGROUND
• 1. Technical Field
• The present teaching relates to methods, systems and programming for identity management. Particularly, the present teaching is directed to methods, systems, and programming for computing measures to be used to provide interoperable identity among various service providers and to provide interoperable credentials.
• 2. Discussion of Technical Background
• In the healthcare environment, online identity solutions that provide secure and interoperable identities are essential. Identity management technology provides management of identities in the digital world. In order to manage the growing number of online identities of a person or an entity, identity federation technology is developed so that different web-sites can reuse a single online identity.
• A federated identity service provider provides user management and authentication services to a plurality of systems of different entities or web-sites, which are also called relying parties. A relying party, typically an application service provider, delegates to the identity service provider to authenticate an end user who is requesting access to the application service provider. As such, the relying party needs to trust the identity service provider to have correctly authenticated the requesting end user's identity.
• An authentication process typically includes the process of verifying a credential the end user presents. In an electronic information system, a digital credential is issued to a legitimate user and will be used subsequently to authenticate the legitimate user. A classic example of a digital credential is a secret password, a passphrase or a pin number. Now, there is an increasing number of uses of other forms of digital credentials, such as, for example, biometrics (finger prints, voice recognition, retinal scans etc.), hard tokens, security devices, public key certificates, etc.
• To objectively assess the quality of an authentication result, NIST document 800-63-1 defines the a number of levels of assurance (LOAs) which describe the degree to which a relying party can be assured that the credential being presented actually represents the entity named in it and that it is the represented entity who is actually interacting with the relying party.
• LOAs are based on two factors: (1) how much can a digital credential be trusted to actually belong to a person. This factor is generally handled by identity proofing; (2) how much the digital credential can be trusted to be a proxy for the entity named in it and not someone else, i.e. identity binding. This factor is directly related to the trustworthiness of the credential technology, the processes by which the digital credential is secured to a token, the trustworthiness of the system that manages the credential and token, and the system available to validate the credential or the token.
SUMMARY
• The teachings disclosed herein relate to methods, systems, and programming for providing identity management and authentication services. More particularly, the present teaching relates to methods, systems, and programming to provide interoperable identity services for various services providers and to enable interoperability of credentials during the authentication process.
• In one example, a method, implemented on at least one computing device having at least one processor, storage, and a communication platform connected to a network for managing identity information of a person is presented. The person's name is received after the identity of the person has been proved at an identity proofing (IDP) level of assurance (LOA). Information related to a credential that is associated with the person is received. The credential can be verified by a credential verification service at a LOA that is of the same or lower level than the IDP LOA. A chosen name of the person is obtained. A combination of the person's name and the chosen name uniquely identifies the person. A digital identity is created based, at least in part, on the person's name and the chosen name. A globally unique identifier (GUID) is generated. The GUID associates with the digital identity and binds to the person. The GUID is bound with the credential. A record of the person that includes at least the IDP LOA and information related to the credential and the credential verification service is stored. Information is transmitted to the credential verification service that the person is to be authenticated via the GUID based on a real-time user input associated with the credential.
• In another example, a method, implemented on at least one computing device having at least one processor, storage, and a communication platform connected to a network for authenticating an online user is presented. An authentication request is received. The authentication request originated from the online user in connection with an application having a first level of assurance (LOA). The authentication request includes the online user's input. A digital identity is searched based on the online user's input. A globally unique identifier (GUID) associated with the digital identity is obtained when the digital identity is found. One or more credentials that are bound to the GUID at the first LOA or a higher LOA are provided. A selection of at least one credential from the one or more credentials is received. Information of the selected at least one credential that includes a credential verification service capable of verifying the selected at least one credential is received. Verification of the selected at least one credential of the online user based on the GUID is requested. A verification response is received. The online user is authenticated at the first LOA when the verification response indicates that the selected at least one credential is successfully verified.
• In still another example, a method, implemented on at least one computing device having at least one processor, storage, and a communication platform connected to a network for authenticating an online user is presented. One or more credentials associated with a globally unique identifier (GUID) corresponding to a person are stored. The GUID and a first level of assurance (LOA) associated with an application are received. At least one of the one or more credentials is determined. Each of the determined at least one credential is at the first LOA or a higher LOA. The determined at least one credential is provided so that the online user who claims to be the person can be authenticated based on a credential selected from the at least one credential.
• Other concepts relate to software for interoperable identities and interoperable credentials. A software product, in accord with this concept, includes at least one non-transitory machine-readable medium and information carried by the medium. The information carried by the medium may be executable program code data regarding parameters in association with a request or operational parameters, such as information related to a user, a request, or a social group, etc.
• In one example, a non-transitory machine readable medium having information recorded thereon for managing identity information of a person is presented. The recorded information, when read by the machine, causes the machine to perform a series of processes. The person's name is received after the identity of the person has been proved at an identity proofing (IDP) level of assurance (LOA). Information related to a credential that is associated with the person is received. The credential can be verified by a credential verification service at a LOA that is of the same or lower level than the IDP LOA. A chosen name of the person is obtained. A combination of the person's name and the chosen name uniquely identifies the person. A digital identity is created based, at least in part, on the person's name and the chosen name. A globally unique identifier (GUID) is generated. The GUID associates with the digital identity and binds to the person. The GUID is bound with the credential. A record of the person that includes at least the IDP LOA and information related to the credential and the credential verification service is stored. Information is transmitted to the credential verification service that the person is to be authenticated via the GUID based on a real-time user input associated with the credential.
• In another example, a non-transitory machine readable medium having information recorded thereon for authenticating an online user is presented. The recorded information, when read by the machine, causes the machine to perform a series of processes. An authentication request is received. The authentication request originated from the online user in connection with an application having a first level of assurance (LOA). The authentication request includes the online user's input. A digital identity is searched based on the online user's input. A globally unique identifier (GUID) associated with the digital identity is obtained when the digital identity is found. One or more credentials that are bound to the GUID at the first LOA or a higher LOA are provided. A selection of at least one credential from the one or more credentials is received. Information of the selected at least one credential that includes a credential verification service capable of verifying the selected at least one credential is received. Verification of the selected at least one credential of the online user based on the GUID is requested. A verification response is received. The online user is authenticated at the first LOA when the verification response indicates that the selected at least one credential is successfully verified.
• In still another example, a non-transitory machine readable medium having information recorded thereon for authenticating an online user is presented. The recorded information, when read by the machine, causes the machine to perform a series of processes. One or more credentials associated with a globally unique identifier (GUID) corresponding to a person are stored. The GUID and a first level of assurance (LOA) associated with an application are received. At least one of the one or more credentials is determined. Each of the determined at least one credential is at the first LOA or a higher LOA. The determined at least one credential is provided so that the online user who claims to be the person can be authenticated based on a credential selected from the at least one credential.
BRIEF DESCRIPTION OF THE DRAWINGS
• The methods, systems and/or programming described herein are further described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:
• FIG. 1 is a high level depiction of an exemplary system configuration of the present teaching, according to an embodiment of the present teaching;
• FIG.2-ashows an exemplary user interface for a LOA2 application in which an end user may login via a LOA2 credential through OneStop identity center, according to an embodiment of the present teaching;
• FIG.2-bshows an exemplary user interface for a LOA3 application in which an end user may login via a LOA3 credential through OneStop identity center, according to an embodiment of the present teaching;
• FIG. 3 is a flowchart of an exemplary process in which OneStop identity center authenticates a user at a requested LOA, according to an embodiment of the present teaching;
• FIG. 4 shows an exemplary system diagrams of OneStop identity center, according to an embodiment of the present teaching;
• FIG. 5 shows a flowchart of an exemplary process in which OneStop identity center authenticates the user at a particular LOA with reusable credentials, according to an embodiment of the present teaching;
• FIG.6-ashows a conceptual view of an exemplary role of OneStop identity center in managing a person's various online identities, according to an embodiment of the present teaching;
• FIG.6-bshows portions of data used in an exemplary attribute management feature of OneStop identity center, according to an embodiment of the present teaching;
• FIG.6-cshows exemplary system diagrams of OneStop identity center that includes the attribute sharing feature, according to an embodiment of the present teaching;
• FIG.6-dshows an exemplary user interface of OneStop identity center where the user manages attribute sharing among various trusted applications, according to an embodiment of the present teaching;
• FIG. 7 shows exemplary user interface for an authenticated user of a trusted application to register with OneStop identity center, according to an embodiment of the present teaching;
• FIG. 8 shows a flowchart of an exemplary process in which an authenticated user of a trusted application shares the user's identity attributes in the trusted application with OneStop identity center in order to register with OneStop identity center and become a OneStop user identity center, according to an embodiment of the present teaching
• FIG. 9 shows a flowchart of an exemplary process in which an OneStop identity center user get registered to a new trusted application, according to an embodiment of the present teaching;
• FIG. 10 depicts a general mobile device architecture on which the present teaching can be implemented; and
• FIG. 11 depicts a general computer architecture on which the present teaching can be implemented.
DETAILED DESCRIPTION
• In the following detailed description, numerous specific details are set forth by way of examples in order to provide a thorough understanding of the relevant teachings. However, it should be apparent to those skilled in the art that the present teachings may be practiced without such details. In other instances, well known methods, procedures, systems, components, and/or circuitry have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.
• The present disclosure describes method, system, and programming aspects of methods and systems for providing a centralized identity management and authentication services to a plurality of trusted applications or service providers. The objectives of the present teaching include, for example, providing centralized management of identity information in a trusted frame work, using a portable, easy to use chosen name to create a unique identifier to universally identify a person, enabling interoperable credentials and allowing individuals to reuse already obtained credentials, protecting the privacy of personal information (identity attributes and other identity information) by separating it from the authentication process. For example, using anonymous digital credentials that do not contain personal information such as the person's name, birth place, birth date, or biometric information such as a picture or a finger print.
• Moreover, the method and system disclosed in the present teaching can protect the privacy of personal information by providing a multi-stage look up mechanism, so that there is no direct access to a person's identity information without successful authentication. The binding of the identity and the digital credential provides additional protection to the identity information.
• A credential manifests a person's relationship to an entity. Even though the relationship is established first by verification of identity information—the identity proofing process. The established relationship is embodied in an anonymous digital credential that no longer includes identity information. As a result, authentication of an identity no longer requires identity information. Rather, authentication becomes a separate process to verify an anonymous digital credential. Further, the frequency of the authentication process does not compromise privacy.
• NIST document 800-63-1 defines four levels of assurances (LOAs), as well as the protocols for and practices used for each level. In the present teaching, the identity service provider is designed to comply with these protocols and practices in its use of LOAs both in the process of identity proofing, credential management and end user authentication.
• The identity provider may be validated by a third party. The identity provider may also belong to a trusted frame work that serves a community of relying parties. In the present teaching, an identity service request to the identity service provider includes both an identity assertion and the level of assurance for the identity assertion. For example, as seen below, US federal government may establish a trust framework to ensure secure transactions between a citizen and business online services.
• 1. Centralized Identity Management
• An identity is a set of attributes related to an entity. The identity of a human entity, such as a person, is recognized by one or many attributes of the person, such as, for example, attributes that the person have provided to various social entities, where by the social entities may have, for example, recorded the person's attributes in their information systems.
• In one example, a person's identity may include physical attributes such as height, weight, hair color, eye color, etc. These attributes may be used for a driver license issuing authority. These attributes may be accessible through an application or web site of the driver license issuing authority.
• In another example, the person's identity may include attributes such as date of birth, gender, and place of birth. These attributes may, for example, be recorded at the person's birth certificate and accessible by a computerized system or web site of the person's birth certificate issuing authority. These attributes may be referenced, for example, by US Department of the State's information system when the person uses these attributes to apply for a US passport.
• With time, the person's identity grows since the person interacts with more and more social entities through life and as a result acquires more and more identity attributes with respect to each of the social entities. With the prevalence of information technology, frequently, the social entities maintain the person's identity attributes and make them accessible through a computerized system or web site. For example, the person enters the education system and may acquire attributes such as a student id from the college he is attending. The person may also acquire a student email account. Both the student id and the student email account attributes are accessible through an application or web site of the person's college information system.
• Similarly, when the person is employed, the person may acquire an employee id attribute from the person's employer whereby the person would be recognized by in the person's employer information system. In still another example, the person may acquire attributes in his professional fields and being recognized by specific professional organizations: a doctor may have a National Provider Identifier (NPI number) attribute as issued by the Centers for Medicare and Medicaid Services (CMS); a lawyer may acquire an attribute of a state bar license number for the state that he is licensed to practices law.
• In another example, the person may interact with entities in the financial industry, such as banks, credit card companies, mortgage companies. The person acquires additional attributes such as bank account numbers, credit card numbers, and mortgage account numbers within these entities.
• Similarly, when the person interacts with service providers such as a phone service provider, the person may acquire a mobile phone number, or a land phone number attribute. When the person subscribes to cable service, internet service, water, gas, electricity service, newspaper service, the person may also have acquired attributes such as an account number from each of these services.
• Moreover, when the person interacts with various online service providers; social media service providers, online shopping service providers, communication service providers, data storage service providers, and digital entertainment service providers, etc. The person may acquire attributes such as, for example, a number of email accounts, twitter accounts, a Facebook accounts, an aliased account on an online chat forum, etc.
• In still another example, the person may interact with entities in the health care industry, and acquires attributes from the interacting healthcare entities. For example, the person may acquire a patient ID x from hospital A's system when, for example, the person went to hospital A's emergency care facility after an accidental fall from the stairs. The person may acquire a different patient ID y from hospital B's system when the person went to hospital B for cardiovascular care.
• In summary, a person's identity, i.e., the various attributes that relate to the person are fragmented and distributed in a vast number of computer systems of different social entities and services providers.
• Problems exist for such distributed identity configuration. For example, some of these attributes are common among many entities; as a result these attributes are duplicated in multiple copies in multiple entities. For example, the “current address” attribute may be exist in many entities, such as, for example, the person's bank, the person's credit card company, the person's account in Amazon.com, the person's employer, the person's primary care doctor's practice, the person's record with the DMV, the person's record with the state bar association, etc.
• The repetitive nature of these attributes creates two problems. First, it is burdensome for a person to repeatedly provide this information to every entity that requires it. Second, it becomes burdensome for the person to update changes to such attributes, and manually update every copy of the same attributes. For example, when the person moves to a new address, the new “current address” attribute need to be updated to all the entities, such as the entities listed above.
• The present teaching provides a solution to the above problems. The present teaching enables the person to have centralized control over the person's identity attributes and their uses in various entities as it provides secure exchange of identity information among a wide group of identities while reducing risk. For example, the present teaching enables identity attributes be distributed to or shared among trusted entities so as to reduce duplicate copies of the same attributes in different entities. Having centralized control over decentralized data storage provides efficiency without sacrificing data privacy.
• 2. Universal Identifier
• As seen in the examples above, the person's identity is distributed in multiple entities, with each entity maintaining a subset of the person's identity attributes, as well as some other information with respect to the person. For example, the college the person attended may maintain the person's identity attributes, such as student ID, student email account, The University may also keep other information about the person, such as, for example, the person's enrolling period, degree earned, date of the degree earned, permanent address of record, etc. These other attributes may also be used to identify a student if the student id is being reused, for example, after 20 years.
• In another example, at birth, the person builds a connection to his birth country's government by establishing a “legal name” identifier to the government, for example, by applying for a birth certificate to prove this connection. The government may also record the other attributes, such as the person's gender, date of birth, place of birth, parents' names, etc. When two person have the same legal name, the person's other attributes may be used to distinguish them.
• Within the universe of each entity, the person may be associated with an identifier that uniquely identifies the person within that particular entity. For example, a social security number can be an identifier to uniquely identifies the person for the US federal government; a driver license number can be an identifier to uniquely identity the person in the person's residential state; a student id can be an identifier to uniquely identify the person in the person's university; a bank account number.
• In still another example, a lawyer's state bar license number is a unique identifier to identity the lawyer in that state bar association. In still another example, a doctor's National Provider Number (NPI number) is a unique identifier to identify the doctor in the healthcare system.
• These identifier attributes are important personal identification numbers. However, these numbers are randomly generated before being assigned to a person, and thus, are not easy to remember. These numbers may be presented in the form of ID cards, such as a social security cards, driver license, bar license cards, etc. However, managing these extra ID cards or id numbers can be burdensome. It also causes security problems when such ID cards are lost or stolen.
• The present teaching teaches a method for creating a consistent identifier that can be used universally across all trusted entities, thus reducing the need to manage multiple identifiers. More specifically, the present teaching provides a Chosen Name identifier, a name that the person choses for himself/herself, a name that the person prefer to be called despite his real name.
• The present teaching also enables secure exchange of user identity information between OneStop and the trusted entities under the user's consent. A trusted entity may require a specific set of identity attributes to map an OneStop identity to a user account of the trusted entity. For example, a personal healthcare record system (PHI) requires 5 identity attributes to find a user's account: first name, last name, date of birth, gender and zip code. Upon user's consent as presented, for example, through an OneStop user interface, OneStop may share these 5 attributes of the user with the PHI system, for example, in an OpenID Connect ID token, along with the user's GUID in the OneStop system.
• On the other hand, a user may apply for an OneStop account via a trusted application. In other words, the trusted application may act as an identity proofing agent for OneStop.
• For example, the person may consent to the PHI system to provide the 5 identity attributes, such as first name, last name, date of birth, gender and zip code to OneStop, PHI system may also provide the LOA based on its record of the user's identity proofing in the PHI system. In one embodiment of the present teaching, using the OpenID Connect protocol (http://openid.net/connect/faq/), PHI system may serve as UserInfo endpoint for OneStop, so that OneStop may obtain the 5 needed attributes and the LOA level securely from the PHI system. The OpenID Connect protocol include ID token, which include information about the authenticated user. The UserInfo endpoint in the OpenID Connect protocol gets attributes about the user and translates the ID tokens.
• 3. Chosen Name: A Universal Personal Identifier
• The present teaching may use a globally unique personal identifier for every user of the OneStop identity center.
• The identifier includes a person's first name, last name, a “&”, and the person's chosen name. For example, Mr. James Chen decides that he would like “Tiger” to be his chosen name; his identifier in OneStop would be “James Chen & Tiger.” In another example, suppose the fictitious figure, Mr. James Bond decides that he would like be called “007”, and use it as his chosen name, his identifier in OneStop would be “James Bond & 007.”
• 
• A person's full name is the person's most significant social identifier, which includes at least a first name and a last name. However, traditionally neither the first name nor the last name is of the person's own choice: the first name is chosen, normally, by the person's parents; the last name is given, normally, by the person's family, either through birth or by marriage.
• A chosen name is a name that the person prefers to be called despite his real name. The underlying philosophy of the chosen name is to provide a person with an opportunity to choose a name for himself/herself, a name that he can expresses himself as who he is, to reflect his preference and follow his own desire as how he/she should be recognized. Because the chosen name is centered on the person's own belief and created with his own unique expression as to his/her identity. As such, the chosen name would be easy to remember and promotes user's frequent use.
• Due to the human factors of the chosen name design as discussed above, it is the vision of the present teaching to have chosen name build its weight with time, through frequent, consistent use, gaining universal acceptance in all aspects of the person's online interactions, and thus becoming a part of the person's permanent identity.
• As part of an online identity identifier, a chosen name may be implemented using as a string. The string includes a sequence of characters, and has an arbitrary but finite length. In one embodiment of the present teaching, the characters may include all alphabetic letters. In one embodiment of the present teaching, the characters may include all characters in the Chinese language. Similarly, in other embodiments of the present teaching, the set of valid characters may include all characters in the Japanese language, or Russian language, or Arabic language, or any other written language
• In another embodiment of the present teaching, the characters may include all Arabic numerals. In another embodiment of the present teaching, the characters may include both alphabetic letters and Arabic numerals numbers.
• To ensure the uniqueness of each globally universal identifier, and tolerate user input errors, the present teaching may use a thread hold value between the distances between any two global identifier strings. For example, the distance between an identifier “Jim Chen & Tiger” and “James Chen & Tiger” may be too short to distinguish each other. Common typos, such as skipping a letter, reverse letters, double letters, may also create a string that has too a short distance to the correct spelling of the intended identifier.
• In one embodiment of the present teaching, the Jaro-Winkler distance, measures the distance. The higher the Jaro-Winkler distance for two strings is, the more similar the strings are. The Jaro-Winkler distance metric is designed and best suited for short strings such as person names. The score is normalized such that 0 equates to no similarity and 1 is an exact match.
• In another embodiment of the present teaching, the distance is measured by the Levenshtein distance. The Levenshtein distance between two strings is defined as the minimum number of edits needed to transform one string into the other, with the allowable edit operations being insertion, deletion, or substitution of a single character. Other embodiments may apply different string distance algorithms, including but not limited to Euclidean Distance, Cosine/Sine similarity distance, Chapman Length, Soudex, Linear and no-linear clustering, as well as string distance algorithms that are tailored to a particular language.
• In still another embodiment, the distance is created by a machine learning algorithm, where user input errors are captured and such errors are used as feedback to correct the outcome of the distance algorithm.
• 4. Multi-Credential Authentication
• In the present teaching, one purpose of a digital credential is to prove to a digital system that the presenter of the digital credential is the very person/identity that is associated with the digital credential. In other words, a digital credential serves as a proxy of the identity/person to the digital system. The process to authenticate an identity/person to a digital system becomes the verification of the proxy, i.e., the digital credential. As such, an identity can be asserted digitally via verification of the digital credential,
• Examples of a digital credential may include something that the person can remember, such as a password. A digital credential may also include something that the person carries, such as his mobile phone, a smart card, a hard token or a USB device. A digital credential may also include something that the person is, such as, for example, a person's biometrics: voice, finger prints, iris scans, etc.
• A person may have established a number of digital credentials during the person's interactions to various entities. For example, the person may have obtained a smart card from the person's employer, the person may obtained a Symantec hard token as a doctor to electronically prescribe controlled substances to patients, the person may acquire a RSA security token from the hospital system that the person works for.
• Using a digital credential makes it easy to use and secure. Because the credential is secured to a token, the trustworthiness of the system that manages the credential and token, and the system available to validate the credential.
• Digital credentials are issued to a person and become attached to the person. Presenting the correct digital credential as linked to the identifier enables the information system to trust the current user being the legitimate user. In other words, an identity can be asserted by authentication of the digital credential.
• In the present teaching, authentication may be a process to electronically verify an assigned credential of an identity as means to accept an identity assertion of that identity.
• For the same security reasons, the person may have gone through a through identity proof process before being issued the digital credential. The person is further burdened to manage an increasing number of such security devices, each for a particular entity, even though they serve the same purpose.
• The present teaching allows reuse of the collection of the existing credentials the person has acquired from various entities. The present teaching also manages security and trust among these established credentials so that they can be used in other entities, based on standards as set forth in NIST document 800-63-1. The present teaching further enables compound credentials, where more than one credentials are used together for increased security. The present teaching provides security because it does not expose links or look up mechanism for identity attributes.
• Motivated by this challenge, the teachings presented herein provide a system or service that utilizes improved approaches to a centralized identity management system which manages the identity attributes that are collected from various source entities.
• FIG. 1 is a high level depiction of system configuration in which a centralized identity management system manages the identities and end user authentications for a number of trusted entities, according to an embodiment of the present teaching. To provide a context, an example of the use of the system is described below. Theend user110 may desire to access a trustedapplication130 to obtain contents or services as provided by application service providers for the trustedapplication130.
• In accordance with the present teaching, the OneStopidentity service provider140 performs a3 step process: (1) identity searching; (2) credential selection; and (3) credential verification. In step (1) Identity searching: theidentity center142 may first search for the identity with identifiers provided by the end user. Theidentity center142 then determines whether theend user110 has sufficient level of assurance (LOA) with its identity proofing record, as indicated in theidentity database144. Theidentity center142 may provide additional identity proofing to theend user110 if needed to reach the desired LOA.
• In step (2) credential selection: theidentity center142 may search for the credentials options of theend user110 via communicating with acredential exchange146. Thecredential exchange146 may generate available credential options that are at or above the desired LOAs by looking up in thecredential database146. Thecredential database146 includes credential information that theend user110 may have.
• In response, theend user110 may select one particular credential to authenticate him/her. In step (3) credential verification: based on the selected credential, thecredential exchange146 selects the correspondingcredential service agent150 to verify the selected credential by interacting theend user110. Finally, upon successful verification of a valid credential, theidentity center142 provides a timed digital identity token to the requesting trustedapplication130 for theend user110.
• InFIG. 1, theexemplary system100 includes anend user110, anetwork120, a number of trustedapplications130, includingapplication1130-a,application2130-b, . . . application n130-c, anidentity center142, anidentity database144, acredential exchange146, acredentials database146, a number ofcredential service agents150, including Authentify xFA150-a, Symantec150-b, RSA150-c, Federal PKI Bridge (for PIV card), Verizon, and other credential service agent150-d.
• Thenetwork120 can be a single network or a combination of different networks. For example, a network can be a local area network (LAN), a wide area network (WAN), a public network, a private network, a proprietary network, a Public Telephone Switched Network (PSTN), the Internet, a wireless network, a virtual network, or any combination thereof. A network may also include various network access points, e.g., wired or wireless access points such as base stations or Internet exchange points, through which a data source may connect to the network in order to transmit information via the network.
• Theend user110 may connect to the network via desktop connections (110-a), or connect to the network via wireless connections such as through a laptop (110-b), or a handheld device (110-c). Theend user110 may have number of authentication tokens for the specific purpose of authenticating himself/herself to access online applications or perform electronic transactions. Theend user110 may carry a hard token112-b, such as, for example a Symantec hard token that generates codes those changes with time. Thenend user110 may also have a USB token112-a, such as, for example a RSA Secure ID token. Theend user110 may also have a smart card112-c, such as, for example, an identification card issued by the end user's employer.
• The trustedapplication130 includes a number of trusted applications in a trust framework. The trust framework may be established by contracts among all member entities for each of themember applications130, and the OneStopidentity Service provider140. The trust framework may also be established via certain certification program, where each member entity or each member applications are certified to be in compliance with a common security protocol. For example, for health information exchange purposes, member entities and applications may follow the LOA practices as defined in the NIST document 800-63-1. In another example, a trust framework may be established by the federal government, such as, U.S. Federal Identity, Credential, and Access Management (FICAM) Trust Framework Solutions (TFS) program (http://info.idmanagement.gov/2013/11/ficam-trust-framework-solutions-tfs.html).
• The trustedapplication130 may include different applications within one organization. For example, a doctor may access an electronic prescription application, a medical history application, and a HIPAA compliant secure email application, all within one hospital system where the doctor practices. The trustedapplication130 many also include applications from different organizations. For example, a doctor may access an electronic prescription application from an application provided by a clinical network, the doctor may access a medical history application from an application provided by a health information exchange (HIE) network, and the doctor may access a HIPPA complaint secure email application hosted by a communications service provider.
• In another example, apatient end user110 may access a first application fromhospital1 to access his recent in-patient record. The patient may access a second application inhospital2 to access his record for an emergency care. The patient may access an application inlab3 to access his recent X-ray. The patient may access a fourth application from his/her insurance company for a medical claim.
• Traditionally, a trustedapplication130 handles its own identity proofing process. For example, upon the end user's initial registration to the trustedapplication130, anend user110 may be required to input, such as via entering into a form, his name, address, email address, phone number and other relevant information about the user. Upon receipt of the user information and verifying it successfully, (i.e., identity proofing of the end user110), theapplication130 may enable theend user110 to create an account. The user account may be accessed by an identifier (e.g., a user name) and a digital credential (e.g., a password).
• To access a trustedapplication130, anend user110 may need to register with theapplication130. The registration process may require theend user110 to provide sufficient information about theend user110, for purpose of, for example, identity proofing theend user110 at the desired LOA level of theapplication130, as defined in the standards as set forth, for example, in NIST document 800-63-1. In one example, theapplication130 may be a free newsletter application that delivers to the user news on selected topics. The newsletter application may require a LOA1 level of identity proofing, where theend user110 only need to provide a unique identifier and a personal email address.
• In another example, theapplication130 provides online shopping services, and requires a LOA2 level of identity proofing. In this online shopping application, theend user110 may need to additionally provide his bank account information, or his credit card information, for example, via the registration interface of the online shopping application. Theend user110's user account will be created only after theapplication130, here the online shopping application, has verified and proved accurate of the person's bank account or the credit card account information. In another example, theapplication130 is an application for accessing to a restricted system that is subject to is subject to regulatory requirements (e.g. HIPAA, DEA rules, etc.).
• For example, theapplication130 may be an electronic prescription application for doctors to prescribe controlled substances (EPCS application), where the end user110 (e.g., a doctor) is required to pass at least a LOA3 of identity proofing before enabled to create account in the EPCS application. In one implementation of the EPCS application, theend user110 is required to pass a vigorous identity proofing process through the hospital system, where theend user110/doctor is required to be present in person, to the registration staff of the hospital, showing two forms of government issued picture ID which shows the doctors legal name, nationality, address and date of birth. In another example of an EPCS application, theend user110/doctor is required to respond to a letter that is mailed to him/her at his/her primary address. In still another example, theend user110/doctor is required to answer, via a landline telephone from his home, various questions to prove his/her identity.
• In still another example, theapplication130 is a credential issuing application where a user is issued a credential based on sufficient identity proofing at a particular LOA level. For example, theapplication130 may be a Symantec application, where the user is issued a hard token upon successful identity proofing, for example, at LOA2. Theapplication130 may be a RSA application, where a user is issued RSA security token upon successful identity proofing, for example, at LOA2.
• In still another example, theapplication130 includes an OneStop application where anend user110 may go through the identity proofing process through the identity proofing process of theOneStop identity center142 and being issued a credential by theOneStop identity center142.
• OneStopidentity service provider140 is an identity management system that provides identity services for the trustedapplications130. OneStopidentity service provider140 includes anidentity center142 and anidentity database144. In some embodiments, the OneStopidentity service provider140 may also include thecredential exchange146 and thecredentials database148.
• In one embodiment of the present teaching, the OneStopidentity service provider140 may engage identity proof agent, such as, for example, Google, PayPal, Equifax, Facebook, Twitter, LinkedIn, Microsoft to conduct the identity proofing process.
• In another embodiment of the present teaching, the OneStop identity service provider may contact with other identity providers, such as, for example, to initially create OneStop users based on records from the US department of State, Department of Homeland Security, Veterans Administration Office of Personnel Management, CAQH, MyGov (General Service Administration), various State Department of Motor Vehicles, or Notary Services.
• Theidentity database144 includes identity information for each OneStop user, including various identity attributes, identity proofing record, and identity binding records.
• In one embodiment of the present teaching, theidentity database144 includes the OneStop Chosen Name Identifier, an internal Global Unique ID (GUID)—a unique code used internally that corresponds to the OneStop Identifier. The identity database may also include the user's identity proofing record and its LOAs. The user's identity proofing record indicates how, when, where, by whom the OneStop user was being identity proofed. For example, an OneStop user, as identified by Ryan Williams & Drew, was identity proofed by the OneStop system, by Experian, on November 2012. He has reached a LOA2. In another example, a second user, as identified by Ellen Smith & Willow, was identity proofed by the EPCS application, on May 2011, certified at LOA3.
• In one embodiment of the present teaching, theidentity database144 may also include information about the credentials that bound to the OneStop user. For example, the user Ellen Smith & Willow, who is a registered user of the EPCS application (a trusted application), having an identity proofing record of LOA3, who is also bound to a Symantec hard token as issued from the EPCS application, which ensures LOA3 authentication. The Symantec hard token is a digital credential that may be uniquely identified by, for example, a serial number of the hard token. In this example, the serial number will also be included in theidentity database144, for example, as a credential attribute as associated with the OneStop user Ellen Smith & Willow. Additionally, the credential attribute may also include other information about the credential, for example, the LOA3 assurance level, the URI for verify this credential, and other information needed to initiate the authentication service of this credential.
• The identity database may include the serial number of the Symantec hard token, as well as its LOA3 credential strength in Ellen's record in theidentity database144.
• In another embodiment of the present teaching, thecredentials database148 includes information about the credentials that are bound to the OneStop user. In this embodiment, the identity binding (association between an identity and one or more credentials) is separate from the identity proofing records.
• In accordance with the embodiments described herein, the trustedapplication130 can redirect to OneStopidentity service provider140 to authenticate theend user110 with its required overall LOAs.
• Overall LOAs of the identity service, as defined by the NIST document 800-63-1, is determined by the LOAs in 3 aspects: identity proofing, credential strength, and authentication process. The overall LOA is the least LOAs achieved by the three. For example, to reach an overall LOA3, the identity service need to have LOA3 or above in identity proofing, using credentials with strength of LOA3 or above, and applying authentication process with LOA3 or above (which requires at least two factor authentication).
• Credential service agents150 refer to a plurality of service providers operable to, for example, issue credentials and provide credential services (e.g. verification of the credentials). For example, thecredential service agents150 may include an Authentifiy xFA150-a, a service provider which provides two factor authentication based on a user's voice. In another example, the authentication service may be provided by Symantec150-bwhere a hard token credential can be authenticated. In another example, theidentity center142 may request RSA Auth Manager150-cto authenticate a hard token from RSA. Similarly, theidentity center142 may request other credential service provider150-dto authenticate another particular type of credential.
• FIG.2-ashows exemplary user interface for a LOA2 application in which an end user may login via a LOA2 credential through OneStop, according to an embodiment of the present teaching. In this example, an exemplary subject application (ABC Healthcare Application) requires LOA2 assurance level for its authentication process. An existing user of the ABC application may login normally through its conventional user interface, such as, for example, theuser interface210. In other examples of the present teaching, theuser interface210 may include any other login or authentication interfaces that the subject application provides.
• In this example as shown in theuser interface210 of FIG.2-a, the user is required enter his/her User Name, which is specific to the ABC application. The user is also required to enter a correct password that was specifically set up for the ABC application. With the growing numbers of web sites/applications that the user accesses, so do the number of authentication details, such as, username/password pairs, that the user is required to remember, or to manage. This can be quite burdensome.
• As a convenient alternative, the user may login to a subject application with a consistent way through OneStop. In one example, the subject application, such as, for example, the ABC application, provides auser interface220 where the user may, for example, be authenticated using the OneStop service. In contrast to using a particular user name that is specific to the subject application, the user may use an unvarying, universal name through OneStop (a Globally Unique OneStop Name, GUON), no matter what subject application is.
• The user's universal name, GUON, includes the user's first name, last name and chosen name. As discussed earlier, OneStop ensures that the user's universal name (GUON) is the user's true names that have been sufficiently verified and identity proofed, at least, at the required LOA level. In this example, theuser interface220 provides user inputfield First Name232, Last Name234, andChosen Name236 for user to input its first name, last name and chosen name respectively. In another embodiment, theuser interface220 may include one text field which accepts the complete string of user's universal name GUON. In still another embodiment, theuser interface220 may provide masked characters feature for inputting the user universal name text field.
• Further, in contrast to using a conventional password, or a particular credential that is tired to the subject application, the user may authenticate himself/herself with any qualifying credential (a credential that is at the desired LOA level or above). For example, theuser interface220 includes acredential list242. Thecredential list242 may include, for example, a list of credentials at the LOA2 or above that OneStop currently is operable to handle. In another embodiment of the present teaching, the credential list includes a list of credentials that are tailored to the current user and include credentials that the current user has acquired. In this embodiment, thecredential list242 may be presented to the user after the user has correctly entered its GUON via to theuser interface220.
• In the example as shown in FIG.2-a, thecredential list242 may include, for example, a Symantec credential242-a, such as a hard token that display a changing pass code. The Symantec credential242-amay, for example, have been issued by the OneStop, can be used for authentication at LOA3. Thecredential list242 may also include an xFA credential242-bwith authentication valued at LOA3. In this example, the user may, for example, have registered with the xFA credential service provider, installed an xFA mobile application on the user's smart phone, and thus enabled to be authenticated by the xFA credential provider based on the user's voice print.
• Thecredential list242 may include for example, an Ezio Secure Card242-cthat the user may have acquired, for example, from Amazon.com. The Ezio Secure Card242-calso provides a changing pass code in its user interface, and may have been issued, for example, at LOA2. Thecredential list242 may include a credential242-d, for example at LOA2, where the user can be verified by a code in a text message that will be sent from PayPal to the user's mobile phone (also called PayPal mobile phone security key).
• Thecredential list242 may also include a RSA secure ID242-ethat is issued from Superscript, with LOA3. The RSA secure ID242-emay be, for example, a hardware device that displays a changing pass code that user is required to present during the RSA secure ID verification process. Thecredential list242 may also include a credential242-fthat the user has acquired for two factor authentication with Microsoft. The credential242-fmay be, for example, qualified at LOA2 and allows Microsoft to send the user a code in an email, where user logs into the account for the first time on a PC or other device.
• Theuser interface220 may also include acomponent244. Thecomponent244 may be a button, or a link, or equivalent. Activation of thecomponent244 may, for example, initiate a process where the current user may add additional new credentials to the OneStop service provider.
• FIG.2-bshows exemplary user interface for a LOA3 application in which an end user may login via a LOA3 credential through OneStop, according to an embodiment of the present teaching. Similar to FIG.2-a, the present teaching enables user to authenticate through a universal LOA3 authentication process through OneStop. Again, the user uses the user's Globally Unique OneStop Name (GUON) regardless what subject application the user is trying to access. Additionally, the user may authenticate himself/herself with any qualifying credential (a credential that is at the desired LOA3 level or above) that the user may have acquired.
• In the example as shown in FIG.2-b, auser interface230 includes acredential list252 at LOA3 that includes for example, a Symantec hard token252-a, as acquired via OneStop, a XFA credential252-b, and a RSA Secure ID252-c, as acquired via SureScript.
• Theuser interface230 may also include, for example, thecomponent244 where the user may provide additional credentials at LOA3 or above to the OneStop system.
• FIG. 3 is a flowchart of an exemplary process in which OneStop authenticate a user at a requested LOA, according to an embodiment of the present teaching. Atstep310, OneStop receives an identity assertion and required LOA from a trusted application. The identity assertion may include, for example, the user's GUON, a string that includes user's first name, last name, “&” and chosen name. Atstep320, OneStop searches in theidentity database144, for an OneStop identifier that matches with the received GUON. Atstep330, if an identity record is found in theidentity database144, for example, with a matching GUON, OneStop continues to check the identity proofing record for the found identity.
• Suppose, the found identity does not have a sufficient level of LOA as indicated in its identity proofing records, OneStop may, for example, redirect the user to start the process for additional identity proofing atstep340. In one example, the user is directed to an Experian website, where additional identity proofing may be performed by requiring the user to answer a number of questions that are generated based on the user's financial record with Experian.
• Upon successful completion of the additional identity proofing atstep350, OneStop may, for example, update the identity's identity proofing record, for example, with an elevated LOA, and/or with any other additional identity proofing details atstep360. If the user fails at additional identity proofing atstep350, OneStop may, for example, deny the user's identify assertion atstep395, for example, by responding with an authentication failure code to the requesting application.
• If the found identity has an identity proofing record that indicates that the IDP level is, for example, at the requested LOA or above, atstep330, OneStop may continue to find qualifying credentials that are bound to this identity at step370. In one embodiment of the present teaching, the qualifying credentials for the identity are stored in theidentity database144, as shown inFIG. 1. In another embodiment of the present teaching, as discussed in more detail below inFIG. 4, the qualifying credentials that are bound to the identity is stored by aseparate credential database148 and managed by thecredential exchange146.
• In one embodiment of the present teaching, the user may select a particular credential to authenticate the user. In another embodiment of the present teaching, OneStop selects a “master” credential at the requested LOA. In another embodiment of the present teaching, OneStop enables the user to select from a list of available credentials.
• In one embodiment of the present teaching, OneStop may initiate the process to verify the selected credential at380. For example, OneStop may redirect the user to the credential verification service provider as related to the selected credential.
• If the selected credential is verified successfully atstep390, OneStop may, for example, provide a positive authentication response with respect to the user to the trusted application atstep399. In one embodiment of the present teaching, OneStop adopts the OpenID Connect protocol, and provide an ID token for the user to the trusted application. In another embodiment of the present teaching, OneStop may provide a SAML token with respect to the user to the trusted application. In still another embodiment of the present teaching, OneStop may provide a signed digital identity with respect to the user to the trusted application.
• If, however, verification of the selected credential fails atstep390, OneStop may, for example, return an authentication failure response atstep395.
• FIG. 4 shows exemplary system diagrams of OneStop with a standalone credential binding system, according to an embodiment of the present teaching. Having a standalone credential binding system provides strong privacy because it creates a separation between a person's identity information and the person's credentials, i.e., information needed to prove the person's identity. In other words, the authentication process is separate from the identity information. In this embodiment, the link between the person and the person's identity is managed by an internal ID (GUID) of OneStop, which cannot be used nor understood by any other entity or system.
• In this embodiment of the present teaching, theOneStop identity center142 may manage the identity proofing process during the registration process of a user. TheOneStop identity center142 may engage various trusted identity proofing services or agents to register a user.
• Thecredential exchange146 in this embodiment provides no link to the person, or the person's identity information/attributes. Such implementation separates identity proofing process from the identity binding process.
• In this embodiment of the present teaching, the credential management and services may be handled by an independent system that comprises acredential exchange146,credentials database148, and a number ofcredential service agents150.
• Credentials database148 stores credential records for all OneStop users, as well as information relate to the verification of the credential. For example, an OneStop user may have a Symantec hard token that was issued to him/her as a LOA2 credential. Thecredential database148 may store, for example, a credential record for the OneStop user that includes, for example, the serial number of the Symantec hard token, its classification as a LOA2, its issuing entity OneStop, the URL that relate to the verification process of the hard token, the valid period of the hard token, the option to renew, the permission to replace with a new hard token, and any other relevant information. The OneStop user may be referenced in thecredential database148 by, for example, a GUID of the OneStop user.
• A credential record in thecredential database148 is configured to store various types of credentials of different LOAs. For example, a credential record may store a LOA2 strong or encrypted password, a credential record may store an identifier to a LOA3 or LOA4 smart card, a credential record may store a mobile phone id. A credential record may also operable to store PKI keys, digital certificates or any other type of digital credentials.
• Thecredential exchange146 may also manage credential binding, where an OneStop user's GUID become associated with a credential record. Thecredential exchange146 also manages credentials for OneStop users and initiates credential verification process with appropriatecredential service agents150. In one embodiment of the present teaching, thecredential exchange146 is operable to issue new credentials to OneStop users, for example, at the demand ofOneStop identity center142. Thecredential exchange146 may be operable to issue replacement credentials for OneStop users or to extend the expiration period of an existing credential.
• In one embodiment of the present teaching, thecredential exchange146 is a cloud based service provider that operates independently ofOneStop identity center142, where secure communication between OneStop and thecredential exchange146 is maintained.
• In the present teaching,end user110 may include an entity, such as, for example, a person, that communicates with trustedapplications130. The end user may110 may have access to a number of personal devices, such as, for example, a mobile phone, a personal computer. Theend user110 may also have access to a number of security devices, such as, for example, a smart card, a Symantec token, a RSA secure ID, an Ezio secure card. The end user may also have access to a communicator, such as a lap top computer, a mobile phone, or a tablet computer, which can have access to the Internet and can communicate with service providers online. Theend user110 may also include biometric collectors, for example, a voice recorder, a finger print scanner, an iris scanner and any other devices and computer applications that is required to collect a particular biometric sample. Theend user110 may also include any other credential collector, such as, for example, any device, any computer or mobile applications, where by the person may provide inputs about a particular credential so that the credential can be verified.
• FIG. 5 shows a flowchart of an exemplary process in which theOneStop identity center142 communicates with astandalone credential exchange146 to manage credentials for OneStop users, according to an embodiment of the present teaching. Atstep510,OneStop identity center142 receives an identity request, for example an authentication request of anend user110, from a trustedapplication130. The authentication request may include the end user's OneStop identifier GUON (First Name, Last Name and & Chosen Name), and an overall LOA level that the trustedapplication130 requires for the authentication quality.
• Assuming, in this example, theend user110 is a valid, pre-registered user in OneStop, and theend user110 has an identity proofing record of required LOA or above. Theend user110 is identified with the user's GUON and is referenced internally in the OneStop system with a corresponding GUID. Atstep520, theOneStop identity center142 may translate the OneStop identifier GUON (First Name, Last Name and & Chosen Name) to the corresponding GUID that uniquely identifies the end user's110 account in OneStop.
• Atstep530, theOneStop identity center142 may send a credential request to thecredential exchange146. The credential request includes, for example, the GUID of theend user110, and the LOA that the trustedapplication110 requires. Atstep540, upon receipt of the GUID and the credential request, thecredential exchange146 look up available qualifying credentials for theend user110 based on the GUID and the LOA. For example, thecredential exchange146 may search in thecredential database148 and obtain a list of all active credentials that are bound to the GUID and has an LOA at the requested LOA or above.
• If the search is not successful and found a qualifying credential for theend user110 atstep545, thecredential exchange146 may return a failure response toOneStop identity center142, atstep546. In one embodiment of the present teaching, upon receipt of a failure response from thecredential exchange146, theOneStop identity center142 may initiate a process to issue a new credential at the desired LOA to theend user110 atstep548. In one embodiment of the present teaching, upon successful issuance of the new credential to theend user110, theOneStop identity center142 may bind the new credential to theend user110 in thecredential exchange146. For example, theOneStop identity center142 may send a “Bind” request to thecredential exchange146, which may include the new credential information and the GUID which shall be bound to the new credential.
• If the search is successful, thecredential exchange146 provides the found credentials to theOneStop identity center142 atstep550. In one example, thecredential exchange146 may provide, for each qualifying credential, the identifier of the credential (e.g. a serial number of a Symantec token or a serial number of a RSA secure ID). Upon receipt of the credential list, theOneStop identity center142 may display the list of credentials to theend user110 in a user interface, such as, for example, theuser interface component220 or230 as shown in FIG.2-a, FIG.2-b, respectively.
• Atstep555, theOneStop identity center142 may receive a credential selection made by theend user110, for example, through auser interface component220 or230 as shown in FIG.2-aand FIG.2-brespectively. In one embodiment of the present teaching, user selection of the credential in theuser interface220 or230 may trigger the presentation of a credential verification user interface, where theend user110 is enabled to input information needed to verify the credential. For example, user selection of the Symantec (OneStop)242-acredential may trigger the presentation of another user interface, such as, for example, a text box to enter a onetime pass code.
• Thecredential exchange146 may select acredential service agent150 that provides the verification service of the user selected credential atstep560. Thecredential exchange146 may, for example, initiate a verification process in the selectedcredential service agent150 atstep565.
• In one embodiment of the present teaching, theOneStop identity center142 collects user inputs that relate to verification of the selected credential via a user interface (e.g. the text box to center the onetime passcode) and pass the user inputs (e.g., the onetime passcode that user provided) on to thecredential exchange146 in a “Credential Verification” request. Thecredential exchange146 may, for example, assemble information required to verify the credential based on the received user inputs to the selectedcredential service agent150. Thecredential exchange146 may also provide to the selectedcredential service agent150, additional information from the credential database with respect to the selected credential, including, for example, the GUID, the verification history of the selected credential, the expiration period of the selected credential, as well as other information related to the selected credential.
• In one example, theend user110 may have selected a Symantec hard token, for example by selecting the Symantec (OneStop) component252-avia theuser interface230 as shown in FIG.2-b. In one embodiment of the present teaching, thecredential exchange146 may obtain information needed to verify the selected credential from the credential record of the selected Symantec token and pass them to the Symantec credential service agent150-b. For example, thecredential exchange146 may provide the serial number of the Symantec hard token and a onetime passcode that user provided.
• Atstep565, the selectedcredential service agent150 may verify the selected credential. For example, the selectedcredential service agent150 may communicate with theend user110 via a secure channel to complete the verification process. For example, theend user110 may have selected a xFA credential, for example by selecting the xFA component252-bvia theuser interface230 as shown in FIG.2-b. In one embodiment of the present teaching, thecredential exchange146 may provide a link through the OneStop user interface to an xFA client application so that theend user110 may be enabled to establish a secure channel with the xFA credential service provider.
• In this example, thecredential exchange146 may provide an internal xFA ID whereby theend user110 is bound in the xFA system. The internal xFA ID may, for example, be stored as a part of the credential record for the xFA credential of theend user110 in thecredential database148. Theend user110 may, for example, provide verification information through the secure channel, such as, for example, provide a voice sample, as well as the xFA internal ID, to the xFA credential service provider to complete the verification process ofstep565.
• As a result of the credential verification step of565, the selectedcredential service agent150 may pass the authentication response to theOneStop identity center142 atstep570. In one embodiment of the present teaching, the selectedcredential service agent150 may send the verification result to thecredential exchange146.
• In another embodiment of the present teaching, the selected credential service agent may send the verification result directly toOneStop identity center142.
• In one embodiment of the present teaching, the selectedcredential service agent150 includes a credential database and provides credential binding services. In this embodiment, the selectedcredential service agent150 binds the user's OneStop GUID with the user's credential information, such as for example, the user's initial voice sample, the serial number of a hard token. In this embodiment, theOneStop identity center142 may send the credential verification request directly to thecredential service agent150 with respect to a GUID. The credential verification agent may receive verification results directly from thecredential service agent150, atstep570.
• In event the credential verification step of565 fails, theend user110 may, for example be directed to the user interface (e.g.,220 or230 of FIG.2-a, FIG.2-b) to try again or to select a different credential.
• If the credential verification is successful atstep575, theOneStop identity center142 may return a positive authentication response to the trusted application. For example, theOneStop identity center142 may provide an ID token with an expiration time and following the OpenID Connect protocol. In another example, theOneStop identity center142 may provide a SAML token to confirm the identity assertion. In still another example, theOneStop identity center142 may provide a signed digital identity for theend user110.
• FIG.6-ashows a conceptual view of an exemplary role of OneStop in which OneStop as an attribute broker among various sites, according to an embodiment of the present teaching. As shown in FIG.6-a, aperson610 may have identities1 (610-a) to n (610-n) that he has established that are distributed insite1 to n, respectively. OneStop provides a centralized management for identities1-nvia the trust relationship between theOneStop web site630 and the various site1-n.
• OneStop provides oneuniversal OneStop identity620 that may, for example, access to all attributes provided by identities1-n. In one embodiment of the present teaching, OneStop is operable to propagate attribute values acrossidentities1 to n to provide an efficient manner in updating shared attributes. For example, Ellen Smith & Willow, as register with OneStop, may have changed her last name from “Smith” to “Gates” upon marriage. In one embodiment of the present teaching, the last name attribute is maintained at OneStop; Ellen has, for example, consented to share this OneStop last name attribute with site1-nautomatically. As a result, OneStop may update sites1-nwith the last name change in identities1-nrespectively.
• FIG.6-bshows portions of data used in an exemplary attribute management feature, according to an embodiment of the present teaching. As a centralized manager for a person's identity, OneStop manages all accessible identity attributes that are associated with the OneStop user. In one embodiment of the present teaching, OneStop ensures source site of each attribute and provides guidance as to where else (other sites) such attribute are also used.
• In one embodiment of the present teaching, as show in FIG.6-b, OneStop owns and provides a number of demographic attributes of a person, such as, for example, first name, last name, date of birth, gender and zip code. Following the OneStop user's consent (See FIG.6-d), OneStop may share these demographic attributes with a list of applications, such as, for example, sites as listed on the corresponding “Attribute Consumer” column. In the example as shown in FIG.6-b, OneStop may share the OneStop user's first name, last name and gender with n sites (site1-n). In contrast, OneStop may share the Date of Birth attribute of the user to only 2 sites (site1—Citi bank and site n-myhealth.com).
• To be a trusted attribute source, OneStop may follow certain protocols to ensure the accuracies of these attributes. For example, OneStop may periodically check with the US post office to ensure that it has the most recent zip code of its use.
• FIG.6-cshows exemplary system diagrams of OneStop where OneStop acts as an attribute broker, according to an embodiment of the present teaching. The present teaching enables the user to determine the scope of the attributes that are shared. The present teaching also enables the user to manage which site the user chooses to be the source of particular attribute, and which site(s) may consume (get updates from) the attribute values from the source site.End users110 in this embodiment use theOneStop application635 to interface with theOneStop identity service140 for registration and attribute sharing.
• The present teaching also enables an attribute exchange among various applications with a centralized authorization model. In one embodiment of the present teaching, OneStop applies the OAuth 2.0 protocol to provide authorization and access control to attribute sharing based on user consent. In this embodiment, OneStop acts as the pseudo resource owner. As a result, user authorization can be implemented in one centralized OneStop authorization server, such as, for example,Oauth2 Authorization Server644. The present teaching alleviates the burden on each site/resource owner to implement its own authorization server.
• OAuth 2.0 protocol has three phases: (1) requesting an Authorization Grant; (2) exchanging the Authorization Grant for an Access Token; and (3) accessing the resources using this Access Token. In one embodiment of the present teaching, OneStop uses OpenID Connect (http://openid.net/connect/faq/) as another identity layer on top of OAuth 2.0 protocol. OAuth applications can get authentication event information over the ID Token and can get the extra claims of the authenticated user from the OpenID Connect UserInfo endpoint.
• Attribute Sharing Manager640 is operable to manage the attribute sharing among various trustedapplications130. As shown in the user interface below in FIG.6-d,attribute sharing manager640 receives user decisions as to what attributes to share, to which the attributes are shared and store the attribute sharing decisions in anattribute map database642.
• Theattribute sharing manager640 may also be operable to ensure the accuracy of the attributes. For example, theattribute sharing manager640 may periodically check with government or authorities to maintain the accuracies of the attributes. For example, theattribute sharing manager640 may periodically check with the address changes requests submitted in the US postal to update zip code attribute of OneStop users. In another example, the attribute sharing manager may periodically get updates from the Social Security Administration's website.
• In another example, the end user may manually change the attributes. In another example, a certified trusted entity may be enabled to conduct attribute updates in theattribute sharing manager640, such as a trusted site of an auditing agency or regulation website, or an identity proof agent.
• Theattribute sharing manager640 may keep a record of attributes revision history, such as, for example, the time, place and manner as to how the attribute is revised, the value change at each revision.
• TheOnesStop identity service140 in this embodiment further includes an OneStop registration service646 that is responsible for registering OneStop users upon identity proofing of the users byidentity proofing agents648. The details of OneStop users registration are described below with respect toFIG. 8.
• FIG.6-dshows an exemplary user interface of OneStop where the user may manage attribute sharing among various trusted applications. Theuser interface650 includes four components:UI component652,654,656, and658 respectively
• TheUI component652 allows the user to select one or many attributes that are to be shared among a set of applications/sites. TheUI component652 also allows the user to update any attribute values, for example by clicking on the update button. TheUI component652 may also allow user to select other attributes that are not currently displayed, by clicking on the “More” button, which may trigger another UI for displaying more attributes options.
• TheUI component654 allows the user to select the set of application/sites where the attributes selected, for example, inUI component652, may be shared. TheUI component654 allows the user to consent to the attributes sharing to the set of selected applications. TheUI component652 may allow the user to select more sites to share the selected attributes, for example, by clicking on the “More” button, which may trigger another UI for displaying more application/site options.
• TheUI component656 allows user to select a default set of attributes with new applications. In this example, the user may elect from a list of demographics information, including the user's first name, last name, zip code, gender and birth month and day.
• TheUI component658 allows the user to reject any attribute sharing among the applications, by for example, click on the “Deny” button.
• FIG. 7 shows exemplary user interface for an authenticated user of a trusted application to register with the OneStop identity service provider, according to an embodiment of the present teaching. The trusted application may be certified to have an overall LOA for its users. The trusted application may be a member of the trust frame work, or have been certified by a third party or an government agency to have followed the practices to reached LOA when identity proofing for its users. In one example, the trusted application is certified at LOA3, thus ensures its users to have passed LOA3 identity proofing. The trusted application may also use a LOA3 credential to authenticate its users. Assuming OneStop identity service provider is to trust the trusted application, the authenticated user of the trusted application may be provided an option to become an OneStop user, so that the user may have access to the OneStop identity services.
• In one embodiment of the present teaching, during an active session of the authenticated user in the trusted application, the user may have access to theuser interface710, as shown inFIG. 7, to automatically register to OneStop identity service provider. In this example, the trusted application provided to the authenticated user a list of attributes that OneStop requires, as shown inUI component720. The list may include, for example, the user's 5 attributes as stored in the trusted application, such as, for example, first name, last name, zip code, and gender and birth month. The user may elect to consent to the sharing of these 5 attributes. The user may elect to not consent to the sharing of these 5 attributes. The user may also elect to update any inaccuracy of these 5 attributes. Having user consent to the sharing of these 5 attributes, may enable OneStop to initiate a registration process of the authenticated user, which will be explained in more detail below inFIG. 8.
• FIG. 8 shows a flowchart of an exemplary process in which an authenticated user of a trusted application shares the user's identity attributes in the trusted application with OneStop service provider in order to register with OneStop and become an OneStop user, according to an embodiment of the present teaching.
• In one embodiment of the present teaching, OneStop may enroll users of a trusted application in batch mode. For example, the trusted application may share with OneStop a group of its users' profiles or attributes, such as, for example, demographics attributes. Trusting these users to have been properly identity proofed by the trusted application at a certain LOA, OneStop may register the group of users in the OneStop system in a batch mode. In one example, OneStop may register a group of users from an EPCS application, where the EPCS users are doctors who may prescribe controlled substances to patients. The EPCS users are identity proofed at LOA3 and are authenticated to the EPCS application at LOA3 via a two factor authentication process.
• OneStop may, for example, check to make sure that the EPCS user does not already have an OneStop user account. In one embodiment of the present teaching, OneStop may create a default chosen name for each new user from EPCS application and allow the new user to change it when the new user's first login to the OneStop. For example, OneStop may use the new user's birth month and day as the user's initial temporary chosen name. For a user who has a birth date of August 16, OneStop may create a default chosen name, such as, for example, “0816” or “Aug16” or “August16.”
• In another embodiment of the present teaching, as illustrated inFIG. 8, an authenticated user of a trusted application may individually register to the OneStop system. Atstep810, the trusted application may obtain the current authenticated user's consent to share a list of attributes with OneStop. For example, the trusted application my present to the currently authenticated user a user interface, such as for example,user interface710 inFIG. 7, a list of attributes that OneStop requires. Upon receiving the current user's consent, the trusted application securely sends the OneStop the attributes with respect to the current user.
• Atstep820, OneStop receives the current user's identity attributes from the trusted application. Atstep830, OneStop may, for example, search within OneStop to see if there is any existing user that has matching attribute values to the received attributes values. If so, the user is already registered in OneStop. OneStop may enable the current user the option to (a) register a new credential, such as, for example, the credential that the current user used to be authenticated by the trusted application (viasteps840,842,844 and848); (b) register new attribute(s) of the user with OneStop (step870).
• In one embodiment of the present teaching, instep840, the current user provides the current application credential to OneStop. For example, the current user of the EPCS application may provide the serial number of the Symantec token to OneStop. In one example, OneStop may also require user to provide the onetime passcode showing on the Symantec token. In one example, OneStop may verify the Symantec token atstep842. The verification of the selected credential is checked atstep844. Upon successful verification, OneStop may bind the new credential, such as, the Symantec token, to the current user's OneStop account, atstep848. If the verification of the selected credential is unsuccessful, then the process exits atstep895.
• Atstep830, if the current user of the trusted application is not found within OneStop, the user may, for example, provided an option to enroll in OneStop through a user interface atstep832. The user may, for example, choose to proceed with enrolling in OneStop at832. If the user opts not to be enrolled in OneStop, the process exits atstep895. Atstep834, whether the user has passed sufficient identity proofing process in the trusted application and has reached sufficient LOA for identity proofing are checked. If the test is failed atstep834, then the process exits atstep895. If the user has passed sufficient identity proofing process in the trusted application and has reached sufficient LOA for identity proofing at834, then OneStop may register the user in OneStop atstep850. For example, OneStop may, atstep860, save the current user and the user's attributes in OneStop's identity repository, such as, for example, theidentity database144.
• In one embodiment of the present teaching, OneStop may also provide the current user with the option to register a new credential viasteps840,842,844 and848. OneStop may also provide the current the user with the option to register new attribute(s) from the trusted application with OneStop atstep870.
• FIG. 9 shows a flowchart of an exemplary process in which an OneStop user may register to a new trusted application, according to an embodiment of the present teaching. To register with a new trusted application, a user normally needs to provide a significant amount of information with respect the user to the new application. Some of this information, for example, is used for identity proofing purposes. Some of this information is needed for specific use by the new application. The present teaching provides interoperable identities through OneStop which allows a trusted new application to delegate the identity proofing task to OneStop. As a result, the user is relieved of the burden to provide a lengthy list of information, e.g., fill out a20 page PDF form online, and do so repeatedly, as each new application may require similar information for purpose of identity proofing.
• In one embodiment of the present teaching, the new application may decide to trust the identity proofing LOA that OneStop provides and forego the need to acquire these attributes. In another embodiment of the present teaching, the new application may still collect a number of attributes through OneStop attribute sharing mechanism, for example, to perform its own identity proofing process. In this example, the user may need to consent to a scope of the attributes that the new application may consume, such as, for example, provide inputs through theuser interface656 components, as shown in FIG.6-d.
• With respect to user information/attributes required specific to the new application, the present teaching provides various novel features. First, OneStop enables attribute sharing, so that the new application may consume existing user attributes from other applications, so that the user are also relieved of the burden to provide these attributes repeatedly. For example, a board certified doctor may have registered with an electronic prescription application, such as Rcopia. The doctor has provided Rcopia with information/attributes relate to his medical training upon registering to the Rcopia application. The same list of attributes will be needed for a new EPCS application, where the doctor may prescribe controlled substances. With the present teaching, the user may simply consent the sharing of these attributes from Rcopia to EPCS through OneStop.
• Additionally, OneStop enables the user to manage these attributes in one place, such as, in the Rcopia application. OneStop may enable or to provide attribute updates from the attribute source/owner, such as the Rcopia application, to the attribute consumers, such as the EPCS application. As such, the user no longer to do updates to these attributes, repeatedly, in each application that uses them.
• Second, OneStop enables the expansion of the user attributes openly because new attributes can be provided to the ecosystem from any application through time. Further, the distributed nature of the attributes which exists in an ever increasing number of applications, will allow a scalable overall ecosystem to expand without limit.
• In reference toFIG. 9, a new trusted application may provide an option for a new user to register to the new trusted application through OneStop. Upon user selection of this option, the new trusted application may send to OneStop its registration requirement, including for example, the overall LOA that the new application requires, a list of attributes with respect to the user that the new application would like to receive from OneStop,step910.
• In one embodiment of the present teaching, the new application may also provide a user interface for the user to login to OneStop at the desired LOA, such as, for example,user interface220 or230 as shown in FIG.2-aand FIG.2-b. If the user successfully logins to OneStop at the desired LOA atstep920, the OneStop service provider may provide a positive authentication response to the new site atstep950. Otherwise, OneStop responds to the new application with authentication failure atstep930. Atstep940, OneStop my provide options for the failed user to remedy the failed login. In one embodiment of the present teaching, if the failure is due to insufficient identity proofing, OneStop may provide user interface to enable user to undertake more identity proofing process to reach a desired LOA level. In another example, if the failure is due to lacking of a credential of the sufficient LOA, OneStop may initiate a proper credential issuance process.
• Upon successful login to the OneStop at the required LOA, the new application may, for example, interact with OneStop to complete the registration process. In one example, the new application requires additional attributes from OneStop. The user may, for example, be provided with a user interface, similar to the user interface shown in FIG.6-d, so that user may consent to the sharing of the list of required attributes to the new application atstep950.
• Further, the new application may enable the user to select a list of new attributes elect to the new application be the source/owner of these attributes atstep960. The new application may also enable the user to provide a list of attribute consumer applications/sites for each new attribute, so that these new attributes or their updates can be shared to the attribute consumer applications/sites, atstep970. In another example, the new application provides new attributes to OneStop and entrust OneStop to be the attribute source for these attributes.
• In one embodiment of the present teaching, OneStop may accept the user's creation of these new attribute values in the new application as is. In another embodiment of the present teaching, OneStop may provide additional service, such as, for example, verifying the newly added attributes and their values before accepting them in the OneStop system atstep980. For example, a new attribute “NPI number” is entered by the user of a new eRx application. OneStop may trigger verification services from another entity, such as, for example, a database that includes the most current NPI number data to ensure the accuracy of the NPI number value. The verification result is checked atstep990. If the verification is not successfully, the process exits atstep995.
• Finally, if the verification is successful, OneStop may update the attribute map to include the attribute management settings with respect to the new application, atstep999. For example, OneStop may record the attribute sharing of the existing attributes to the new application. OneStop may also record the new attributes and the consumers of the new attributes. In another example, the new application provides new attributes to OneStop and entrust OneStop to be the attribute source for these attributes.
• FIG. 10 depicts a general mobile device architecture on which the present teaching can be implemented. In this example, the user device by which end users could use for accessing the trustedapplications130, the OneStopidentity service provider140, and/or thecredential service agents150 is amobile device1000, including but is not limited to, a smart phone, a tablet, a music player, a handled gaming console, a global positioning system (GPS) receiver. Themobile device1000 in this example includes one or more central processing units (CPUs)1002, one or more graphic processing units (GPUs)1004, adisplay1006, amemory1008, acommunication platform1010, such as a wireless communication module,storage1012, and one or more input/output (I/O)devices1014. Any other suitable component, such as but not limited to a system bus or a controller (not shown), may also be included in themobile device1000. As shown inFIG. 10, amobile operating system1016, e.g., iOS, Android, Windows Phone, etc., and one or morelocal client applications1018 may be loaded into thememory1008 from thestorage1012 in order to be executed by theCPU1002. Thelocal client applications1018 may include a browser or any other suitable mobile apps for accessing the trustedapplications130, the OneStopidentity service provider140, and/or thecredential service agents150 on themobile device1000. Execution of thelocal client applications1018 may cause themobile device1000 to perform the processing as described above in the present teaching. For example, the display of the user interfaces shown in FIGS.2-a.2-b,6-d, and7 may be made by theGPU1004 in conjunction with thedisplay1006. User interactions with the user interfaces shown in FIGS.2-a.2-b,6-d, and7 may be achieved via the I/O devices1014 and provided to the trustedapplications130, the OneStopidentity service provider140, and/or thecredential service agents150 via thecommunication platform1010.
• To implement the present teaching, computer hardware platforms may be used as the hardware platform(s) for one or more of the elements described herein. The hardware elements, operating systems, and programming languages of such computers are conventional in nature, and it is presumed that those skilled in the art are adequately familiar therewith to adapt those technologies to implement the processing essentially as described herein. A computer with user interface elements may be used to implement a personal computer (PC) or other type of work station or terminal device, although a computer may also act as a server if appropriately programmed. It is believed that those skilled in the art are familiar with the structure, programming, and general operation of such computer equipment and as a result the drawings should be self-explanatory.
• FIG. 11 depicts a general computer architecture on which the present teaching can be implemented and has a functional block diagram illustration of a computer hardware platform that includes user interface elements. The computer may be a general-purpose computer or a special purpose computer. Thiscomputer1100 can be used to implement any components of the interoperable identity and interoperable credentials architecture as described herein. Different components of the system in the present teaching can all be implemented on one or more computers such ascomputer1100, via its hardware, software program, firmware, or a combination thereof. Although only one such computer is shown, for convenience, the computer functions relating to the target metric identification may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load.
• Thecomputer1100, for example, includesCOM ports1150 connected to and from a network connected thereto to facilitate data communications. Thecomputer1100 also includes a central processing unit (CPU)1120, in the form of one or more processors, for executing program instructions. The exemplary computer platform includes aninternal communication bus1110, program storage and data storage of different forms, e.g.,disk1170, read only memory (ROM)1130, or random access memory (RAM)1140, for various data files to be processed and/or communicated by the computer, as well as possibly program instructions to be executed by theCPU1120. Thecomputer1100 also includes an I/O component1160, supporting input/output flows between the computer and other components therein such asuser interface elements1180. Thecomputer1100 may also receive programming and data via network communications.
• Hence, aspects of the method of interoperable identity and interoperable credentials, as outlined above, may be embodied in programming. Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and/or associated data that is carried on or embodied in a type of machine readable medium. Tangible non-transitory “storage” type media include any or all of the memory or other storage for the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide storage at any time for the software programming.
• All or portions of the software may at times be communicated through a network such as the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer of the search engine operator or other explanation generation service provider into the hardware platform(s) of a computing environment or other system implementing a computing environment or similar functionalities in connection with generating explanations based on user inquiries. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links or the like, also may be considered as media bearing the software. As used herein, unless restricted to tangible “storage” media, terms such as computer or machine “readable medium” refer to any medium that participates in providing instructions to a processor for execution.
• Hence, a machine readable medium may take many forms, including but not limited to, a tangible storage medium, a carrier wave medium or physical transmission medium. Non-volatile storage media include, for example, optical or magnetic disks, such as any of the storage devices in any computer(s) or the like, which may be used to implement the system or any of its components as shown in the drawings. Volatile storage media include dynamic memory, such as a main memory of such a computer platform. Tangible transmission media include coaxial cables; copper wire and fiber optics, including the wires that form a bus within a computer system. Carrier-wave transmission media can take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media therefore include for example: a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD or DVD-ROM, any other optical medium, punch cards paper tape, any other physical storage medium with patterns of holes, a RAM, a PROM and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave transporting data or instructions, cables or links transporting such a carrier wave, or any other medium from which a computer can read programming code and/or data. Many of these forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.
• Those skilled in the art will recognize that the present teachings are amenable to a variety of modifications and/or enhancements. For example, although the implementation of various components described above may be embodied in a hardware device, it can also be implemented as a software only solution—e.g., an installation on an existing server. In addition, the dynamic relation/event detector and its components as disclosed herein can be implemented as a firmware, firmware/software combination, firmware/hardware combination, or a hardware/firmware/software combination.
• While the foregoing has described what are considered to be the best mode and/or other examples, it is understood that various modifications may be made therein and that the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be applied in numerous applications, only some of which have been described herein. It is intended by the following claims to claim any and all applications, modifications and variations that fall within the true scope of the present teachings.

Claims (20)

We claim:

1. A method implemented on a computing device having at least one processor, storage, and a communication platform capable of making a connection to a network for managing identity information of a person, the method comprising the steps of:

receiving the person's name after the identity of the person has been proved at an identity proofing (IDP) level of assurance (LOA);

receiving information related to a credential that is associated with the person, wherein the credential can be verified by a credential verification service at a LOA that is of the same or lower level than the IDP LOA;

obtaining a chosen name of the person, wherein a combination of the person's name and the chosen name uniquely identifies the person;

creating a digital identity based, at least in part, on the person's name and the chosen name;

generating a globally unique identifier (GUID) that associates with the digital identity and binds to the person;

binding the GUID with the credential;

storing a record of the person that includes at least the IDP LOA and information related to the credential and the credential verification service; and

transmitting information to the credential verification service that the person is to be authenticated based on a real-time user input associated with the credential.

2. The method ofclaim 1, wherein binding the GUID with the credential occurs at an identity center or at a credential exchange.

3. The method ofclaim 2, wherein the identity of the person is unknown to the credential exchange.

4. The method ofclaim 1, wherein the identity of the person has been proved by an IDP source.

5. The method ofclaim 4, wherein the IDP source includes at least one of:

an identity proofing service provider that is an approved member of a trust framework;

a government agency;

a trusted healthcare organization; and

a trusted application wherein users of the trusted application passed the identity proofing at the IDP LOA.

6. A method implemented on a computing device having at least one processor, storage, and a communication platform capable of making a connection to a network for authenticating an online user, the method comprising the steps of:

receiving an authentication request originated from the online user in connection with an application having a first level of assurance (LOA), wherein the authentication request includes the online user's input;

searching a digital identity based on the online user's input;

obtaining a globally unique identifier (GUID) associated with the digital identity when the digital identity is found;

providing one or more credentials that are bound to the GUID at the first LOA or a higher LOA;

receiving a selection of at least one credential from the one or more credentials;

retrieving information of the selected at least one credential that includes a credential verification service capable of verifying the selected at least one credential;

requesting verification of the selected at least one credential of the online user based on the GUID;

receiving a verification response; and

authenticating the online user at the first LOA when the verification response indicates that the selected at least one credential is successfully verified.

7. The method ofclaim 6, further comprising denying authentication of the online user when the digital identity is not found.

8. The method ofclaim 6, wherein the step of requesting verification of the selected at least one credential of the online user based on the GUID comprises:

soliciting information associated with the selected at least one credential from the online user; and

sending a verification request to the credential verification service with the GUID and the received information associated with the selected at least one credential.

9. The method ofclaim 6, wherein the step of requesting verification of the selected at least one credential of the online user based on the GUID includes sending a verification request to the credential verification service with the GUID.

10. The method ofclaim 6, wherein the first LOA is 2 or 3.

11. The method ofclaim 6 further comprising the steps of:

providing, upon the successful authentication, the one or more credentials;

receiving a choice of at least one of the one or more credentials; and

disabling the chosen at least one credential.

12. The method ofclaim 6 further comprising the steps of:

receiving, upon the successful authentication, information about a credential with an associated LOA that is the same or lower than the first LOA, as well as a credential verification service capable of verifying the credential; and

binding the GUID with the credential and the associated LOA.

13. The method ofclaim 12 further comprising the step of:

storing the received information; or

sending the received information to a credential exchange.

14. The method ofclaim 6, wherein an authenticated session is created upon the successful authentication of the online user.

15. The method ofclaim 14, further comprising sharing the authenticated session with another application.

16. The method ofclaim 14, wherein the authenticated session expires at a predetermined period of time.

17. The method ofclaim 16, wherein the predetermined period of time is configurable.

18. A method implemented on a computing device having at least one processor, storage, and a communication platform capable of making a connection to a network for authenticating an online user, the method comprising the steps of:

storing one or more credentials associated with a globally unique identifier (GUID) corresponding to a person;

receiving the GUID and a first level of assurance (LOA) associated with an application;

determining at least one of the one or more credentials, wherein each of the determined at least one credential is at the first LOA or a higher LOA; and

providing the determined at least one credential so that the online user who claims to be the person can be authenticated based on a credential selected from the at least one credential.

19. The method ofclaim 18 further comprising receiving information about one of the one or more credentials associated with the GUID at a LOA from an identify center.

20. The method ofclaim 19, wherein the information further includes a credential verification service capable of verifying the credential.

Images