Systems and methods for use in sharing digital identities

Systems and methods are provided for using an identity provider (IDP) to implement enrollment of a user to a relying party. One exemplary method includes receiving a login credential for a user from a relying party in connection with enrolling the user to the relying party, where the user is associated with a digital identity and the digital identity includes personal identifying information (PII) of the user. The method also includes generating a one-time-passcode (OTP) and transmitting the OTP to a communication device bound to the digital identity associated with the user, receiving an OTP from the relying party, and when the OTP generated by the computing device matches the OTP received from the relying party, compiling an enrollment file for the user including at least a portion of the PII of the user. The method then includes transmitting the enrollment file to the relying party.

FIELD

The present disclosure is generally directed to systems and methods for use in sharing digital identities in connection with login processes associated with relying parties.

BACKGROUND

Users are known to access a variety of different accounts in a given day. The accounts may include, without limitation, banking institution web accounts, email accounts, fitness application accounts, etc. Each of the accounts may require particular credentials, such as a user name and password when accessing the account, to inhibit unauthorized persons from doing the same. As such, when the users intend to access the accounts, the users are required to, in general, login or sign-in to the accounts. In connection therewith, the users typically select user names, passwords or other credentials for the accounts when first registering for the accounts, or thereafter, and then subsequently use the credentials to access the accounts when desired. Often, the credentials selected by the users are be the same for different ones of the users' accounts.

DETAILED DESCRIPTION

When users enroll for accounts (from relying parties), depending on types of the accounts, the users are often asked for the same data repeatedly for each of the accounts. This often may be tedious and time consuming for the users as the number of accounts for which they enroll grows. In addition, from time to time, preferred usernames or other login credentials selected by the users during registration are already taken/used, whereby the users are forced to select login credentials dissimilar from those used for their other accounts. And, as the number of such different login credentials grows, the users may find it increasingly difficult to remember their particular login credentials for each of their different accounts.

Uniquely, the systems and methods herein permit sharing of digital identities associated with users to relying parties (or account access interfaces associated therewith), whereby the enrollment processes of the users for accounts at the relying parties is streamlined. In particular, an identity provider (IDP) permits a user to register once, with the IDP, whereby a digital identity for the user is created and stored in a ledger data structure (i.e., a vault) associated with the IDP. Apart from the user, the IDP also offers a software development kit (SDK) to relying parties, which may be employed as a network-based application particularly associated with each of the relying parties. The SDK facilitates interactions between the user, the relying party, and the IDP to retrieve a digital identity (or portion thereof) (in a tokenized or otherwise secured manner), directly from the IDP, for use in enrolling the user with the relying party (in connection with opening a new account, etc.). This provides improved security to personal identifying information (PII) of the user included in the digital identity. In addition, the IDP and SDK permit login credentials to be managed by the user, through the IDP and/or SDK, for the user's various different accounts, whereby the user may be permitted to login to the relying party via a credential associated with the IDP and/or through use of a communication device bound to the digital identity at the IDP. In this manner, the IDP is therefore injected as a new party to the enrollment of the users for different accounts with different relying parties, thereby providing more efficient enrollment and management of credentials for each of the different accounts.

FIG. 1illustrates an exemplary system100in which one or more aspects of the present disclosure may be implemented. Although the system100is presented in one arrangement, other embodiments may include one or more parts of the system100(or other parts) arranged otherwise depending on, for example, particular types of accounts and registrations available in the systems, relationships between users and relying parties, privacy concerns and/or requirements, etc.

The illustrated system100generally includes a digital identity provider (IDP)102, a ledger data structure104, a relying party106, and a communication device108associated with a user110, each of which is coupled in communication with one another through one or more networks. The network(s) is/are indicated generally by arrowed lines inFIG. 1, and each may include one or more of, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated inFIG. 1, or any combination thereof.

In the illustrated embodiment, the IDP102is generally a digital identity computing device or group of computing devices, which is/are configured to collect personal identifying information (PII) for users and to generate digital identities for the users (e.g., in response to requests by the users to do so, etc.). When the digital identities are generated, the IDP102is configured to store the digital identities in the ledger data structure104. It should be appreciated that the IDP102may be a standalone entity, or it may be integrated, at least in part, in another entity. For example, the IDP102may be included in a payment network, such as, for example, the Mastercard® payment network, etc.

The IDP102includes and/or is associated with an interface112, which is configured to permit (or facilitate) users (e.g., the user110, etc.) to register a digital identity with the IDP102, to manage an existing digital identity, and even to delete an existing digital identity. In one example, the interface112includes a website, hosted by the IDP102or on behalf of the IDP102, whereby the interface112is accessible through a web browser at the user's communication device108and configures the IDP102to perform as described (e.g., to generate and/or manage a digital identity for the user110, etc.). Additionally, or alternatively, in other examples, the interface112may include a web-based application (e.g., application118, etc.), which is downloaded and executed on the user's communication device108to configure the communication device108to perform as described. Additional details of the interface112are described further below.

