US-12621284-B2 - Systems and methods for user authentication using subject identifier and/or subject identifier documents

US12621284B2US 12621284 B2US12621284 B2US 12621284B2US-12621284-B2

Abstract

In some instances, a method is provided. The method comprises: generating a first subject identifier for the first domain, wherein the first subject identifier comprises a plurality of elements, wherein at least one of the plurality of elements comprises a subject identifier fragment indicating a unique identifier string for the user; based on a second user request to access second content for a second domain from the user device associated with the user, determining whether the user is enrolled into the subject identifier authentication; in response to determining that the user is enrolled into the subject identifier authentication for the first domain, generating a second subject identifier for the user for the second domain based on the subject identifier fragment from the first subject identifier for the first domain; and granting access to the second content for the second domain based on generating the second subject identifier.

Inventors

Abbie Barbir
Alan Bachmann
Erick Verry
Paul Ivanivsky
Cisa Kurian
Neal Shah
Michael Streuling

Assignees

AETNA INC.

Dates

Publication Date: 20260505
Application Date: 20240315

Claims (20)

1 . A system, comprising: a first back-end application system that is associated with a first domain and is configured to: receive a first content request for accessing content on the first domain from a user device associated with a user; and based on the first content request, provide a first identification request to an identity broker system; the identity broker system, wherein the identity broker system is configured to: based on receiving the first identification request, determine whether the user is enrolled in subject identifier authentication; and based on determining that the user is not enrolled in the subject identifier authentication, generate a first subject identifier for the first domain, wherein the first subject identifier comprises a plurality of elements, wherein at least one of the plurality of elements comprises a subject identifier fragment, wherein the subject identifier fragment indicates a unique identifier string for the user; and a second back-end application system that is associated with a second domain and is configured to: receive a second content request for accessing content on the second domain from the user device associated with the user; and based on the second content request, provide a second identification request to the identity broker system, and wherein the identity broker system is further configured to: based on receiving the second identification request, determine that the user is enrolled in the subject identifier authentication for the first domain; generate a second subject identifier for the user based on the subject identifier fragment from the first subject identifier for the first domain; generate a subject identifier document associated with the second subject identifier, wherein the second subject identifier resolves to a storage location for the subject identifier document; generate a public and private key pair for the second domain, wherein the public key of the public and private key pair is included within the subject identifier document; and grant access to the content on the second domain based on using the public and private key pair for the second domain.
2 . The system of claim 1 , wherein the first subject identifier is a first decentralized identifier (DID) and the second subject identifier is a second DID, wherein the plurality of elements of the first DID comprise a scheme element, a DID method element, and a namespace specific string, wherein a portion of the namespace specific string indicates the subject identifier fragment, and wherein the identity broker system is configured to generate the second DID by using the portion of the namespace specific string of the first DID that indicates the subject identifier fragment.
3 . The system of claim 1 , wherein the identity broker system is further configured to: subsequent to generating the first subject identifier for the first domain, provide, to the user device, an identity request for use in identity binding; receive, from the user device, user authentication enrollment information indicating one or more biometric features of the user; and perform the identity binding for the user by binding the user authentication enrollment information with the generated first subject identifier for the user, wherein determining that the user is enrolled in the subject identifier authentication for the first domain is based on the user authentication enrollment information being bound to the generated first subject identifier.
4 . The system of claim 3 , wherein the identity broker system is further configured to: provide, to the user device, a device request for use in device binding; receive, from the user device, device information associated with the user device; and perform the device binding for the user device by binding the device information with the generated first subject identifier for the user and the user authentication enrollment information, wherein determining that the user is enrolled in the subject identifier authentication for the first domain is based on the device information being bound to the generated first subject identifier.
5 . The system of claim 4 , wherein the identity broker system is configured to generate the second subject identifier for the user by: retrieving the generated first subject identifier that is bound to the user authentication enrollment information and the device information; and generating the second subject identifier by using the subject identifier fragment from the retrieved first subject identifier.
6 . The system of claim 5 , wherein the first subject identifier comprises an element, from the plurality of elements, indicating the subject identifier fragment and the first domain, and wherein the generated second subject identifier comprises an element indicating the subject identifier fragment and the second domain.
7 . The system of claim 1 , wherein the identity broker system is further configured to: based on a new content request for accessing the content on the second domain, determine that the user is enrolled in the subject identifier authentication for the second domain using the second subject identifier; and provide instructions to the second back-end application system to grant access to the content based on determining that the user is enrolled in the subject identifier authentication for the second domain.
8 . The system of claim 7 , wherein the identity broker system is configured to determine that the user is enrolled in the subject identifier authentication for the second domain using the second subject identifier by: based on an authentication request, obtaining authentication information from the user device; comparing the authentication information with user authentication enrollment information stored in a wallet system; and determining that the user is enrolled in the subject identifier authentication for the second domain based on the comparison and using the second subject identifier.
9 . The system of claim 7 , wherein the identity broker system is configured to determine that the user is enrolled in the subject identifier authentication for the second domain using the second subject identifier by: based on a device verification request, obtaining device information from the user device; comparing the device information from the user device with device information stored in a wallet system; and determining that the user is enrolled in the subject identifier authentication for the second domain based on the comparison and using the second subject identifier.
10 . The system of claim 7 , wherein the identity broker system is configured to determine that the user is enrolled in the subject identifier authentication for the second domain using the second subject identifier by: providing a challenge to the user device; receiving a signed challenge from the user device, wherein the user device signed the challenge using the private key of the public and private key pair for the second domain; resolving the second subject identifier to determine the storage location of the subject identifier document; retrieving the public key from the subject identifier document based on the determined storage location; and verifying that the user is enrolled in the subject identifier authentication based on using the public key from the subject identifier document and the signed challenge from the user device.
11 . The system of claim 1 , wherein the identity broker system is further configured to: bind the first subject identifier, the second subject identifier, and the subject identifier document together within a wallet system.
12 . A method, comprising: based on a first content request to access first content for a first domain from a user device associated with a user, generating a first subject identifier for the first domain, wherein the first subject identifier comprises a plurality of elements, wherein at least one of the plurality of elements comprises a subject identifier fragment indicating a unique identifier string for the user; based on a second user request to access second content for a second domain from the user device associated with the user, determining whether the user is enrolled into subject identifier authentication; in response to determining that the user is enrolled into the subject identifier authentication for the first domain, generating a second subject identifier for the user for the second domain based on the subject identifier fragment from the first subject identifier for the first domain; generating a subject identifier document associated with the second subject identifier, wherein the second subject identifier resolves to a storage location for the subject identifier document; generating a public and private key pair for the second domain, wherein the public key of the public and private key pair is included within the subject identifier document; and granting access to the second content for the second domain based on using the public and private key pair for the second domain.
13 . The method of claim 12 , wherein the first subject identifier is a first decentralized identifier (DID) and the second subject identifier is a second DID, wherein the plurality of elements of the first DID comprise a scheme element, a DID method element, and a namespace specific string, wherein a portion of the namespace specific string indicates the subject identifier fragment, and wherein generating the second subject identifier comprises generating the second DID using the portion of the namespace specific string of the first DID that indicates the subject identifier fragment.
14 . The method of claim 12 , further comprising: subsequent to generating the first subject identifier for the first domain, providing, to the user device, an identity request for use in identity binding; receiving, from the user device, user authentication enrollment information indicating one or more biometric features of the user; and performing the identity binding for the user by binding the user authentication enrollment information with the generated first subject identifier for the first domain, wherein determining whether the user is enrolled into the subject identifier authentication is based on the user authentication enrollment information being bound to the generated first subject identifier.
15 . The method of claim 14 , further comprising: providing, to the user device, a device request for use in device binding; receiving, from the user device, device information associated with the user device; and performing the device binding for the user device by binding the device information with the generated first subject identifier for the first domain and the user authentication enrollment information, wherein determining whether the user is enrolled into the subject identifier authentication is based on the device information being bound to the generated first subject identifier.
16 . The method of claim 15 , wherein generating the second subject identifier for the user comprises: retrieving the generated first subject identifier that is bound to the user authentication enrollment information and the device information; and generating the second subject identifier by using the subject identifier fragment from the retrieved first subject identifier.
17 . The method of claim 16 , wherein the first subject identifier comprises an element, from the plurality of elements, indicating the subject identifier fragment and the first domain, and wherein the generated second subject identifier comprises an element indicating the subject identifier fragment and the second domain.
18 . The method of claim 12 , further comprising: binding the first subject identifier, the second subject identifier, and the subject identifier document together within a wallet system.
19 . A non-transitory computer-readable medium having processor-executable instructions stored thereon, wherein the processor-executable instructions, when executed, facilitate: based on a first content request to access first content for a first domain from a user device associated with a user, generating a first subject identifier for the first domain, wherein the first subject identifier comprises a plurality of elements, wherein at least one of the plurality of elements comprises a subject identifier fragment indicating a unique identifier string for the user; based on a second user request to access second content for a second domain from the user device associated with the user, determining whether the user is enrolled into subject identifier authentication; in response to determining that the user is enrolled into the subject identifier authentication for the first domain, generating a second subject identifier for the user for the second domain based on the subject identifier fragment from the first subject identifier for the first domain; granting access to the second content for the second domain based on generating the second subject identifier; based on a new content request for accessing the second content on the second domain, providing a challenge to the user device; receiving a signed challenge from the user device, wherein the user device signed the challenge using a private key for the second domain; resolving the second subject identifier to determine a storage location of a subject identifier document, wherein the subject identifier document comprises a public key that is a key pair to the private key; retrieving the public key from the subject identifier document based on the determined storage location; verifying that the user is enrolled in the subject identifier authentication based on using the public key from the subject identifier document and the signed challenge from the user device; and granting access to the second content based on determining that the user is enrolled in the subject identifier authentication for the second domain.
20 . The non-transitory computer-readable medium of claim 19 , wherein the first subject identifier is a first decentralized identifier (DID) and the second subject identifier is a second DID, wherein the plurality of elements of the first DID comprise a scheme element, a DID method element, and a namespace specific string, wherein a portion of the namespace specific string indicates the subject identifier fragment, and wherein generating the second subject identifier comprises generating the second DID using the portion of the namespace specific string of the first DID that indicates the subject identifier fragment.

