Patent Application
20200092281
Virtual Private Networks (VPNs) are a common means of establishing trust and user identity within corporate networks. The application of VPNs to mobile devices has made it possible for enterprises to get the same level of trust from mobile devices. However, many enterprise productivity applications reside outside conventional enterprise network boundaries, in cloud-based services. There is therefore a need to be able to access these services securely too, without having to establish their user identity individually with each service (most commonly by entering passwords to login to each such service).
VPNs typically establish user identity through the use of a pre-established secure credential on the user's device that is unlocked by the user entering a password or PIN, or more recently through biometrics, such as using the device to read a fingerprint. Such credentials are commonly in the form of PKI keys and certificates provisioned on the devices with the help of an Enterprise Mobility Management (EMM) solution (also known as a Unified Endpoint Management UEM). Pre-established secure credentials such as passwords typically vary from application to application, and can be cumbersome and difficult to manage especially if a user needs to memorize many passwords.
Users can use their smartphone/mobile device as a physical access device. For example, a service provider provides a mobile application that is installed on the user's physical access device. The mobile application receives a push notification asking the user to verify their identity. The user's physical access device prompts the user to unlock the phone (e.g., enter a password, provide a biometric to a Touch ID® fingerprint sensor, etc.) and approve or deny the request. However, some service providers may have more stringent requirements, and this type of process does not meet their security or privacy standards. For example, a user could install the mobile application on any physical device including those without adequate security controls (e.g., a spouse's device or home mobile device). This means that the user's identity can be verified by anyone in possession of the device. Someone who is not the user is able to unlock the physical device and approve the request even if they are not the user.
In addition, multi-factor use cases are evolving such that asking a user for a password may be considered cumbersome and unnecessary if a physical device can assert the user's identity. Users tends to forget passwords (especially if they are managing many different passwords for different devices), and this reduces their productivity and causes them to take insecure routes to gain access to resources and become productive again.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
Asserting a mobile device-associated identity in an enterprise authentication system to access a resource from a device other than the mobile device is disclosed. More specifically, the mobile identity includes a unique identity. The unique identity is sometimes called a “unique device-associated user identity,” or “mobile identity” herein. Techniques to provide secure access to on-premises and/or cloud-based enterprise resources via the unique identity as disclosed herein are described. In various embodiments, the unique identity is established via a mobile device that is under management (e.g., registered with/via) an Enterprise Mobile Management (EMM) solution. The unique identity is used to authenticate a user to access enterprise resources via one or more other devices, including in various embodiments one or more devices that are not under management. First, an enterprise authentication system and process is described (
In the example shown, VPN security (such as that offered by MobileIron® Tunnel) is leveraged to establish trust and/or user identity for purposes of user authentication to distributed cloud-based services. In various embodiments, the request to access such a service may be associated with a non-VPN device. In various embodiments, cloud-based services may use various security protocols, such as federated identity standard protocols, e.g. SAML or OAuth. In some embodiments, a mechanism is provided to provide VPN-based authentication to authenticate users in the event a direct VPN connection is not available, e.g., with respect to a device from which access is requested. In some embodiments, the public-key infrastructure (PKI) and the Enterprise Mobility Management (EMM) service that together form the basis of the VPN security may be modified and leveraged to establish authentication to cloud-based services. In some embodiments, certificates associated with VPN may be modified, and/or enterprise directory information may be leveraged in conjunction with such certificates, in order to establish the user's identity with cloud-services.
Most of the cloud-services of interest to enterprise customers support the federated identity standard SAML. Many services also support another federated identity standard—OAuth. When using SAML, cloud-services typically determine the identity provider (i.e. the entity asserting the identity of the user) based on the user's identity, which is based on attributes obtained from the session like a stored cookie. The user's identity can be determined from (e.g., associated with) a user-provided unique identifier as further described below. In various embodiments, an identity provider may use VPN-based authentication to authenticate a user regardless of whether a device via which a request to access a cloud-based service is made is connected via a VPN.
In the example shown, device(s) (managed device 102 or unmanaged device 110) may be used to securely access services, such as enterprise applications, via security proxy 106. For example, security proxy 106 (such as MobileIron® Sentry®) may comprise a secure tunnel 112 or other certificate-based connection. An unmanaged device (device 110) may provide a unique identity (e.g., entered by a user seeking access) to securely access services, such as enterprise applications, via security proxy 106 as further described below. A certificate (identity certificate) may be provisioned on managed devices (device 102), e.g., at device registration. For example, an Enterprise Mobility Management (EMM) server 114 (such as MobileIron® Core or Cloud) may provision the certificate on the device 102. The EMM server may maintain device security posture information, e.g., jail broken or not, unauthorized app installed, etc., and may provide such posture information to the security proxy. One or more agents (secure, EMM-managed apps such as authenticator app 116) on the device 102 may act as agents to provide information relevant to security posture of the device 102, to take action on device 102 in response to a detected security breach, and/or to establish and maintain a secure VPN connection.
In various embodiments a unique identity may be used to authenticate a user to a cloud service, even if the request originates from a device 110 not connected to the VPN (e.g., not managed by EMM 114). In the example shown, device(s) 110 not connected to the security proxy 106, e.g., legacy Windows® operating system based personal computers, unmanaged mobile or other unmanaged devices, etc., may be used to request access to a cloud service 104. In various embodiments, the cloud service 104 may redirect the requesting application to identity provider 108 associated with security proxy 106. In various embodiments, identity provider 108 may use one or more techniques potentially involving security proxy 106 to authenticate the user to the cloud service 104. The techniques described here find application to alternatives to cloud service 104 such as applications that can embed calls to the security proxy 106 to invoke authenticator app 116 (and receive an allow/deny response).
For example, in some embodiments, another device associated with the requesting user and also included among devices 102 associated with security proxy 106 may be used to authenticate the user. For example, in some embodiments, a push notification may be sent by the identity provider 108 to a VPN-connected device 102 associated with the same user. A unique identity associated with the request via a non-VPN device 110 may be mapped to a device 102 on the VPN. Alternatively, the identity provider 108 may prompt the user for such identifying information (a unique identity) that is used to uniquely identify the device 102 for that user. Upon identifying the device 102 for the user, the identity provider 108 may send a push notification to that device. When the user connects via their device 102, a verified identity of the user established via and/or in connection with the security proxy 106 may be used to generate an assertion to authenticate the user to the cloud service 104 to enable access to the cloud service 104 via the non-VPN device 110.
In the example shown in
In various embodiments, the unique identity can be used in conjunction with one or more techniques to authenticate a user in connection with a request from a non-VPN connected device (e.g., devices 110 of
Inline Authentication Using Certificates.
In enterprise environments, PKI certificates and keys may be deployed to devices that may not always be VPN connected. In some embodiments, when a user from a device that is not connected to the VPN but which has been provisioned with an employee PKI key and certificate presents an authentication request to the VPN associated identity provider, the identity provider challenges the user to present proof-of possession of the key corresponding to their employee certificate. This may be done using standard protocols such as TLS with client-authentication. If the user is able to present this proof, then the user is considered to be authenticated, and the identity provider generates an identity assertion to the cloud-based service provider based on this information. The unique identity can be used to look up an associated a certificate or key.
Inline Authentication Using Techniques Other than Certificates.
In some embodiments, the VPN associated identity provider may challenge the user to enter a unique identity that can be verified against an enterprise data source (such as the enterprise employee directory, e.g., Active Directory®) to establish the identity of the user. Some enterprises may configure this to be multi-factor authentication, but in such cases, the identity provider in various embodiments will be able to verify the information presented by the user directly against a source of authentic information from the enterprise.
Enterprise Identity Provider Authentication.
In some embodiments, the VPN associated identity provider may act as a federation proxy. When it receives an authentication request from a cloud-service provider, it generates a new authentication request to the enterprise identity provider and redirects the user to it. The enterprise identity provider may employ any secure technique to establish the user's identity by checking the unique identity. If the unique identity is authenticated, the enterprise identity provider generates an identity assertion that it presents to the federated identity provider by redirecting the user's app. The federated identity provider then generates a new assertion based on the information obtained from the identity assertion generated by the enterprise identity provider.
Push Notification Based Authentication.
In some embodiments, push notification based authentication, e.g., as described above, may require a client app to be installed on the user's mobile device or other VPN connected device. In some embodiments, the required client app may be obtained by mobile devices through their employer's EMM server and/or enterprise app store. Alternatively, the functionality may be bundled with other device management client apps such as a mobile device management (MDM) agent or app.
Referring further to
In the example shown, device(s) (managed device 102) may be used to securely access services, such as enterprise applications, via security proxy 106. For example, security proxy 106 (such as a Mobilelron® Sentry®) may comprise a secure tunnel 112 or other certificate-based connection. A certificate may be provisioned on the device 102, e.g., at device registration. For example, an Enterprise Mobility Management (EMM) server 114 may provision the certificate on the device 102. The EMM server may maintain device security posture information, e.g., jail broken or not, unauthorized app installed, etc., and may provide such posture information to the security proxy. One or more agents (secure, EMM-managed apps such as authenticator app 116) on the device 102 may act as agents to provide information relevant to security posture of the device 102, to take action on device 102 in response to a detected security breach, and/or to establish and maintain a secure VPN connection.
In various embodiments, device(s) 102 connected via secure tunnel 112 may be used to access cloud services 104. The connection to the cloud services 104 may or may not be through the security proxy 106. Cloud services 104 may be configured to redirect access requests to an identity provider 108. Device 102 once redirected may communicate with identity provider (IdP) 108 via security proxy 106 to obtain an assertion or other credential to present to the cloud service 104. In various embodiments, a certificate or other credential associated with the device 102's connection via VPN 106 may be used by the identity provider (IDP) 108 to establish the user identity associated with request, and to construct an assertion to authenticate the user to the cloud service 104. In some embodiments, a security posture check may be performed, and the redirected authentication request may be denied or not forwarded based at least in part on security posture information indicating the device 102 is not in a secure posture. The user identity certificate used to secure the secure tunnel 112 has various attributes that describe the user, such as the user's email address, or employee id. In addition, information may be obtained from systems like EMM or other services (like Active Directory or Cloud Service), or a constant value common to a group of users such as company affiliation, usage license, role etc. The IdP provides a flexible way in which customers can specify rules to transform such user identifying information into information that specific cloud service providers expect in federated identity messages in order to uniquely identify the user of that cloud service. Such transformations may include selecting one or more fields, encoding and decoding them in various formats
In the example shown in
Managed device 102 and unmanaged device 110 can each include one or more processing devices. By way of non-limiting example, devices include smartphones, mobile devices, tablets, and desktop computers. Applications can be installed on these devices. An authenticator app, which is managed by EMM 114 can be installed on managed device 102.
In various embodiments, one or more of the above described authentication techniques may be combined with a workflow to require an approval from a third party (e.g., supervisor or other authority).
When a user using an unmanaged device 110 visits a service provider 104, the service provider redirects the user to the security proxy. The redirection corresponds to a request to authenticate a user. In various embodiments, the service provider is already federated to the security proxy (e.g., Mobilelron® Access®) for user authentication by an enterprise administrator. For example, if an authenticator app is used in an authentication process, the authenticator app is trusted only if communications between the app and the security proxy is through secure tunnel 112. For example, a user opens a browser in an unmanaged device (e.g., device 110) and navigates to a cloud service provider website (such as www.serviceproviderA.com). Referring to
Returning to
In the example shown in
The process determines, based on the unique identity, an identity certificate associated with the request (204). The identity certificate is used to secure a tunnel and has various attributes that describe the user. At the time the unique identity was created, it was associated with an identity certificate. The process looks up the mapping of the unique identity to the identity certificate. In some embodiments, the process performs one or more authentication or security procedures (further described with respect to
The process generates an identity assertion based on the identity certificate (206). The identity assertion can be generated from one or more attributes obtained from a certificate presented by a secure tunnel 112 when a managed device 102 communicates with a security proxy 106. The identity assertion can be transmitted between the unmanaged device 110 and service provider 104 to authenticate the unmanaged device to access the service provider's resources in a way transparent to the user. Put another way, the unmanaged device automatically presents the identity assertion to the service provider to obtain access to the service provider's resources without needing user input beyond presenting the unique identity.
The process provides the identity assertion to a requesting node with which the request to authenticate is associated (208). If the identity assertion is recognized by the requesting node (service provider 104), then the service provider grants access. Otherwise, if the identity assertion is not recognized, then no access is provided.
The process begins by presenting an interaction page on an unmanaged device to receive a unique device-associated user identity (302). The interaction page can be provided inside a browser to query a user to enter a unique identity. Referring to
The interaction page may be implemented in various ways based on enterprise policies and administrator configurations. In some embodiments, the interaction page includes a form asking the user to enter a string representing the unique identity. The string can be any of the public or private strings chosen at the time the unique identity was established. In some embodiments, the interaction page includes a widget that guides the user to input biometric data. For example, a user uses a camera to input a unique identity such as a FaceID® or uses a sensor to input a fingerprint. In some embodiments, the interaction page includes directions for a user to scan a scannable code (e.g., QR code) using an authenticator app on a managed app (e.g., app 116 of
The process receives the unique identity (304). The unique identity is input to an input field in the interaction page presented at 302. Referring to
The process determines whether to apply additional security measures such as a one-time password (OTP) (306). A policy (such as one defined by an administrator) can define whether additional security measures are applied. For example, an administrator can define a rule that processes unique identities after first applying a security layer such as receiving and verifying a one-time password. The additional security measures may vary from user to user or group to group. Unrecognized IP addresses or origins may be subject to heighted security measures compared with familiar IP addresses. If additional security measures are not to be applied, the process proceeds to A (314).
Otherwise, if additional security measures are to be applied, the process sends a verification code (e.g., an OTP) to a managed device (308). For example, the OTP can be sent to the device by a system performing the process (e.g., security proxy). Alternatively, the process generates a verification code on the managed device. For example, the OTP is generated on the device based on a secret shared during a registration process such as by a time-based one-time password (TOTP) algorithm. The managed device is a previously registered device managed by an EMM and associated with the unique identity. The process generates a verification code or looks-up a verification code from a list of previously-generated codes and sends this code to the managed device. Then, the user inputs the verification code in the unmanaged device (e.g., in a browser or the interaction page described earlier) to be sent to the process to verify the user's identity.
Referring to
After receiving the verification code from the unmanaged device, the process determines whether the verification code is correct (312). The process determines whether the user-provided verification code matches the verification code that the process sent to the managed device earlier. If there is a match, then the verification code is correct. In some embodiments, the verification code expires after some time. The user can generate a new verification code in the authenticator app. Referring to authenticator app 430 of
If the verification code is incorrect, the process simply ends in some embodiments. In some embodiments, a user may re-attempt to verify. For example, the user can generate a new verification code in the authenticator app as described above (return to 308). Otherwise, if the verification code is correct at 312, the security measures that began at 306 are successfully complete, and the process proceeds to A (314).
The process maps the unique identity to the device that established the unique identity (314). The unique identity may be received in variety of ways as described earlier with respect to 304. In various embodiments, a unique identity is received from the unmanaged device. More specifically, a browser/interaction page communicates the unique identity to the process (security proxy). Referring to interaction page 420, the input of the unique identity (a string here, but may be other data such as biometric data), is transmitted by the interaction page to the process. In various embodiments, the unique identity is received from an authenticator app on a managed device. Referring to authenticator app 460, a QR code (which identifies a login session on an unmanaged device) is transmitted by the authenticator app to the system implementing the process of
The process looks up the unique identity, and maps the unique identity to the device that established the unique identity. The process may retrieve stored mappings of unique identities to managed devices. A mapping can be stored at the time a managed device creates a unique identity. A process for establishing a unique identity is further described in
The process sends a push notification (of the authentication request) to the managed device (316). Referring to
The process determines whether the authentication request is approved (318). If the authentication request is not approved, the process may simply end or a user can request a subsequent push notification to be sent, e.g., if a request was accidentally denied. In some embodiments, the push notification expires after a pre-determined time so that if a user does not approve (or deny) a request within the pre-determined time, the request is considered denied.
Otherwise, if the authentication request is approved, the process matches an identity certificate to the unique identity (320). The identity certificate is a certificate presented by a secure tunnel in association with communications transmitted through the tunnel. Referring to
The process determines whether the identity certificate matches the unique identity (322). If the identity certificate does not match the unique identity, the process may end in some embodiments. In some embodiments, a user may re-attempt to verify for example by returning to 302 to re-enter or provide another unique identity.
Otherwise if the identity certificate matches the unique identity, the process generates an identity assertion (324). If the identity certificate matches the unique identity, then the process generates an identity assertion for the browser/interaction page of the unmanaged device 110 to authenticate itself with the service provider 104 (www.serviceproviderA.com). In various embodiments, the process generates the identity assertion by selecting attributes from the certificate such as a user principal name (UPN), email ID, user ID, common name (CN), employee ID, and the like. In various embodiments, the process redirects the browser/interaction page back to the service provider and the user logs in with the generated identity assertion by presenting the identity assertion. The presentation of the identity assertion may take place in the back end without requiring the user to enter any additional information. If the identity certificate does not match the unique identity, the process ends.
The following figure shows an example of how a unique identity can be established.
Process 500 can be performed in a system such as the one shown in
Process 500 begins by prompting a user to establish a unique device-associated user identity (502). The process may prompt the user in response to events such as the user opening the authenticator app (e.g., app 116) for the first time. If the user previously skipped or declined to set up the unique identity, the process may periodically remind the user to establish the unique identity. In various embodiments, the user may request to establish the unique identity. Process 500 may instruct the authenticator app to present a user interface page with visual reminders that draw the user's attention to the concept of a unique identity. For example, words/phrases and/or an icon or logo draws the user's attention to the use of a unique identity. Referring to
Processor 500 receives (or creates) the unique device-associated user identity (504). The unique identity can be various formats/types or a combination of formats/types. By way of non-limiting example, unique identities can include one or more of the following: a user's public information, a private secret selected by the user, a random string, a scannable code, biometric information, and a one-time password. The unique identity can be selected by a user or generated for the user (e.g., by a security proxy or authenticator app). A user's public information has the advantage of being easily remembered by the user, but may be relatively unsafe compared with the other examples because it can be easily guessed. Examples of public information include a phone number, email address, an employee ID, and a user ID. An example of a private secret selected by the user is a string such as one that is easy for the user to remember but hard for others to guess. Process 500 can verify that the private secret complies with a policy set by the enterprise or administrator as further described below. An example of a random string is a string that is generated by security proxy 106 or authenticator app 116. This has the advantage of being more secure than a user-selected private secret if the user is not good at selecting secure strings. An example of a scannable code is a QR code, which can be a unique code generated by the security proxy 106 or authenticator app 116 for a specific user or user and device combination. The authenticator app 116 may be configured to store the private secret, random string, or scannable code for the user to recall as needed. Examples of biometric information includes a thumb print or face print. Biometric information has the advantage of being harder to forge/guess. However, not all devices used by the user may support input of biometric information. For example, devices that do not have fingerprint sensors or cameras would not be able to be used to accept or transmit the unique identity. An OTP can be generated by an authenticator app, and may be used in conjunction with other types of unique identities such as a user's public information.
Process 500 verifies that the unique device-associated user identity complies with policies (506). In some embodiments, an enterprise or administrator can define a policy/standard to govern permitted unique identifiers. For example, for user-selected private secrets, the process may check that the string is not easily guessed, does not include public information, unique for the enterprise, or the like.
Process 500 associates the unique device-associated user identity with the user's one or more managed devices (508). Referring to
Process 500 associates the unique device-associated user identity with the user's identity certificate (510). The user's identity certificate is the user's identity for the enterprise, e.g., a certificate that is presented by a device to obtain access to enterprise resources (access to cloud services 104). As described above, an identity certificate is used to secure the secure tunnel 112 and has various attributes that describe the user, such as the user's email address, or employee ID. The unique identity is associated with the identity certificate so that when a user presents a unique identity, the matching identity certificate found, and the identity certificate is presented to the service provider on behalf of the user to access the service provider.
In various embodiments, to prevent leaking of information about a user's unique identity, during the process 500 to establish the unique identity, communications are made only through a mutually authenticated secure channel established by the secure tunnel 112. This prevents a malicious user from using the application to guess the secure unique identity of other users in the company.
In various embodiments, when a user enters a unique identity, the unique identity protected. In the process 500 of establishing the unique identity, the unique identity is protected within the container of the authenticator app. In the process 200 of providing a unique identity to obtain access to enterprise resources, the unique identity is protected within the container of the browser/interaction page. This ensures that the unique identity is not exposed to the cloud service 104. The unique identity can be protected by a variety of security techniques including applying a secure hashing algorithm on top of the unique identity after it is entered (whether in registration phase 500 or authentication phase 200).
Techniques for asserting a mobile device-associated in an enterprise authentication system to access a resource from a device other than the mobile device is disclosed. In various embodiments, these techniques are transparent to the end user in determining the device posture to control access for public mobile apps to corporate resources in cloud or on-premises. Unlike conventional methods that use an OTP to establish a user's identity and stores a cookie in the browser to enable easy login for the next few days without needing to validate the user, the unique identity is more securely established and authenticated and does not need to be refreshed frequently. Unlike conventional single sign on techniques that grant access to resources when a username and password is input to a variety of platforms, the unique identity disclosed here has been authenticated in a more secure manner. In one aspect, the unique identity is more securely established and authenticated because the process involves an enterprise mobile management server. In another aspect, the unique identity is linked to an identity certificate. The unique identity does not require a username and password combination and can be easier to remember or use. In particular, unlike conventional single sign on, the unique identity is used in various embodiments to look up an identity certificate and generate an identity assertion. Unlike conventional apps that use QR codes to connect users by linking a browser to a session, the scannable code described here links a browser on an unmanaged device to a managed device. These techniques improve security and usability by having users verify user identity remotely on a high secure endpoint using a unique identity.
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
This application is a continuation of co-pending U.S. patent application Ser. No. 16/257,654 entitled ASSERTING A MOBILE IDENTITY TO USERS AND DEVICES IN AN ENTERPRISE AUTHENTICATION SYSTEM filed Jan. 25, 2019, which claims priority to U.S. Provisional Patent Application No. 62/622,715 entitled ASSERTING A MOBILE FIRST IDENTITY TO USERS AND DEVICES IN AN ENTERPRISE AUTHENTICATION SYSTEM filed Jan. 26, 2018. This application is a continuation of co-pending U.S. patent application Ser. No. 16/257,654 entitled ASSERTING A MOBILE IDENTITY TO USERS AND DEVICES IN AN ENTERPRISE AUTHENTICATION SYSTEM filed Jan. 25, 2019, which is a continuation-in-part of U.S. patent application Ser. No. 15/595,648 entitled UNIFIED VPN AND IDENTITY BASED AUTHENTICATION TO CLOUD-BASED SERVICES filed May 15, 2017, which claims the benefit of U.S. Provisional Patent Application No. 62/336,451 entitled UNIFIED VPN AND IDENTITY BASED AUTHENTICATION TO CLOUD-BASED SERVICES filed May 13, 2016. The above-mentioned applications are incorporated herein by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 62622715 | Jan 2018 | US | |
| 62336451 | May 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16257654 | Jan 2019 | US |
| Child | 16688668 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15595648 | May 2017 | US |
| Child | 16257654 | US |