The relying party106includes a business or other entity that relies on identities of users to provide data or other services to the users. In this embodiment, the relying party106also includes and/or provides an interface116, through which the data, for example, is made available to users (including the user110). In one example, the interface116may include a website, hosted by the relying party106or on behalf of the relying party106, whereby the interface116is accessible through a web browser at the communication device108of the user110and configures the relying party106to perform as described. Additionally, or alternatively, in other examples, the interface116may include a web-based application, which is downloaded and executed on the user's communication device108to configure the communication device108to perform as described. Regardless of the type, though, the interface116is configured to issue accounts to users (once enrolled), which then permit the users to access data through the interface116, by presenting login credentials to the interface116. For instance, the interface116may include a banking institution website, whereby the user110is permitted to login and view bank statements, account balances, or even direct financial transactions, etc. associated with his/her account. Or, the interface116may be associated with an account of the user110at a fitness application installed at the user's communication device108, and through which the user110may access and view data received from a fitness tracker, set fitness goals, and share fitness data with other users, etc.

With continued reference toFIG. 1, the IDP102includes and/or is associated with a software development kit (SDK)114, which is provided in connection with digital identity services offered by the IDP102. In particular, when the relying party106opts into the digital identity services of the IDP102, the IDP102is configured to provide the SDK114to the relying party106for integration with the interface116of the relying party106. The SDK114is provided to configure the device executing the SDK114(e.g., a device at the relying party106, the user's communication device108, etc.) to interact with the IDP102to register a digital identity and to disseminate a registered digital identity, securely, to one or more relying parties.

In connection with the digital identity services from the IDP102, the relying party106is required to conform to certain restrictions and/or procedures. First, the relying party106is configured to generate and transmit, to the IDP102, an enrollment requirement file for enrollment of a user to an account at the relying party (and for access to the interface112). The enrollment requirement file may include, for example, a listing of the required and/or optional PII for enrollment of the user to an account with the relying party106, etc. The listing may include, for example, a name of the user, a mailing address of the user, a phone number of the user, a social security number of the user, etc. Upon receipt, the IDP102is configured to store the enrollment requirement file in memory. Second, the relying party106is configured to receive, from the IDP102, and implement, an encryption mechanism (e.g., an encryption key, etc.) to secure communication between the IDP102and the relying party106(e.g., directly or via the SDK114, etc.). And finally, the relying party106is configured to receive a deletion command from the IDP102and to delete PII or associated data received from the IDP102in connection with enrollment of the user.

The communication device108associated with the user110may include, for example, a portable communication device such as a tablet, smartphone, personal computers, etc. The communication device108is configured to permit the user110to access the interfaces112and116. In one example, the communication device108includes a web browser, which configures the communication device108to communicate with the IDP102and the relying party106, via the interface112and interface116, respectively. What's more, the communication device108also includes the network-based application118, which configures the communication device108to perform as described herein. In particular, the application118is associated with, created by, and/or disseminated by the IDP102, whereby the application118facilitates communication with the IDP102, as described in more detail below.

With that said, it should be appreciated that the user110is associated with an identity, which includes one or more of a name, a mailing address, a government ID number, an email address, a phone number, a birthdate, biometric references (e.g., facial images, etc.), a gender, an age, an eye, color, account numbers, an employee identifier, and/or other information sufficient to distinguish the user110from other users. The identity may be evidenced by one or more physical documents issued by an authority (e.g., a federal government (e.g., a passport, a social security card, etc.), an insurance provider, a telecommunication provider (e.g., a mobile network operator (or MNO), etc.), a department of motor vehicles (or DMV), or other trusted identity authority, etc.). Such identity of the user110, then, may then be the basis for (or at least partly the basis for) the digital identity of the user110at the IDP102.

While only one IDP102, one ledger data structure104, one relying party106, and one communication device108are illustrated in the system100, it should be appreciated that additional ones of these parts or features may be included in other system embodiments. In addition, it should be appreciated that the system100is applicable to multiple users.

FIG. 2illustrates an exemplary computing device200that can be used in the system100ofFIG. 1. The computing device200may include, for example, one or more servers, workstations, personal computers, laptops, tablets, smartphones, etc. In addition, the computing device200may include a single computing device, or it may include multiple computing devices located in close proximity or distributed over a geographic region, so long as the computing devices are specifically configured to function as described herein. In the exemplary embodiment ofFIG. 1, each of the IDP102, the ledger data structure104, the relying party106, and the communication device108may be considered, may include, and/or may be implemented in a computing device consistent with the computing device200, coupled to (and in communication with) one or more of the networks illustrated inFIG. 1. However, the system100should not be considered to be limited to the computing device200, as described below, as different computing devices and/or arrangements of computing devices may be used in other embodiments. In addition, different components and/or arrangements of components may be used in other computing devices.

Referring toFIG. 2, the exemplary computing device200includes a processor202and a memory204coupled to (and in communication with) the processor202. The processor202may include one or more processing units (e.g., in a multi-core configuration, etc.). For example, the processor202may include, without limitation, a central processing unit (CPU), a microcontroller, a reduced instruction set computer (RISC) processor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a gate array, and/or any other circuit or processor capable of the functions described herein.

The memory204, as described herein, is one or more devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. The memory204may include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. The memory204may be configured to store, without limitation, identity details and data related to identities of users, digital identities of users, biometric references for users, identifiers, tokens, other payment account credentials, login credentials for user accounts, and/or other types of data (and/or data structures) suitable for use as described herein. Furthermore, in various embodiments, computer-executable instructions may be stored in the memory204for execution by the processor202to cause the processor202to perform one or more of the functions described herein, such that the memory204is a physical, tangible, and non-transitory computer readable storage media. Such instructions often improve the efficiencies and/or performance of the processor202and/or other computer system components configured to perform one or more of the various operations herein, whereby such instructions (and the performance of the resulting operations) effectively transform the computing device into a special-purpose device. It should be appreciated that the memory204may include a variety of different memories, each implemented in one or more of the functions or processes described herein.

In the exemplary embodiment, the computing device200also includes a presentation unit206that is coupled to (and is in communication with) the processor202(however, it should be appreciated that the computing device200could include output devices other than the presentation unit206, etc.). The presentation unit206outputs information, visually or audibly, for example, to a user of the computing device200(e.g., prompts to the user110at the communication device108to enter PII, to enter credentials, etc.), etc. And various screens (e.g., as defined by the interfaces112and116, etc.) (e.g., including instructions to capture an image of a document, etc.) may be displayed at computing device200, and in particular at presentation unit206, to display certain information in connection therewith. The presentation unit206may include, without limitation, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, an “electronic ink” display, speakers, etc. In some embodiments, the presentation unit206may include multiple devices.

In addition, the computing device200includes an input device208that receives inputs from the user (i.e., user inputs) of the computing device200such as, for example, entries of PII, selections of portions of a digital identity to be shared with the relying party106, etc., as further described below. The input device208may include a single input device or multiple input devices. The input device208is coupled to (and is in communication with) the processor202and may include, for example, one or more of a keyboard, a pointing device, a mouse, a camera, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), another computing device, and/or an audio input device. In various exemplary embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device, may behave as both the presentation unit206and the input device208.