Description

BACKGROUND Relying parties may choose to use public/private key pairs as a way to enhance user protection to their resources. In this approach, the private key is bound to a specific user device and for a specific relying party domain. Therefore, each device may include a specific domain bound private key that is able to sign a challenge from the relying party to ensure that authentication is secure and immune from phishing attacks. Examples of such solutions include the original Fast Identity Online (FIDO) universal authentication framework (UAF) solution. An alternative to a device bound key is an approach that replicates and provides the initial private key to the cloud by either a platform provider or a PASSKEY provider. In this approach, the device bound key is validated on a cloud based on per key setup policies. This approach is less secure since it changes the device bound property of the key to a cloud bound approach. It also introduces the platform provider or the PASSKEY provider into the trust triangle by relying on their services for account recovery and key propagation to multiple devices. Further, this approach deprives the relying party from the right to control its own credential and for many regulated industries such as healthcare and financial industries, it fails to meet the key possession requirement that is required for sensitive data. Accordingly, there remains a technical need to ensure that unauthorized and/or unknown devices are properly verified by the relying party prior to obtaining sensitive information of the user. SUMMARY In some examples, the present application provides a method and system for user authentication using subject identifiers (e.g., decentralized identifiers (DID)) and/or subject identifier documents (e.g., decentralized identifier documents (DDO)). For example, the enterprise organization may own, manage, operate, and/or be otherwise associated with an enterprise cloud computing system. The enterprise cloud computing system may include and/or be associated with an identity broker system and a wallet system (e.g., a database that stores credential information for a plurality of users). The cloud computing system (e.g., the identity broker system) may generate one or more subject identifiers for the user based on the user device consenting to the subject identifier enrollment (e.g., DID enrollment). The identity broker generates a unique subject identifier that includes a subject identifier fragment (e.g., a DID fragment) that uniquely identifies the user within a domain. The subject identifier fragment may be generated as a result of performing an identity validation step that may include the validation of the user using official documents. The identity broker uses the subject identifier fragment as a part of the subject identifier when identifying the user. The cloud computing system may further generate one or more subject identifier documents for the user and store the subject identifier documents into the wallet system. The subject identifiers may be resolved (e.g., by the identity broker system and/or another system/device) to determine a location of the subject identifier documents. The subject identifier documents may include, but are not limited to, information associated with the public/private key pair for one or more domains. For example, the enterprise organization may include internal application back-end systems that manage one or more internal domains (e.g., one or more software applications that are managed or owned by the enterprise organization). The subject identifier documents may include information associated with the public/private key pair for the one or more domains. Based on the subject identifier, the user device may determine the location of the subject identifier documents within the cloud computing system and may use this to access the private and/or public keys for the one or more internal domains. As such, using the subject identifier and the subject identifier documents that are managed by the enterprise cloud computing system and not the platform provider system, the user device may gain access to the content (e.g., sensitive information such as medical records of the user) for the internal domains (e.g., domains managed by the enterprise cloud computing system). Additionally, and/or alternatively, the cloud computing system may use the subject identifiers for secure pass key authentication (e.g., secure pass token authentication) as well as for subject identifier authentication (e.g., DID authentication). For example, similar to the cryptography behind the public/private key pairs, a secure pass key (e.g., a secure pass token) is a credential (e.g., a FIDO credential) that does not require nor use a password. Instead, secure pass keys use an authentication method to identify and grant access to content for an authorized user. The secure pass key may be a cryptographically generated strong key that may be used as an alternative