Further, the illustrated computing device200also includes a network interface210coupled to (and in communication with) the processor202and the memory204. The network interface210may include, without limitation, a wired network adapter, a wireless network adapter (e.g., a NFC adapter, a Bluetooth™ adapter, etc.), a mobile network adapter, or other device capable of communicating to one or more different ones of the networks herein and/or with other devices described herein. Further, in some exemplary embodiments, the computing device200may include the processor202and one or more network interfaces incorporated into or with the processor202.

Referring again toFIG. 1, the user110generally has two options to register a digital identity with the IDP102, either via the interface112(or the application118) directly through the IDP102, or via the interface116indirectly through the relying party106. In the former, the user110may access, at the communication device108, the interface112associated with the IDP102, whereby the user110interacts directly with the IDP102to register therewith and the IDP102is configured to register the user110through the operations described below (e.g., in connection with the SDK114, etc.).

In the later, the user110may access the IDP102through the SDK114integrated in the interface116, by selecting the option to interact with the IDP102for purposes of registration (e.g., via a button or other input included in the interface116which is selectable by the user110and linked to the SDK114, etc.). In response, in this option, the relying party106, as configured by the SDK114, displays an option to the user110to register with the IDP102as a new user. The user110then provides an input (i.e., a selection to register) to the communication device108, which in turn initiates the registration process. In particular, the relying party106, as configured by the SDK114, solicits a username, a password, an agreement to certain terms and conditions, PII, and (in some embodiments) biometric data from the user110at the communication device108. In response, the user110provides the same (e.g., username JSmith and password Bob1951, etc.) (and a password reminder “Dad's name and birth year?”) and further provides an agreement to the terms and conditions offered by the IDP102(for use of the digital identity service). In addition to the PII, the relying party106, as configured by the SDK114, is configured to solicit one or more settings associated with the username and password, such as, for example, using the same username and password for different relying parties when permitted, etc.

Regarding the PII, the user110may provide a name, a mailing address (e.g., a street, a city, a state and ZIP code, etc.), a home phone number, a work phone number, a cell phone number, an email address, government ID numbers (e.g., a driver's license number, a social security number, a passport number, etc.), his/her mother's maiden name, a gender, a birthplace, a date of birth, and a payment account credential, etc. (all, broadly, PII). It should be appreciated that additional PII may be solicited by the IDP102(directly or via the interface116or SDK114) from the user110in other embodiments (e.g., during registration, after initial registration, etc.). It should also be appreciated that when providing the PII, the user110may designate the PII into different classes, i.e., whether the PII is considered, for example, standard or enhanced for security purposes, etc. In this exemplary embodiment, the user110designates a name, a mailing address and a phone number as being standard PII, and further designates a social security number, his/her mother' maiden name and a birthplace as enhanced PII. It should be appreciated that the IDP102may offer and/or the user110may opt to include additional or different classes of PII in other embodiments.

FIG. 3illustrates an exemplary screen302(broadly, an interface or part of an interface) that may be displayed to the user110at the communication device108, by the relying party106, as configured by the SDK114(or by the interface116), in connection with registering the user110to the IDP102. As shown, the screen302solicits a username, a password, various PII, a class designation for enrollment with regard to the PII, etc. As further shown, the interface302also includes toggle button, which, when selected, causes additional screens304and306to be displayed. Specifically, the toggle option for reuse of the same credentials permits screen304to be displayed, which permits the user110to enter the preferred credentials for all new enrollments with relying parties (and through which the user's digital identity from the IDP102is used). And, the toggle option for classes of PII permits screen306to be displayed, which permits the user110to select the class of PII which is the default for enrollment with a relying party (or multiple relying parties) and enter specific PII to be included in the selected class of PII. It should be appreciated that the screen302is merely exemplary and that other screens may be displayed to solicit the same or different information in other embodiments.

What's more, as part of the registration process for the user110with the IDP102, the relying party106, as configured by the SDK114, captures a unique identifier associated with the user's communication device108, such as, for example, a media access control (MAC) address, a mobile equipment identifier (MEID), a serial number, etc., and provides the same to the IDP102.

With that said, it should be appreciated that the interface112at the IDP102(e.g., through a web-based interaction with the user110at the communication device108or through the application118, etc.) may similarly be used, by the IDP102, to directly receive the above-noted data from the user110(for registration with the IDP102), such as the username, the password, the various user settings, the agreement to terms and conditions for the digital identity service, the user's PII, the classes and unique identifier of the communication device108, the biometric data for the user110, etc. (directly and without reliance on the relying party106and/or the SDK114). In connection therewith, it should also be appreciated that screens similar to screens302-306may also be displayed to the user110at the communication device108, by the IDP102(or by the interface112), in connection with directly registering the user110to the IDP102. Here, the communication device108may also be configured (e.g., by the application118, etc.) to store the biometric received from the user110in memory (e.g., memory204, etc.) of the communication device108, for example, for subsequent use in authenticating the user110as described herein.

Then in the system100, when the PII is received from the user110(at the relying party106during indirect registration of the user110), the relying party106, as configured by the SDK114, passes the username, the password, the user's agreement to the terms and conditions for the proceed service, the selected settings, the user's PII (and PII classes), the received biometric, and the unique identifier associated with the user's communication device108to the IDP102. In response, the IDP102is configured to compile a digital identity for the user110, which includes the username, the password, the PII for the user110(and class designations), the biometric, and the unique identifier of the user's communication device108, and to store the digital identity in the ledger data structure104. Additionally, the IDP102is configured to bind the digital identity of the user110to the user's communication device108, based on the unique identifier of the communication device108. As indicated above, the unique identifier of the commination device108may include, but is not limited to, a MAC address, a unique device identifier (UDID), a MEID, etc. In connection with binding the user's digital identity to the communication device108, then, the unique identifier of the communication device108is included in and/or identified to the digital identity stored in the data structure104(such that the communication device108is linked to the user's digital identity) thereby permitting the communication device108(as associated with the unique identifier) to be a validation mechanism for a one-time passcode (OTP) or for a biometric authentication of the user110, as described more below. In this manner, therefore, the communication device108is identified as an authentication mechanism for the user110in connection with sharing the digital identity, or PII included therein, with one or more relying parties (such as the relying party106).

In turn, when the user110expects to enroll with a relying party (such as the relying party106), the user110is permitted to use the digital identity services of the IDP102to effect such enrollment.

Specifically, for example, the user110may seek to enroll with the relying party106to access an account at the relying party106and corresponding protected data associated with the relying party106(and potentially linked to the user's new account). In so doing, the user110may initially access the interface116for the relying party106(via the communication device108), whereby a screen for login is presented to the user110at the communication device108. The screen includes a button associated with the digital identity services of the IDP102. In response, the user110selects the button, and the SDK114is executed, by the relying party106, to cause the relying party106to display an IDP login screen to the user110at the communication device108(e.g., a light box overlaid on the interface116, etc.).

In response, the user110enters the username and password associated with his/her registration with the IDP102(i.e., JSmith and Bob1951) to the IDP login screen and selects an input to login. In turn, the relying party106, as configured by the SDK114, solicits a class of PII to be provided to the relying party106, which may include, for example, standard or enhanced. When the selection is made by the user110, the relying party106, as configured by the SDK114, passes the username, password, and designated class for PII to the IDP102. In turn, the IDP102is configured to generate an OTP for the transaction and to transmit the generated OTP to the communication device108, via the application118(as part of an authentication process for the user110). The communication device108, as configured by the application118, then displays the OTP to the user110. At the same time, the relying party106, as configured by the SDK114, causes a screen soliciting the OTP from the user110to be displayed at the communication device108. The user110enters the OTP, generated by the communication device108, to the screen, whereby it is received by the relying party106. And, the relying party106, as configured by the SDK114, transmits the OTP provided by the user110to the IDP102. And, upon receipt of the OTP from the relying party106, the IDP102is configured to authenticate the user110based on the OTP received from the relying party106matching the OTP generated at the communication device and transmitted to the IDP102. In this way, the binding of the user's communication device108to the user's digital identity is utilized for authentication of the user110(e.g., to identify the user110to his/her communication device108, etc.).

It should be appreciated that, in other embodiments, the IDP102may be configured to authenticate the user110via one or more biometrics received from the user110at the communication device108. In particular, the IDP102may be configured to request a biometric from the user110at the communication device108(e.g., via the application118, etc.) in connection with enrollment of the user110to the relying party106. In turn, the communication device108may be configured to receive the requested biometric from the user110and compare the biometric to a reference biometric stored in memory at the communication device108(e.g., as provided by the user110at the communication device108during registration to the IDP102, etc.). When the biometrics match (based on comparison techniques generally known in the art), the communication device108may then be configured to transmit an authentication message/confirmation to the IDP102. Alternatively, the communication device108may be configured, instead, to transmit the biometric received from the user110to the IDP102, whereby the IDP102may then compare the received biometric to the reference biometric for the user110. In either case, the binding of the user's communication device108to the user's digital identity is again utilized for authentication of the user110(e.g., to identify the user110to his/her communication device108, etc.).

However, when the user110is not authenticated (i.e., when the biometric provided by the user110does not match the reference biometric at the communication device108), the communication device108is configured to transmit a failure notice to the IDP102, and the IDP102is configured to transmit an enrollment failed indication to the relying party106, whereby the SDK114is configured to seek a further authentication attempt (e.g., via the IDP102, etc.) or to direct the user110to the interface116for conventional enrollment. In this manner, the relying party106is informed that no enrollment file (as described below) will be forthcoming from the IDP102.

With that said, it should be appreciated that the OTP, the biometric, and other mechanisms may be employed between the IDP102, the relying party106, and/or the user110to authenticate the user110in connection with enrollment of the user110to the relying party106(or registration of the user110to the IDP102, or login of the user110at the relying party106, etc.).

When the user110is ultimately authenticated, the IDP102is configured to compile an enrollment file for the user110, which is consistent with the class of PII selected by the user110(standard or enhanced) and the enrollment requirement file associated with the relying party106, and to encrypt or otherwise obscure the enrollment file (e.g., with an encryption key known to the SDK114, etc.). The IDP102is configured to then transmit the encrypted enrollment file to the relying party106. And, the relying party106is configured, in turn, to decrypt the enrollment file (as necessary) and to generate an account for the user110at the relying party106, which is specific to the user110and which is accessible via the username/password included in the enrollment file. Thereafter, the user110is permitted to access the account at the interface116of the relying party106to view content included therein. In this manner, the user110avoids providing the PII directly to the relying party106in order to enroll for the account through the interface116.

When the user110later returns to the interface116(e.g., to access his/her account at the relying party106, etc.), the interface116is again configured to present a login screen to the user110at the communication device108, whereby the user110is provided the option to login through the IDP102. When the user110selects to login through the IDP102, the relying party106, as configured by the SDK114, instructs the user110to generate a one-time passcode (OTP) for the transaction, whereby the communication device108is configured to generate the OTP (either with or without first authenticating the user110, for example, via a biometric provided by the user110, etc.). The communication device108is configured to then transmit the generated OPT to the IDP102and to display the OTP to the user110at the communication device108.

At the same time, as above, the relying party106, as configured by the SDK114, causes a screen soliciting the OTP from the user110to be displayed at the communication device108. And, in turn, the user110enters the OTP, generated by the communication device108, to the screen, whereby it is received by the relying party106. The relying party106, as configured by the SDK114, transmits the OTP provided by the user110to the IDP102. Then, upon receipt of the OTP from the communication device108and the relying party106, the IDP102is configured to authenticate the user110based on the OTPs being a match. When authenticated, the IDP102is configured to confirm authentication to the relying party106, whereby the user110is again permitted to be logged into the interface116(based on the OTP and without providing his/her login credentials or other credentials to the relying party106to obtain access to his/her account).

It should be appreciated that the IDP102is further configured to permit the user110to manage credentials and PII included in the user's digital identity stored in the ledger data structure104, for example, via the interface112(e.g., upon access by the user110to his/her account at the IDP102through the interface112, etc.).

FIG. 4illustrates an exemplary method400for use in relying on an IDP to implement enrollment of a user to a relying party (and for use in allowing subsequent access by the user to the relying party following such enrollment). The exemplary method400is described as implemented in (or through) the IDP102, the communication device108, and the relying party106, and other parts of system100. The method400is also described with reference to the computing device200. However, the methods herein should not be understood to be limited to the system100or the computing device200, as the methods may be implemented in other systems and/or computing devices. Likewise, the systems and the computing devices herein should not be understood to be limited to the exemplary method400.

At the outset in the method400, the user110elects to register with the IDP102directly through the IDP102via the interface112(rather than indirectly through the relying party106(as generally described above in the system100)). In doing so, the user110accesses the IDP102for registration, through the interface112. Consistent therewith, the user110selects a registration option at the interface112, as presented at the communication device108, which in turn, provides a registration request, at402, to the IDP102. In turn, the IDP102, via the interface112, solicits an agreement by the user110, at404, with certain terms and conditions associated with the digital identity service provided from the IDP102. In response, the user110agrees, whereby the communication device108, via the interface112, signals agreement to the terms and conditions, at406.

Next, at408, the IDP102solicits a new username and password from the user110for the registration. And, in response, the user110provides a username and password to the communication device108, at the interface112, which provides, at410, the username and the password to the IDP102. It should be appreciated that the IDP102may enforce certain rules for the username and password, such as, for example, no repeated usernames; a password having a certain number of letters, numbers and special characters; etc. When the username and password are acceptable (or otherwise accepted by the IDP102), the IDP102solicits, at412, various PII and account settings from the user110, via the interface112(including, in some examples, a reference biometric for the user110for use in subsequently authenticating the user110, etc.). The PII and setting may include those illustrated in the exemplary screen302ofFIG. 3, or more or less. When the user110provides the requested PII and settings, or portion thereof, through the communication device108, the communication device108provides, at414, the PII and settings (and reference biometric, when provided), from the user110, to the IDP102via the interface112. In some embodiments, when the user110provides the reference biometric, the communication device108may also store the reference biometric in memory associated therewith (in addition to, or in lieu of, sending it to the IDP102). In this way, the communication device108may subsequently use the reference biometric in connection with authenticating the user110(as described herein).

In connection therewith, as part of the communication of the agreement, the username and password, and/or the PII, the IDP102also captures, at416, a unique identifier associated with the user's communication device108(e.g., a MAC address, a MEID, a serial number, etc.). Then, at418, when the above data is received, the IDP102compiles a digital identity (or digital ID) for the user110and binds the communication device108, based on the unique identifier, to the digital identity. For instance, the unique identifier of the communication device108may be included in and/or identified (or linked) to the user's digital identity (e.g., in the data structure104, etc.), thereby permitting the communication device108to be a validation mechanism for an OTP or biometric authentication of the user110. As such, once the unique identifier of the communication device108is established at the IDP102, it can be used to ensure a higher degree of authenticity of any OTP or biometric data (or corresponding authentication confirmations) received from the communication device108(and that the communication device108from which the data is received is actually associated with the user110for which the data is directed). The IDP102then stores the digital identity in the ledger data structure104, as bound to the unique identifier of the user's communication device108.

It should be appreciated that in various embodiments, in connection with compiling and/or storing the digital identity for the user110, the IDP102may seek to validate the received PII, or parts thereof, based on images of documents solicited and/or received from the user110and/or via third parties. It should also be appreciated that such validation may be omitted in other embodiments.

At this point in the method400, the user110is registered with the IDP102and is able to rely on his/her digital identity at the IDP102to subsequently enroll to one or more relying parties, when desired.

That said, the user110may seek to enroll with the relying party106, whereby the user110accesses the interface116associated with the relying party106. In response, the relying party106, via the interface116, displays, at422, a login screen to the user110at the communication device108. The user110, in turn, selects to enroll to the relying party106with the IDP102, at424.

Upon receipt of the user's selection, the relying party106, and in particular the interface116, launches, at426, the SDK114. The relying party106(and in particular, the SDK114) solicits the username and password for the user110, at428. And, the user110responds by providing, at430, the user's username and password (as created when registering with the IDP102). In addition, the relying party106, via the SDK114, solicits, at432, from the user110, an identification of the class of PII to be shared with the relying party106(e.g., standard or enhanced, etc.) from the user's digital identity. The user110responds, at433, with a selected class (or potentially, relies on a default set by the user110during registration with the IDP102), whereby the communication device108selects/confirms the class of PII to share with the relying party106.

Next, at434, the relying party106, via the SDK114, passes the username, password and selection of the class of PII to the IDP102. In response, the IDP102validates, at436, the user110(based on the provided username and password, etc.). The IDP102then generates an OTP, at438, and transmits the OTP, at440, to the user's communication device108. Alternatively, upon validating the user110(again based on the provided username and password, etc.), the IDP102may instead transmits a direction to the user's communication device108to generate the OTP (where the communication device108is identified, for example, based on the unique identifier of the communication device108included in the user's digital identity or otherwise), whereby the communication device108(via the application118, for example) generates the OTP.

In any case, in response, the communication device108displays, at442, the OTP to the user110(e.g., via the application118, etc.) (whether it is received from the IDP102or generated by the communication device108). The user110is then able to retrieve the OTP and enter it into a screen displayed at the communication device108, by the relying party106(and, in particular, by the SDK114). The communication device108, in turn, transmits, at444, the OTP to the relying party106, via interaction between the SDK114and the interface116. In response, the relying party106, and in particular, the SDK114, provides the OTP to the IDP102, at446. And, at448, the IDP102validates the OTP received from the relying party106based on the OTP received from the communication device108(i.e., validates the user110when the OTPs match).

In other embodiments, upon validating the user110(again based on the provided username and password, etc.) (at436), the IDP102may transmits a direction to the user's communication device108to obtain a biometric for the user110(e.g., via the application118, etc.). In turn, the communication device108may request and receive the biometric from the user110and compare the biometric to a reference biometric for the user110stored in memory at the communication device108(e.g., as provided by the user110at the communication device108during registration to the IDP102, etc.). When the biometrics match, the communication device108may then transmit an authentication message/confirmation to the IDP102.

When the IDP102is unable to validate the OTP (or when the user's biometric is not validated or authenticated), the IDP102may transmit, at450(optionally, as indicated by the dotted line inFIG. 4), a validation failed notice to the relying party106, whereby the SDK114may seek a further authentication or validation attempt (e.g., via the IDP102whereby the IDP102may generate another OTP or request the user110to provide another biometric, etc.). Or, the IDP102may direct the user110to the interface116of the relying party106for conventional enrollment.

Thereafter in the method400, in any case where validation is successful (of the OTP or the user's biometric), the IDP102retrieves the digital identity for the user110from the ledger data structure104, retrieves the enrollment requirement file for the relying party106, and compiles, at452, an enrollment file for the relying party106. The enrollment file includes a username, a password, and PII (either standard or enhanced, as selected by the user110) for the user110, etc. The IDP102then encrypts, at454, the enrollment file and transmits, at456, the enrollment file to the relying party106. The relying party106in turn decrypts the enrollment file, at458, and enrolls the user110to the interface116, at460, whereby the user110is provided access thereto via the username and password included in the enrollment file (without the user110actually providing any PII directly to the relying party106in connection with enrolling with the relying party106).

With that said (and as further shown inFIG. 4), it should be appreciated that when the user110returns to the interface116of the relying party106after enrollment (at the communication device108), to login to the interface116to access his/her account with the relying party106, for example, the relying party106(via the interface116) may display, at462, a login screen to the user110. At the login screen, the user110may either use the username and password from his/her digital identity to access the interface116or the user110may rely on the IDP102to do so. Here, the user110selects, at464, to login to the interface116with the IDP102, at the login screen for the interface116, whereupon the SDK114is launched, at466, and a screen is displayed to the user110at the communication device108, which solicits an OTP from the user110. In connection therewith, the communication device108generates, at470, an OTP, where the OTP is then provided, at472, from the communication device108to the IDP102. The communication device108also displays at474, the OTP to the user110. The user110is then permitted to enter the OTP displayed at the communication device108to a screen associated with the relying party106soliciting the OTP, at the communication device108(or at another device associated with the user). The OTP is provided, at476, from the communication device108to the relying party106, or more specifically, to the SDK114, which in turn provides the received OTP, at478, to the IDP102. In response, the IDP102validates the received OTP, at480, and when validated, the IDP102transmits, at482, the username and the password for the user110(broadly, the user's login credentials) to the interface116, via the SDK114, at the relying party106, thereby logging the user110into the interface116, at484, without the user110actually presenting a username or password (or other login credential(s)) to the interface116(i.e., such that the login credentials are provided by the IDP102in lieu of being provided by the user110).

While the login aspect ofFIG. 4is presented with respect to the OTP, it should be appreciated that a biometric may be used in lieu of or in addition to the OTP, whereby the user110may be requested to provide a biometric at the communication device108. In turn, the communication device108may then provide the biometric to the IDP102and/or an authentication indicator to the IDP102(e.g., based on a biometric authentication of the user110at the communication device108, etc.). In response, the IDP102may validate the user110by comparison of the biometric received from the communication device108to a reference biometric, or based on receipt of the biometric indicator. In either case, the IDP102is permitted to proceed to share the login credential(s) with the relying party106.

Additionally, the user110may be permitted to access the interface112to manage the digital identity stored in the ledger data structure104, as desired. The management may be subject to the user110logging into the interface112with a login credential for the IDP102and/or an OTP process as described above.

FIG. 5illustrates a series of exemplary screens502,504, and506, which may be displayed to the user110, at the communication device108(or at another computing device associated with the user110), by the interface112at the IDP102in connection with managing the user's digital identity, etc. As shown, at the screen502, the user110is able to select from his/her various usernames and passwords included in the digital identity for accounts held by the user110at different merchants (broadly, relying parties). When the user110selects to update a username and/or password for an account (e.g., for an account at Merchant1, etc.), screen504is displayed to the user110at the interface112(via the user's communication device108or other computing device), whereupon the user110is permitted to enter a new username and password for the account. Then, when the user110selects to submit the desired changes (e.g., by the “Submit” button, etc.), the IDP102transmits the new username and/or password to the selected relying party (e.g., the Merchant1in this example, etc.). And, the relying party updates the username and password, if permitted, and confirms the update to the IDP102, which then indicates a successful update to the user110at one or more further screens in the interface112. If the update is not successful (e.g., based on rules imposed by the relying party (e.g., the new username is already being used, the new password is insufficient, etc.), etc.), though, the relying party will indicate the same to the IDP102, which, in turn, informs the user110of the error and permits a new username and/or password to be attempted.

Further, as shown inFIG. 5, the user110is permitted to cancel an enrollment with one or more relying parties at the screen502as well (e.g., any one of Merchants1-5, etc.). When the option to cancel is selected, the interface112displays screen506, which solicits a confirmation from the user110to cancel the enrollment. When the user110confirms, the IDP102transmits a cancellation command to the relying party, which in turn, cancels the account and/or enrollment of the user110with the selected relying party, and confirms the same to the IDP102. The cancellation generally includes the deletion of all PII related to the user110(in general or as received from the IDP102) for the given account.

Additionally, with reference toFIG. 6, the interface112may display the exemplary screens602and604to the user110(at the communication device108or at another computing device associated with the user110). The exemplary screen602, as part of the interface112, permits the user110to alter PII included in the user's digital identity (in general). Specifically, the user110may select to update a mobile phone number, upon which the exemplary screen604is displayed to the user110, via the interface112(e.g., at the communication device108or another computing device, etc.). In response, the user110is permitted to enter a new mobile phone number, and re-enter the new mobile phone number to confirm, and then select “Update” to commit the change in the mobile phone number of the digital identity. Upon selection and confirmation by the user110, the IDP102receives the selection, via the interface112, and compiles the digital identity to include the new mobile phone number (and deletes the prior mobile phone number) and stores the digital identity in the ledger data structure104.

Once the desired modifications are complete, the IDP102broadcasts the change(s) to the digital identity (e.g., the mobile phone number, etc.) to each relying party who has enrolled the user110through the IDP102(e.g., Merchants1-5, etc.). Consistent with the above description, each of the relying parties implements the change in the PII and confirms that the PII has been changed to the IDP102. The IDP102then confirms the change(s) as complete to the user110, via one or more screens of the interface112. If an error, for any reasons, occurs when trying to implement the change, the relying party notifies the IDP102, which in turn notifies the user110through one or more screens of the interface112.

As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one or more of the following operations: (a) receiving, by a computing device, a login credential for a user from a relying party in connection with enrolling the user to the relying party, the user associated with a digital identity stored in a data structure, the digital identity including personal identifying information (PII) of the user; (b) generating, by the computing device, a one-time-passcode (OTP) and transmitting the OTP to a communication device bound to the digital identity associated with the user, based on a unique identifier associated with the communication device; (c) receiving, at the computing device, an OTP from the relying party; (d) when the OTP generated by the computing device matches the OTP received from the relying party, compiling, by the computing device, an enrollment file for the user, the enrollment file including at least a portion of the PII of the user from the digital identity for the user; and (e) transmitting the enrollment file to the relying party, thereby permitting the relying party to enroll the user to an account without the user providing any PII directly to the relying party.

As will also be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one or more of the following operations: (a) receiving, by a computing device, a login credential for a user from a relying party in connection with enrolling the user to the relying party, the user associated with a digital identity stored in a data structure, the digital identity including personal identifying information (PII) of the user; (b) transmitting, by the computing device, a biometric authentication request for the user to a communication device bound to the digital identity associated with the user, based on a unique identifier associated with the communication device; (c) receiving, at the computing device, a biometric confirmation from the communication device indicating authentication of the user; (d) compiling, by the computing device, an enrollment file for the user in response to the biometric confirmation; (e) including, by the computing device, at least a portion of the PII of the user from the digital identity for the user to the enrollment file; and; and (f) transmitting the enrollment file to the relying party, thereby permitting the relying party to enroll the user to an account without the user providing any PII directly to the relying party.

As will also be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one or more of the following operations: (a) receiving, by a computing device associated with the IDP, a one-time-passcode (OTP) generated by a communication device bound to the digital identity associated with the user in connection with a login request by the user for the account at the relying party, the digital identity including a login credential specific to the relying party; (b) receiving, at the computing device, an OTP from the relying party; (c) comparing, by the computing device, the OTP generated by the communication device and the OTP received from the relying party; and (d) when the OTP generated by the communication device matches the OTP received from the relying party, transmitting, by the computing device, the login credential specific to the relying party from the digital identity of the user to the relying party, whereby the user is permitted to login to the account at the relying party by providing the OTP to the computing device but without providing the login credential to the relying party.