Anonymous authentication with token redemption

Abstract

This disclosure relates to a method for anonymity verification, the method comprising: receiving, by an application running on a client device, an authentication request from a first content provider to authenticate a user to receive content from a second domain of a second content provider; redeeming an anonymous proof token by transmitting the anonymous proof token along with the second request using a proof token issuance system that issues an anonymous proof token certifying the user's authentication to the second content provider; receiving a redemption result indicating whether the proof token was successfully redeemed, the redemption result being digitally signed by the proof token issuance system and operable for verifying that the user has been authenticated to the second content provider without identifying the user to the second content provider; and transmitting the redemption result to the first content provider.

Description

Background Technology

[0001] Client devices transmit requests and other data over public networks such as the Internet. These communications can be altered by other parties, such as parties that intercept communications and / or intermediaries that receive communications and forward them to other parties.

[0002] Other parties can simulate a client device to send requests that appear to originate from the client device but actually come from other parties' devices.

[0003] Various authentication technologies can be used to verify the identity of client devices attempting to conduct transactions over public networks. However, these technologies can also raise privacy concerns. For example, users of client devices may not want to share information that could be used to track client devices or the users of those devices (such as stable device identifiers), and data providers can operate under privacy-preserving standards that prevent them from receiving or processing such information. Summary of the Invention

[0004] This specification describes authentication techniques for verifying the integrity / authenticity of client devices while avoiding the use of stable device identifiers that can be used to track client devices or their users.

[0005] Typically, the first innovative aspect of the subject matter described in this specification can be embodied in a method for anonymity authentication, the method comprising: receiving, by an application running on a client device, an authentication request from a first server hosted on a first domain of a first content provider to authenticate a user to receive content from a second domain of a second content provider different from the first content provider; in response to receiving the authentication request, redeeming an anonymous authentication token by the application using a authentication token issuing system that issues an anonymous authentication token certifying the user's authentication to the second content provider by transmitting the anonymous authentication token along with a second request; in response to the second request, receiving from the authentication token issuing system a redemption result indicating whether the authentication token has been successfully redeemed and signed by the authentication token issuing system using a digital signature, wherein the redemption result is operable for verifying that the user has been authenticated to the second content provider without identifying the user to the second content provider; and transmitting the redemption result signed by the authentication token issuing system to the first content provider.

[0006] In some implementations, the redemption result can be used to verify to the recipient that the user has been authenticated against the second content provider, without having to provide the user's credential set to the first content provider.

[0007] In some implementations, the second content provider is a news provider, the first content provider is a news aggregator domain, and the redemption result signed by the proof token issuance system and transmitted by the application to the first content provider is performed in response to a user action requesting access to resources hosted by the news provider.

[0008] In some implementations, the second content provider is a media hosting platform, the first content provider is a social media platform, and the redemption result signed by the proof token issuance system and transmitted by the application to the first content provider is executed in response to a user action requesting access to resources hosted by the media hosting platform.

[0009] In some implementations, the method includes: an application on a client device sending a first request for an anonymous proof token certifying the user's authentication against a second content provider to a trusted procedure capable of accessing the credentials of the user of the client device; the trusted procedure sending a third request for the anonymous proof token to a proof token issuing system, the third request including a set of credentials of the user of the client device; and the application receiving the anonymous proof token from the proof token issuing system, the anonymous proof token including (i) a proof token creation timestamp indicating the creation time of the anonymous proof token, and (ii) a second digital signature of the proof token issuing system.

[0010] In some implementations, the method includes an application requesting content from a second content provider via an electronic resource of a first content provider.

[0011] In some implementations, the method includes the application receiving content from a second content provider.

[0012] In some implementations, it is proven that the digital signature of the token issuance system is created based on a blind signature scheme.

[0013] In some implementations, the digital signature of the proof token issuance system is created using a group signature scheme and an anonymous certificate issued to the client device, and the method includes storing the anonymous certificate in a secure private keystore on the client device.

[0014] In some implementations, transmitting the redemption result signed by the proof token issuance system further includes providing (i) additional data signed by the application and (ii) that does not associate the user with the credential set.

[0015] In some implementations, the request indicates the number of proof tokens to be issued.

[0016] In some implementations, the request is signed using a third digital signature with a private key maintained by the application, and the third digital signature can be verified using (i) a public key corresponding to the private key and (ii) a public key issued by the application.

[0017] In some implementations, the second digital signature is created using a private key maintained by the proof token issuing system, and the third digital signature can be verified using (i) a public key corresponding to the private key and (ii) a public key issued by the proof token issuing system.

[0018] In some implementations, the redemption result includes a single bit indicating whether the proof token was successfully redeemed.

[0019] Other embodiments of this aspect include corresponding systems, apparatuses, and computer programs encoded on computer storage devices, which are configured to perform the actions of the method.

[0020] The subject matter described herein can be implemented in specific embodiments to achieve one or more of the following advantages.

[0021] Using authentication tokens to authenticate client devices or users provides a secure communication channel between client devices and the computers or other devices of other entities. The digital signature of the data contained in the authentication token, included along with the token itself, enables entities to verify that the data in the authentication token has not been altered since the token was created. Additionally, including the token creation time in the authentication token allows the recipient to determine whether the request is new or part of a scheme to fraudulently use the identity of an authorized device to perform an operation by a third party.

[0022] For example, a proof token can be used to identify that a client device is authorized to access a resource without identifying the client device for that resource, thereby allowing the party maintaining the resource to be certain that the client device is a legitimate authorized user and allowing the client device to maintain its anonymity with respect to that resource.

[0023] The authentication token system provides the ability to authenticate devices and / or users across different websites within the same platform and across different platforms without sharing personally identifiable information (PII) with the websites or platforms. For example, an authentication token system allows a user to access resources and content from third-party content aggregation platforms and websites that require authentication, without providing their PII to those platforms or providers. The authentication token system is privacy-preserving, enforcing boundaries between different websites and platforms and providing convenient, seamless access to resources and content. Instead of providing a PII such as a username and password to a third-party content aggregation platform to access resources, the client device is able to provide a redemption result authenticating the client device to the third-party content aggregation platform, granting the user access to the resources. Therefore, the third-party content aggregation platform does not receive the user's usual PII for accessing resources (e.g., the username and password the user would use to directly access resources), and the resource publisher cannot determine that the user is accessing the resource through the third-party content aggregation platform. This protects the user's privacy regarding their PII used for resources and also protects the user's privacy when using the third-party content aggregation platform.

[0024] Proof token systems improve user experience by removing sources of friction. For example, proof tokens can be used to allow users to access restricted resources without requiring them to provide additional authentication information.

[0025] The proof token can also include a device integrity decision indicative of the integrity of the client device that transmitted the proof token. This allows the recipient of the proof token to verify that the data originated from a trusted client device, for example, and not from an emulator or compromised device. The device integrity decision can be generated and digitally signed by a trusted device analyzer (e.g., a third-party device analyzer), enabling the recipient of the proof token to verify that the client device was evaluated by the trusted device analyzer and that the data in the device integrity decision has not been modified since its creation by the trusted device analyzer.

[0026] While proof tokens protect the integrity of communications transmitted from client devices, there are potential privacy issues associated with their use. A primary privacy issue is that reusing the same proof token across multiple interactions with a content publisher or platform can potentially allow the proof token recipient to correlate multiple requests transmitted from the same client device and aggregate user data based on these correlations. The techniques described in this document enhance privacy against such correlations by using multiple proof tokens, each including a unique public key of the client device. For example, a client device can generate a batch of N public / private key pairs and then send these N public keys to a third-party device analyzer to receive a batch of N corresponding proof tokens. The client device can then, for example, use a new proof token for each request; or the client device can use the same proof token for all requests within a certain time interval; or the client device can use the same proof token for all requests originating from the same application on the client device; or some combination thereof. Limiting the use of each public key limits the number of requests a recipient can correlate based on the public key and increases the amount of confidence an application server has when consuming redemption records. For example, an application server can determine that the older the token, the greater the likelihood that the client has unintentionally exposed the token to malware. Using this batching method also reduces the burden on the device analyzer by having fewer requests to process, reduces network bandwidth consumption, and reduces latency at the client device when transmitting requests that will include a proof token, which would introduce latency if the client device sent a request for a proof token every time it was needed.

[0027] The second privacy issue is that sharing a client device's stable public key with a device analyzer can potentially allow the analyzer to track the client device. For example, if multiple distinct recipients of proof tokens can know which proof tokens the device analyzer received in the same batch of requests from the same device, then these token recipients can correlate multiple requests transmitted by the same client device and aggregate user data based on this correlation. Recipients would need to collude with or corrupt the device analyzer's data storage to obtain such data. The techniques described in this document enhance privacy against such tracking by sending a blinded version of the public key to the device analyzer instead of the original value. For example, a client device can generate a batch of N public-private key pairs, blind the N public keys (or cryptographic hashes of the public keys), and then send the N blinded keys to the device analyzer; the third-party device analyzer returns a batch of N corresponding blinded signatures, never receiving the original value of the client device's public key.

[0028] The described proof token can encode only a limited amount of information due to the described blinding scheme, thereby increasing the difficulty of encoding the expiration time within the token and enhancing its security. For example, one way to limit the token's lifetime when a limited amount of information exists is to define each token as valid only for the lifetime of the issuing key used to generate that token.

[0029] To prevent PII (Proof of Access) from being shared by parties requesting proof of access tokens for restricted content and / or resources, the token generation and redemption process can be integrated with existing systems as part of the resource and / or content access data flow. This process improves user privacy, experience, and access to resources and / or content while extending the functionality of intermediary platforms and websites and increasing the accessibility of parties requesting proof of access tokens without requiring additional effort from users. Furthermore, this process does not require the requesting party to receive any information about who the authenticated user is or how the token is being created. The recipient simply receives a proof of access token indicating that the user or device attempting to access a specific resource and / or content has been authenticated, their identity verified as an authorized party, or that they are otherwise trustworthy at a certain level. The recipient also confirms the identity of the requesting client device / user to ensure they are the correct user / authenticated user.

[0030] Various features and advantages of the foregoing subject matter are described below with reference to the figures. Additional features and advantages will be apparent from the subject matter and claims described herein. Attached Figure Description

[0031] Figure 1A It is a block diagram of the environment in which digital content is distributed.

[0032] Figure 1B This is a data flow diagram of an example process for requesting, issuing, and redeeming proof tokens.

[0033] Figure 2 This is a flowchart illustrating an example process for requesting and receiving a batch of N proof tokens.

[0034] Figure 3 This is a flowchart illustrating an example process for sending, receiving, and verifying proof tokens.

[0035] Figure 4 This is a flowchart illustrating an example process for requesting and receiving a batch of N blind-signed proof tokens.

[0036] Figure 5 This is a flowchart illustrating an example process for sending, receiving, and verifying a proof token for a blind signature.

[0037] Figure 6 This is a block diagram of an example computer system.

[0038] In the various figures, the same reference numerals and names indicate the same elements. Detailed Implementation

[0039] Typically, the systems and techniques described in this document provide a secure communication channel between an isolated environment, such as a web site accessed within a browser's sandbox environment, and client devices and other entities outside that isolated environment, such as content publishers. Within a secure sandbox environment, code can be executed securely within the isolated environment. However, to protect the environment's security, code running inside the environment may not be able to access information outside the environment. For example, a web browser may not be able to access device-level information such as the device and / or the authenticity of the requests made. In some implementations, although the web browser may be able to access the same raw input information that a "device integrity verification" subsystem on a separate device could access, replicating the actual process of transforming that information into a device integrity decision within the browser itself may be technically impractical or repetitive. The systems and techniques described below provide a pipeline from outside the sandbox environment to inside. This process guarantees security because data cannot be forged and guarantees privacy because data cannot be used to track user activity.

[0040] External entities such as client devices and / or other content publishers or providers can provide a proof token (or a redemption record for the redemption token) over the network along with requests and other data transmissions to verify the integrity of the request and the client device. Requests can include, for example, requests to manage user data (e.g., delete user-related data), and / or requests for content and / or access to resources. Using proof tokens to secure communication channels ensures user privacy and data security by preventing any data leakage to the isolated environment or to the requesting party who provided the proof token. The proof token includes several layers of verification, ensuring that authentication of the client device cannot be forged and that user privacy is protected, resulting in no PII being transmitted. The redemption process, and using the signed redemption result as a security signal—not the token itself—provides access to the requested website or the location from which the requested resource is being retrieved, ensuring that the token cannot be used to track client device / user activity or identify the user.

[0041] In some methods, the proof token can be digitally signed using the private key of a trusted program. The trusted program can confidentially maintain the private key. The proof token can, in particular, include a public key corresponding to the private key, a payload, and the proof token itself. The proof token can include a decision indicating the integrity level of the client device, as determined by a trusted device integrity system, such as a third-party device integrity system maintained by an entity different from the user of the client device and the recipient of the proof token. The proof token can also include the client device's public key (or a cryptographic hash of the public key) to bind the proof token to the client device.

[0042] The proof token can be digitally signed by the proof token issuing server using a private key kept confidential by the issuing server. A public key corresponding to this private key can be provided to the receiving system, allowing them to trust that the client device has been evaluated by the proof token issuing system, for example, by verifying the digital signature of the proof token using the public key. This combination of two key pairs provides a secure communication channel that enables the receiver to verify the integrity of the client device and the integrity of communications received from the client device, and binds the proof token to the client device, preventing other devices from using the proof token to forge its integrity.

[0043] In some methods, the proof token issuance system does not receive the original data used for the public key included in the proof token. Alternatively, the trusted application can send a blinded public key or a blinded derivative of a public key (e.g., a blinded truncated cryptographic hash of the public key) by using a blind signature scheme to blind the public key or a derivative thereof. Using blind signature schemes, the proof token issuance system can prove the integrity of a client device without receiving the original value of the client device's public key, thereby enhancing the privacy of the client device or user by reducing the risk of potential tracing via the public key. The proof token issuance system can also issue a blind signature verification key that the recipient can use to verify the blind signature.

[0044] In other methods, group signature schemes can be used, where the proof token issuing server acts as a group manager. For example, the proof token issuing server can issue M group verification keys for M trusted groups, assign client devices to one of the M trusted groups, and deliver anonymous certificates to the client devices. The client devices can use the anonymous certificates to anonymously sign the proof tokens, and these anonymous signatures can be verified by the recipient using the issued group verification keys. Using group signature schemes, neither the proof token issuing server nor the recipient of the proof token needs to receive the original value of the client device's public key, thereby further enhancing the privacy of the client device or user by reducing the risk of potential tracking via the public key.

[0045] Figure 1A and Figure 1B Examples of system 100 and process 190 for requesting, issuing and redeeming proof tokens are shown. Figure 1A This is a block diagram of an environment 100 in which digital content is distributed. Figure 1B It is used in, for example, Figure 1A The illustrated example environment 100 shows a data flow diagram of an example process 190 for requesting, issuing, and redeeming authentication tokens. Example environment 100 includes a data communication network 105, such as a local area network (LAN), a wide area network (WAN), the Internet, a mobile network, or a combination thereof. Network 105 connects client devices 110, publishers 130, a website 140, a content platform 150, an authentication token issuance (ATI) server 170 (which may also be referred to as a token issuance system), and a device integrity system 180 (which may also be referred to as a device integrity calculation system). Example environment 100 may include many different client devices 110, publishers 130, websites 140, content platforms 150, and authentication token issuance servers 170.

[0046] In a specific example, a user of a client device may attempt to access or request resources and / or content from a website that requests authentication of the user and / or client device 110. For example... Figure 1A The system shown and as Figure 1B The process shown provides a seamless way for users to access or request resources and / or content while verifying that the user and / or client device is a legitimate user authorized to access or request resources to the entity providing the resources and / or content.

[0047] Website 140 is, or can include, one or more resources 145 associated with a domain name and hosted by one or more servers. An example website is a collection of HTML-formatted web pages that can contain text, images, multimedia content, and programming elements such as scripts. Each website 140 is maintained by a publisher 130, which is the entity that controls, manages, and / or owns the website 140.

[0048] Resource 145 is any data that can be provided via network 105. Resource 145 is identified by a resource address (e.g., a Universal Resource Locator (URL)) associated with resource 145. Resources include HTML pages, word processing documents and portable document format (PDF) documents, images, videos, and feed sources, to name a few. Resources can include content such as words, phrases, images, and sounds, which may include embedded information (such as meta-information in hyperlinks) and / or embedded instructions (such as scripts).

[0049] Content platform 150 is a platform that provides access to various unaffiliated resources and / or domains. Content platform 150 can provide access to resources that are not associated with each other or with content platform 150. For example, content platform 150 can be a social media platform that provides access to content from various other websites, such as video hosting platforms, image hosting platforms, blogs, etc. Content platform 150 can communicate with and / or integrate with various content publisher domains. For example, content publisher domain 160 can be a different website that includes resources to which content platform 150 provides access. In some implementations, content publisher domain 160 can be a different website similar to website 140 and provides access to resources similar to resource 145. For example, content publisher domain 160-3 can be an image hosting website that provides access to images uploaded by its users. In some implementations, content platform 150 can request and provide access to resources by responding to a digital component request from an entity (content publishing partner 152) that selects digital components on behalf of digital component provider 160.

[0050] Client device 110 is an electronic device capable of communicating via network 105. Example client devices 110 include personal computers, mobile communication devices (e.g., smartphones), digital media players, smart speakers, wearable devices (e.g., smartwatches), and other devices capable of sending and receiving data via network 105. Client device 110 can also be a gaming device or a streaming device. Client device 110 typically includes applications 111, such as web browsers and / or native applications, to facilitate sending and receiving data via network 105. Native applications are applications developed for a specific platform or device. Publisher 130 is capable of developing native applications and providing them to client device 110.

[0051] Client device 110 may include one or more private keys 112 and one or more corresponding public keys 113. The private keys 112 and public keys 113 may be maintained by an application 111, a trusted program 114, and / or other programs on client device 110. Client device 110 may store one or more different sets of private / public key pairs. In some implementations, the private keys 112 and public keys 113 are stored in secure storage 115.

[0052] Client device 110 may also include a trusted program 114 that the user or client device 110 has authenticated to it. In some implementations, the trusted program 114 may be a native application of client device 110. For example, the trusted program 114 may be the device's operating system, or an application that is executed on client device 110 and associated with a specific entity that client device 110 has authenticated to it.

[0053] For example, trusted program 114 can issue authentication tokens to other applications for use in securing communications from client device 110. In some implementations, trusted program 114 is trusted by client device 110 from entities that request resources and / or content and require authentication. For example, trusted program 114 can be a program trusted by an entity requesting an authentication token. In one example, trusted program 114 can be a web-based interface for an entity accessible through application 111. In some implementations, trusted program 114 is associated with an entity requesting an authentication token. For example, trusted program 114 can be a mobile application maintained by an example news organization. The example news organization is able to create and maintain news content accessible to paid subscribers and news content accessible to all visitors.

[0054] The Affirmation Token Issuance (ATI) server 170 generates the proof token requested by the trusted program 114. The trusted program 114 can include hard-to-forge trusted code from a reliable source. In one example, the trusted program 114 can be an operating system, part of the operating system, a web browser, etc. Typically, the trusted program 114 is difficult to compromise, and the time and effort required for a malicious actor to tamper with it is prohibitively high. Additionally, because the trusted program 114 is provided and maintained by a reliable source, any vulnerabilities that arise can be addressed by that source. Using such a trusted program in this way provides the technical advantage of increased security at the client device because the trusted program is difficult to compromise. Additionally, the trusted program offers the advantage of mitigating vulnerabilities in the trusted program because it is maintained by a reliable source.

[0055] Trusted program 114 can be local to client device 110. For example, trusted program 114 can be a device driver for the operating system of client device 110. In some implementations, trusted program 114 operates entirely locally on client device 110, thereby reducing the need to transmit user information. In some implementations, trusted program 114 can operate locally on client device 110 and via a network such as network 105. For example, trusted program 114 can be a mobile application installed on user device 110 that transmits and receives information via network 105.

[0056] As described in more detail below, trusted program 114 is capable of generating encryption keys (e.g., public / private key pairs), storing the encryption keys in secure storage 115 (e.g., a secure cache), storing proof tokens in secure storage 115, generating proof tokens, generating blind signatures of encryption keys or derivatives thereof, and / or retrieving and storing certificates. In some implementations, trusted program 114 interacts with a device integrity client to send data to and receive data from the device integrity system. In some implementations, trusted program 114 is configured to generate a request for proof token 122 for each of a set of specified types of requests (e.g., requests to change user privacy settings).

[0057] The authentication token can be used by an entity to verify the integrity of a request and the integrity of client device 110. For example, some entities may attempt to forge parameters of resource or content requests, such as specifying different resources to be provided with the content and / or specifying different users to whom the content will be presented, in order to gain access to data that the entity may not be able to access normally. Additionally, some malicious parties may attempt to impersonate other people's client devices for illicit purposes.

[0058] During the process executed by system 100, a proof token is redeemed from ATI server 170 to generate a signed redemption result (SRR). The signed redemption result indicates whether the proof token was successfully redeemed, but does not include information such as the user identifier, the time the token was generated, the time the token was redeemed, verification information provided by trusted procedure 114, or other PII information of the user. The signed redemption result can also be used by the entity to verify the integrity of the request and the integrity of client device 110, and can be used in place of the proof token. By accepting the signed redemption request as verification instead of performing the token redemption and verification process, the process executed by system 100 protects user privacy while ensuring that the request and the user have been authenticated. In some implementations, the signed redemption result can be used to verify the integrity of the request in addition to the proof token.

[0059] In this system, both the proof token and the redemption result of the signature are used by the entity to verify that the user is authenticated to receive other data, such as the requested content or information. The redemption result of the signature is signed by the ATI server and proves that the user is authenticated to receive the specific data being requested, without providing data or other information identifying the requesting user, such as the degree or level of user authentication. In one example, an entity can provide a proof token to a resource provider for redemption, the resource provider redeems the proof token, signs the redemption result, and the signature on the result can be used to notify the entity that the proof token was previously successfully redeemed, and therefore the user requesting the resource is authenticated to receive the requested resource.

[0060] The process of verifying the redemption result of the token and signature provides a secure communication channel between the client device 110 and the computer or other devices of other entities through an intermediary. This prevents others from altering the request and ensures that the request comes from the verified client device 110 and from the authorized user through the proxy.

[0061] A redemption result that can be a very small amount of data (e.g., 2 bits) not only reduces the amount of data transferred between, for example, a website and an application running outside the sandbox environment, but also provides a secure communication channel between a sandbox environment, such as a web browser, and an application running outside that sandbox environment. In some implementations, the redemption result of the signature can exceed 2 bits. For example, the signature can contain more than 2 bits. In some implementations, the number of bits shared between the redemption result and the data on the client device accessible to the proof token issuance service (i.e., "connectable bits") is limited to reduce the ability of observers to link interactions of the same user or device with the proof token issuance service and the recipient of the SRR.

[0062] For example, if the proof token only includes 2 bits that can be connected to the proof service, then this limited amount of information guarantees that any information derived from the proof token, such as the redemption result, will have at most 2 bits that can be connected to the proof service. Proof data is not transmitted directly between the web browser and the application running outside the web browser because the proof data is both verified and redeemed to the ATI server. Due to this process, the data transmitted between the application running outside the web browser and the secure environment of the web browser carries the same information as provided by the proof token (i.e., the specific entity and / or request has been authenticated and the entity's identity has been successfully proven), but without the risk of exposure or interception; this process protects user privacy.

[0063] ATI server 170 can generate different types of proof tokens 122, which may have different forms or contain different content. In some implementations, the proof token 122 includes a dataset comprising the ATI server 170's public key 173, a token creation time indicating when the proof token 122 was created, payload data, and an integrity decision generated by a device integrity system or by a trusted program 114 using data received from the client device 110. The proof token 122 can also include a digital signature generated by the ATI server 170 using a private key 172 corresponding to the public key 173 included in the proof token 122, and the dataset. That is, the ATI server 170 can use the private key 172 to digitally sign the dataset and include the resulting digital signature along with the dataset in the proof token 122. In some implementations, the proof token includes the user's credentials in the payload.

[0064] In such matters Figure 1A and Figure 1B During the process described, ATI server 170 generates and redeems proof tokens, thereby providing the security benefits of proof tokens without requiring each entity to create and maintain a proof token system, and offering additional privacy benefits to users. See below for more information. Figures 2 to 5 Describe the process by which a proof token is generated. Additionally, because the request process includes a token redemption process, the proof token system needs to protect user privacy while providing verification data that offers the benefits of proof tokens, and also restricts the transfer and access to a user's PII.

[0065] In some implementations, as a security measure, the proof token can be set to expire within a predetermined period. By requiring the proof token when it expires, the ATI server 170 can ensure that the token must be requested periodically, and thus ensure that the entity proving its identity is authenticated periodically.

[0066] When the proof token expires, the corresponding data at ATI server 170 can be updated to ensure that the proof token cannot be redeemed later. In some implementations, ATI server 170 evaluates data, such as the age of the proof token, before determining whether to redeem the token and generating a signed redemption result.

[0067] In some implementations, the proof token 122 includes a dataset comprising payload data, a proof token creation time indicating when the proof token 122 was created, and a digital signature of the dataset. In this example, the ATI server 170 is able to generate the digital signature using a group signature scheme and a certificate issued by the device integrity system or the ATI server 170 to the client device 110.

[0068] Typically, the recipient of the authentication token then verifies the authentication token and / or the integrity judgment included in the authentication token (if appropriate). If the authentication token is successfully verified, the recipient is able to determine whether the client device 110 is a trusted device and process the request accordingly. If the authentication token is not successfully verified, the recipient is able to ignore or remove the request, for example, by not responding to the request or by changing the data in response to the request.

[0069] The proof token creation time indicates when proof token 122 was created. Trusted program 114 can record the creation time of the proof token. This proof token creation time can be a high-resolution timestamp (e.g., accurate to seconds, milliseconds, or microseconds). The proof token creation time can be used to determine whether request 120, including proof token 122, is a new request or a recent request. For example, an entity receiving proof token 122 can compare the token creation time with the current time or the time proof token 122 was received. If the difference between the two times exceeds a threshold, the entity can determine that the request is not new or is invalid, as described in more detail below.

[0070] The creation time of the proof token can also be used to detect replay attacks. For example, if multiple requests with the same dataset and including the same proof token creation time are received, the entity receiving the requests can determine that the requests are duplicates and / or part of a replay attack.

[0071] The creation time of the proof token, combined with other data, can also be used as a transaction identifier for the request. For example, in an implementation where proof token 122 includes a public key 113, the transaction identifier can be a combination of two or more of the creation time of proof token 122 and the public key 113. The transaction identifier can be used to perform deduplication on multiple versions of the same request 120 received from multiple channels. For example, ATI server 170 can receive the same request from both trusted program 114 and associated website 140. In another example, ATI server 170 can receive the same request from both content platform 150 and content publishing partner 152. In this example, the transaction identifier can be based on the creation time of proof token 122 and the public key 113 of proof token 122. ATI server 170 can compare two data points in two or more requests to determine whether the request is a duplicate.

[0072] The payload can include data for individual requests 120. For example, it can include information about the requested resource (e.g., the subject of the resource), information about the resource's context (e.g., the number of slots, the type of slots, the size of the slots, etc.), information about the client device 110 (e.g., the type of device, the IP address of the device, the geographical location of the client device 110) (if the user has enabled this feature) and / or other appropriate information.

[0073] In either example, it is possible to redeem the proof token and include the redemption result in the request for content provided by application 111 to website 140, enabling the website to guarantee that the request is valid and / or from an authorized user, but not to access the user's PII. Application 111 can include the SRR in requests sent to content platform 150 or other recipients such as website 140 to access resource 145.

[0074] If request 120 manages user data at publisher 130, content platform 150, content publishing partner 152, content publisher domain 160, or another entity, then request 120 may include data specifying the requested changes. For example, if a user chooses to remove all user data from content publisher domain 160-2, the payload will include data specifying this removal from content publisher domain 160-2 (e.g., an identifier or network address of content publisher domain 160-2).

[0075] The device integrity system 180 can additionally evaluate device-level fraud detection signals received from the client device 110, such as from a trusted program 114, and determine the trust level (or integrity level) of the client device 110 based on these signals. The device-level fraud detection signals can include data representing operational characteristics or metrics of the client device, which can be used to determine whether the client device is compromised or whether it is operating as a normal client device or a simulated client device. Certain operational characteristics and metrics often differ for a real client device compared to an emulator. In some implementations, the device-level fraud detection signals include application-level fraud detection signals, which include the operational characteristics and metrics of the application 111 requesting the authentication token. The trusted program 114 can collect these device-level fraud detection signals and include them in the request for the authentication token.

[0076] Device integrity system 180 can issue a decision indicating the trust level (or integrity) of client device 110. The receiver uses the decision to determine whether to trust the request 120, which includes that decision. For example, if the decision indicates that client device 110 is not trustworthy, the receiver can ignore the request, for example, by not responding to it.

[0077] In some implementations, the process described with respect to Figures 1 to 5 can be performed such that the trusted program 114 is a web site to which the user has authenticated, and the web site 140 is a program or application from which the user is requesting access or requesting resources.

[0078] When application 111 sends a request via network 105 to access a specific resource 145 or other content, application 111 can use privacy-preserving technologies to prove the user's identity, authenticity, and / or authorization status. This privacy-preserving technology allows for the generation and redemption of proof tokens without providing information that could be used to identify or otherwise track the user to either application 111 or website 140 from which the resource or other content is requested. Figure 1B Example 190 shows a process for implementing privacy-preserving technologies.

[0079] In step A, application 111 can generate a request 120 for one or more authentication tokens and provide the token request 120 to trusted program 114. For example, application 111 could be a web browser through which a user of client device 110 is accessing various websites such as website 140 and / or requesting access to or content from various resources, such as resource 145, publisher 130, and content platform 150, and other entities. In this example, trusted program 114 could be an application on client device 110 trusted by the entity from which application 111 is requesting resources or access. In one example, trusted program 114 could be an application created and hosted by an example news organization for smartphones, and a user could be requesting access to news articles on website 140 hosted by the example news organization via a news aggregator on web browser 111.

[0080] Users of client device 110 can provide login credentials to trusted program 114, enabling them to authenticate with the trusted program. For example, users can log in to the sample news organization using their username and password for their account. The account can be a free account or a paid subscription account, and users can be granted additional authorizations that users without login credentials cannot view, access, and / or receive regarding specific content and / or resources. For example, the sample news organization can provide users without any login credentials with access to a subset of its articles, users with login credentials for an account without a paid subscription with access to a larger subset of its articles, and users with login credentials for an account with a paid subscription with access to the complete set of its articles and content.

[0081] Application 111 can perform step A without receiving requests for proof or integrity information from website 140, content platform 150, and / or other entities. For example, application 111 can periodically send proof token requests 120 to trusted program 114 to refresh the proof token. In some implementations, the proof token can expire after a predetermined period of time to ensure that the proof data remains accurate and to reduce the likelihood of third parties or malicious actors accessing and using the proof data without authorization. When the proof token expires, application 111 can delete the expired proof token, automatically generate a request 120 for a new proof token, and provide that request to trusted program 114.

[0082] In step B, the trusted program 114 is able to generate a signature request for the proof token, thereby allowing a token issuing server, such as the Proof Token Issuance (ATI) server 170, to generate a proof token that proves the user's identity based on the information provided by the trusted program 114.

[0083] For example, a smartphone application 114 created and hosted by the example news organization can create a request 121 for a verification token and provide that request to the ATI server 170. This request can be signed by the example news organization application 114 to indicate information about the integrity of the request. For example, the request can be signed by the example news organization smartphone application 114 to indicate whether the request is made on behalf of a user with login credentials and / or the type of login credentials (i.e., a free account, a Tier 1 paid subscription account, an account on a shared family plan, etc.). In some implementations, the signature on the request can provide a determination of whether the request and / or the entity is authenticated. For example, the example news organization application can determine that the request is legitimate and / or that the user has been authenticated to the example news organization through the application using valid credentials. The example news organization application 114 can then include the authentication determination along with request 121.

[0084] In some implementations, request 121 is a new request generated by trusted application 114 using request 120 from application 111 to create request 121. In some implementations, request 120 is signed by trusted application 114 to indicate the validity of the request and / or the user, and the signed request 120 is transmitted as request 121. In some implementations, request 120 and validity information provided by trusted application 114 are transmitted together as request 121.

[0085] Because Application 111 does not directly request the proof token, it does not need access to the information included in the request for the proof token, and therefore can facilitate access to specific resources and / or content delivery without access to the user's PII. This allows the proof process to be performed seamlessly while protecting the user's privacy. Although Application 111 can receive, store, and redeem proof tokens, as detailed below... Figure 1A and Figure 1B The steps described in CI are as follows, but application 111 does not directly receive or have access to the PII provided by the user to the trusted program 114, except for the PII that the user has already granted application 111 access to. Therefore, in addition to protecting user privacy, the authentication token generation and redemption process, as described, also additionally allows application 111 to provide functionality such as content aggregation without requiring PII information from the user. This process improves the functionality of the system, thereby creating a more secure flow of information and reducing the amount of input required from the user.

[0086] Such as about Figure 1A and Figure 1B The described process involves two distinct sets of signatures, thus providing two steps within the trust chain. The certificate token issuer signs the redemption result of the certificate token and / or signature, and the web browser includes the signature on requests to access a portion of the website and / or resources.

[0087] As discussed above, in some methods, the trusted program 114, application 111, or client device 110 can include one or more private / public key pairs along with the proof token request (and the device integrity decision associated with the device's public key). In some implementations, the private / public key pairs can span multiple proof token variations to enhance the privacy of the client device or user against tracking by the proof token recipient. For example, the client device can generate batches of private / public key pairs and retrieve corresponding batches of proof tokens from a proof token issuing server, thereby reducing or eliminating the reuse of proof tokens. Figure 2 An illustrative example of this batching process is described in the document.

[0088] In step C, ATI server 170 issues a proof token. This token issuance step can include many different parts. Typically, ATI server 170 issues a proof token consisting of a small number of bits that bears proof of the identity of the requesting client device and / or user. Before issuing the proof token, ATI server 170 is able to verify that the request is valid, thereby providing an additional layer of security for website 140, resource 145, content publisher domain 160, and / or any other entity providing SRR to it.

[0089] For example, ATI server 170 can verify the signature on request 121. In some implementations, as described above, trusted program 114 can provide a blind signature on request 121. In some implementations, the proof token issuing server does not receive the original data used for the public key included in the proof token. Alternatively, the client device can send a blinded public key or a blinded derivative of a public key (e.g., a blinded truncated cryptographic hash of the public key) by using a blind signature scheme to blind the public key or a derivative thereof. Using a blind signature scheme, the proof token issuing server can prove the integrity of the client device without receiving the original value of the client device's public key, thereby enhancing the privacy of the client device or user by reducing the risk of potential tracking via the public key. The proof token issuing server can issue a blind signature verification key that the recipient can use to verify the blind signature.

[0090] Once ATI server 170 has verified the validity of the request, ATI server 170 is able to issue a proof token 122 that proves the identity of client device 110 and / or user with respect to trusted program 114 and / or the entity associated with trusted program 114.

[0091] The number of proof tokens issued in step C can directly correspond to the number of proof tokens requested in steps A and / or B. For example, application 111 can request 5 proof tokens in step A, and trusted program 114 can provide a request for 5 proof tokens to ATI server 170. The number of proof tokens to be requested and / or issued can be determined by application 111, trusted program 114, client device 110, and / or ATI server 170.

[0092] In some implementations, the ATI server 170 can change the number of authentication tokens issued based on the number of authentication tokens requested. For example, the ATI server 170 can automatically determine the number of authentication tokens to be issued in response to a request based on the average number of authentication tokens requested from various sources. The ATI server 170 can determine the number of authentication tokens to be issued in response to a request by balancing security with reduced traffic: issuing more tokens reduces the number of times a request must be made and then a token issued, and also reduces the frequency of verifying the validity of the request and the identity of the user of application 111.

[0093] In some implementations, the number of proof tokens issued in step C depends on the maximum number of proof tokens that can be issued. For example, the proof token recipient can issue (1) a limit on the number of tokens that can be sent from each individual client device or application to the recipient's selected destination domain within a selected time frame (e.g., no more than X requests in Y seconds, minutes, or hours); (2) a limit on the number of tokens that can be sent from one or more selected applications on the individual client device to the recipient's selected destination domain within a selected time frame (e.g., no more than X requests from application A or from any application other than application A in Y seconds, minutes, or hours); (3) a limit on the number of tokens that can be sent from the individual client device to a selected endpoint within the recipient's selected destination domain within a selected time frame; (4) a limit on the number of tokens that can be sent from one or more selected applications on the client device to a selected endpoint within the selected destination domain within a selected time frame; or (5) any combination of two or more of such limits.

[0094] The authentication token 122 can itself be a single information bit indicating whether the holder is authenticated. For example, a value of 0 can indicate that the holder is not authenticated, and a value of 1 can indicate that the holder is authenticated.

[0095] The response issued by ATI server 170 to application 111 can include the authentication token 122 itself and can additionally include one or more encrypted information bits. In some implementations, additional information bits can be included in the authentication token 122, such that the authentication token 122 includes one bit indicating whether the holder is authenticated and one or more additional information bits. For example, at issuance, ATI server 170 can include one bit of private metadata (such as verified user credentials or other data) to be transferred from outside the secure sandbox environment of application 111 to inside the secure sandbox environment of application 111.

[0096] The ATI server 170 can additionally use multiple private signing keys to sign the proof token. These private signing keys, which can be verified using the corresponding verification key provided by the ATI server 170, serve as signatures as part of the trust chain. When the recipient of the proof token can verify the signing key using the corresponding verification key provided by the ATI server 170, the recipient can trust that the ATI server 170 issued the proof token. This process of signing the proof token can be performed using, for example, a blind signature scheme, such that the proof token issuing server does not see the raw data of the client device's public key. For example, the client device can generate batches of private / public key pairs and then use a blind signature scheme to blind the public keys (or suitable derivatives of these public keys that can be used as values ​​for the submission phase of the blind signature scheme, such as cryptographic hashes of the public keys or cryptographic hashes of public keys concatenated with the device model) before sending the public keys to the proof token issuing server to retrieve the corresponding batches of proof tokens. In this example, the proof token is blindly signed using the public key. Figure 4 An illustrative example of this batching process is described in the document.

[0097] Additionally, ATI server 170 can use multiple private signing keys with the corresponding verification key provided by ATI server 170 to sign the SRR in a process similar to that described above regarding signing the proof token in step C.

[0098] The combination of n verification keys and a single information bit provides n*2 distinct combinations, and these combinations additionally encrypt a small amount of information into a token that can be verified by application 111. The encrypted information can be verified by application 111, such as a web browser, to ensure that additional information has not been encrypted into the token, as the encryption result will reveal the number of encrypted bits. If application 111 determines that additional data has been encrypted into the verification token, then application 111 does not need to store the token or redeem it. For example, if application 111 verifies the verification token before storing it, application 111 can simply discard the token. If, for example, application 111 verifies the verification token before redemption, application 111 can discard the token and avoid attempting to redeem it.

[0099] For example, if ATI server 170 attempts to encrypt more bits than expected into the proof token, the proof token will fail the check performed by application 111. Application 111 can, for example, periodically check the public key and / or verification key provided by ATI server 170. Application 111 can then use the public key to verify the digital signature of ATI server 170. However, if neither verification key verifies the proof token, application 111 will not attempt to redeem the token and can discard it.

[0100] In step D, application 111 stores the authentication token received from ATI server 170. For example, application 111 receives authentication token 122 from ATI server 170 and then stores the token in secure storage. For example, application 111 can store authentication token 122 in a secure cache maintained by application 111 or client device 110.

[0101] In step E, a triggering event occurs for the redemption of the proof token. In some implementations, website 140 can request proof from application 111 before granting access or delivering resources. For example, if a user of client device 110 attempts to access a feature for adding a custom background to their profile on example social media website 140, example social media website 140 can request proof from application 111 before granting access to that feature. In some implementations, application 111 can automatically redeem proof tokens to create storage for the SRR to be used. For example, a user of application 111 may have a pattern of accessing example news aggregation website 140 before 7 a.m. each day, and application 111 can automatically redeem proof tokens for various example news websites 140a, 140b, and 140c that display articles from them on example news aggregation website 140.

[0102] To protect user privacy, system 100 implements a token redemption process that allows proof tokens to be redeemed, thereby proving the user's identity while keeping the token details private to ATI server 170. This token redemption process includes application 111 generating a request to redeem a proof token. The token redemption request and the proof token are provided to ATI server 170, which generates a signed redemption result (SRR). This signed redemption result, indicating that the proof token was successfully (or unsuccessfully) redeemed and without providing the user's PII or information that could be used to track redemption or usage patterns, is provided to application 111 in response to the token redemption request. Application 111 can then include the SRR in a request to access resources or other content from website 140 to prove the user's identity and / or the authenticity of the request. Because it is the SRR, rather than the proof token, that is provided to website 140, website 140 can trust that the user is authorized to access resources and / or receive content without access to the user's PII.

[0103] In some implementations, ATI server 170 determines whether any valid proof token exists for a particular issuer. If no token is available for a given issuer, ATI server 170 rejects the request with an error. If a token is available for a given issuer, the ATI server issues a proof token to the requesting entity. The issuer can consume the token and, based on the result, act, including an SRR response header to allow the redemption proof to be forwarded to other parties without exposing the credentials or user information of the entity proving its identity. Additionally, the issuer may include information in the proof token and / or SRR to indicate how long the redemption record should be cached (e.g., in seconds). In some implementations, if this information is not included, the lifetime of the SRR is tied to the lifetime of the proof token information confirming the issuance of the redemption token. In some implementations, the SRR is treated as an arbitrarily large object (blob) of bytes from the issuer.

[0104] The token redemption process, as well as the process of using SRR to authenticate requests and / or users, also provides a security mechanism for transferring information from outside the sandbox environment of application 111 to the sandbox environment. Traditionally, for applications 111 such as web browsers, the application runs inside a sandbox environment and is isolated from other entities and information to provide a secure environment. The systems and processes described with respect to Figures 1 through 6 maintain the security of the sandbox.

[0105] Additionally, because the recipient of the SRR does not perform the verification and redemption of the token, the recipient of the SRR does not need to request or process information such as proof token information. This allows the process to protect user privacy and improve the security of the transmitted data, because proof tokens can be issued to the user of application 111 without requesting additional information once the user has provided their credentials to the trusted program 114.

[0106] In some implementations, the ATI server 170 is associated with a trusted program 114, a website 140, a content platform 150, and / or one or more content publisher domains 160. For example, the ATI server 170 could be maintained by the entity, Example News Organization, which operates the Example News Organization mobile application 114 and the Example News Organization website. In some implementations, the ATI server 170 is a separate entity from the trusted program 114, website 140, content platform 150, and / or one or more content publisher domains 160, and does not require the development of infrastructure for processing authentication tokens. For example, the ATI server 170 could be designated as the server of a trusted authentication token issuance system by a website 140 to which a user is attempting to gain access. The website 140 would not need to develop or maintain infrastructure for processing authentication tokens and would instead accept the redemption result signed by the ATI server 170. (See also: [link to relevant documentation]). Figure 1A and Figure 1B The described system and process allow websites, content publishers, and other content providers and resources to verify that requests are genuine and / or that users are authorized to access / receive content without needing to know how tokens are requested, generated, and / or redeemed.

[0107] For example, if application 111 sends a request to another entity (e.g., to publisher 130, content platform 150, content publishing partner 152, or content publisher domain 160) to manage, for example, the deletion of data stored by that entity, then this request can include SRR.

[0108] In some implementations, application 111 is configured to automatically send SRRs with specified types of requests. For example, each application 111 that requests a proof token and sends an SRR can include a software development kit (SDK) or application programming interface (API) that enables application 111 to access and / or redeem the proof token and access and / or send an SRR. The API can specify the set of requests to include SRRs, such as requests for managing user data, requests for access to resources and / or content that the user needs to authorize, etc. For example, certain types of requests for content or for accessing specific resources (such as requesting a news web page for a paid subscriber) may require SRRs.

[0109] In step F, application 111 sends a token redemption request 123 to ATI server 170. This step of redeeming the token from the ATI server 170 that issued the token allows for the provision of an SRR instead of a proof token. Data associated with the issuance and redemption of the proof token can be used as a traceable signal to track user activity; however, the signed redemption result only provides information that the holder of the SRR has successfully redeemed the proof token, without providing potentially sensitive, identifiable, or traceable information, such as the context in which the token was redeemed, the time of the token redemption, and / or authentication information provided prior to the issuance of the token, and other information.

[0110] Application 111, along with token redemption request 123, transmits data indicating the proof token to be redeemed. In some implementations, token redemption request 123 includes the proof token for redemption. In some implementations, application 111 transmits the proof token along with token redemption request 123. In some implementations, application 111 transmits data indicating that the proof token was successfully issued to the user of client device 110.

[0111] At the redemption time, when ATI server 170 receives token redemption request 123, ATI server 170 also receives a proof token. If the proof token is valid and verifiable, it is a token previously issued by ATI server 170 and stored by application 111. ATI server 170 receives the proof token along with token redemption request 123 and extracts one of the possible combinations of information bits and encryption keys. These bits indicate whether the holder of the proof token has been verified. In some implementations, multiple different encryption keys are available to provide additional information about the proof token and authentication level. For example, different public keys can indicate different authorization levels or different authentication levels. In some implementations, the token information is verified by application 111 before storage and can also be verified by ATI server 170 before redemption to verify that the token was issued by ATI server 170 itself and to ensure that application 111 has not modified the token.

[0112] In step G, ATI server 170 generates and transmits a signed redemption result 124 to application 111. Once ATI server 170 has verified that the proof token indicated in token redemption request 123 is valid and / or issued by ATI server 170 itself, ATI server 170 is able to generate the redemption result and then sign it. The signature from ATI server 170 adds an additional link to the chain of trust and allows the recipient of the signed redemption result to trust that the proof token was redeemed from ATI server 170 without providing the recipient with additional information that could be used to track the user's activity or identity.

[0113] ATI server 170 verifies the proof token indicated in token redemption request 123 by verifying, for example, that one or more digital signatures associated with the proof token have not been forged. For example, ATI server 170 can verify that one or more digital signatures it itself uses to sign the proof token as described in step C have not been forged. ATI server 170 can perform this check by decrypting the proof token using its private key.

[0114] In some implementations, ATI server 170 can verify that one or more digital signatures from, for example, application 111 have not been forged to ensure that token redemption request 123 is legitimate. For example, ATI server 170 can compare the signature data with one or more public keys issued by application 111. In some implementations, the digital signature can simply be metadata provided along with the token redemption request 123, indicating that the request was generated by application 111.

[0115] In some implementations, ATI server 170 can verify additional token data, such as redemption time, the context for redemption, and / or the time the proof token was issued, as well as other metrics and characteristics. In some implementations, ATI server 170 can identify specific contexts under which a particular type of proof token can be redeemed, and can verify whether the current context is a valid context in which the proof token can be redeemed. For example, ATI server 170 may receive information from a specific website 140 that a proof token for accessing a subscriber-only crossword puzzle can only be redeemed when attempting to access the crossword puzzle. However, a token redemption request 123 may indicate that the proof token for accessing the subscriber-only crossword puzzle is being redeemed without any data indicating an attempt to access the subscriber-only crossword puzzle. ATI server 170 can then determine that the context for redemption is not met, and can reject the token redemption request by transmitting an indication of rejection or unsuccessful redemption, invalidating the proof token, and / or simply not responding to the token redemption request, among other actions.

[0116] In some implementations, ATI server 170 can determine whether a proof token has expired upon receiving a token redemption request 123. For example, ATI server 170 can determine how long the proof token has been unredeemed and whether it has expired based on the creation time associated with the proof token. In one example, ATI server 170 can determine that a proof token used to access and perform a search on the research database must be less than 25 minutes old to be redeemed. Later, if ATI server 170 receives a token redemption request 123 indicating that a proof token used to access and perform a search on the research database is one week old, ATI server 170 can determine that the proof token has expired and can refuse the token redemption request by transmitting an instruction to refuse or fail redemption, invalidating the proof token, and / or simply not responding to the token redemption request, among other actions. The expiration period for the proof token can be any amount of time, such as 10 seconds, 15 minutes, 3 hours, 6 days, two weeks, etc.

[0117] Once the ATI server 170 has completed its verification of the proof token and / or token redemption request, the ATI server 170 generates a signed redemption result. SRR 124 includes data indicating whether the proof token was successfully redeemed, and does not include additional data that could be used to track user activity or identify the user associated with the credentials used to generate the redeemed proof token.

[0118] The process of generating a signed redemption result that provides only an indication of whether the token has been successfully redeemed ensures the security of the recipient of the signed redemption result and the privacy of the user who generated the signed redemption result.

[0119] For example, by generating a redemption result with a signature and providing that result to website 140 instead of providing a proof token, website 140 cannot trace the original request for the proof token and associate it with a specific user. (See below for details.) Figure 4 As described, because the proof token is signed using a blind signature scheme, the ATI server 170 that issued the token can only verify that it itself signed the token and that the token has not been modified or previously redeemed. The ATI server 170 cannot see when the proof token was signed or any additional parameters associated with the initial request for the proof token, thus protecting the privacy of the user requesting the proof token.

[0120] In step H, application 111 stores the SRR in secure storage. For example, application 111 can store the SRR 125 in a secure cache location similar to storage where the proof token 122 is stored.

[0121] In step I, application 111 generates and sends access request 125 to website 140. Access request 125 may additionally include parameters, such as SRR and other parameters. Application 111 may digitally sign access request 125 as an additional link in the chain of trust. For example, application 111 may sign critical parameters in access request 125. In some implementations, if all parameters are sensitive or important, all parameters may be signed in access request 125.

[0122] In some implementations, step I is triggered by website 140. For example, application 111 may attempt to access resource 145 or a specific section of website 140, and website 140 may request authentication from application 111.

[0123] In some implementations, step I is performed automatically by application 111 based on information detected by application 111 from website 140. For example, application 111 may detect from data associated with website 140 that authentication may be required. The data may be stored by application 111, provided by website 140, or otherwise accessible to application 111. For example, the data may be stored in a centrally shared location, such as a central database, accessible to multiple different applications 111 installed on multiple different devices. In some implementations, application 111 may determine that website 140 requires authentication based on the stored data. For example, when application 111 first attempts to access website 140, application 111 may receive data indicating a request for authentication. On subsequent attempts to access website 140, application 111 may automatically determine that authentication will be requested to access website 140 and provide an SRR when attempting to access website 140 and / or resource 145.

[0124] In step J, website 140 attempts to verify the SRR provided in the access request. If website 140 is able to verify the SRR, then website 140 is able to provide access to the portion of website 140 indicated in access request 125 or provide access to the requested resource 145.

[0125] As mentioned above Figure 1A and Figure 1B The described process is secure and private. In some implementations, when issuing proof tokens using the blinding scheme or group signature scheme described above, the process allows different platforms, content providers, and publishers to verify that a user is authorized to access specific content while protecting user privacy, ensuring that no single party can track user activity or link activity to a specific user or user information during the process.

[0126] In some implementations, if the proof token is issued without blinding or group signing, the token can contain a high-resolution timestamp or detailed application information, as well as other potentially sensitive information or information that can be used to link subsequent web activities to a specific device in the event of collusion between the proof token issuing server and the content publisher.

[0127] In a specific example, trusted application 114 is a mobile application installed on client device 110 (the user's smartphone) and is the official trusted application of the example news organization. Application 111 is a web browser installed on client device 110, and website 140 is the official website of the example news organization. Users who are subscribers of the example news organization, logged into the example news organization's application 114, and wish to access content on the example news organization's official website 140 on client device 110 can have a seamless browsing experience. For example, web browser 111 can generate a token request and provide it to the example news organization application 114. The user has provided their login credentials, and the authenticated example news organization application 114 can generate a signed token request 121 to ATI server 170. In this specific example, ATI server 170 can be a certificate token issuing server maintained by the example news organization. In some implementations, ATI server 170 can be a trusted server to which the example news organization delegates token issuance tasks. The signed token request 121 can include the user's credentials for verification by ATI server 170. Upon receiving and verifying the user's credentials and / or request 121, ATI server 170 can issue a verification token 122 to web browser 111. Verification token 122 can include at least one bit indicating whether the user's credentials and / or request 121 has been authenticated. Verification token 122 can be stored in the secure cache of web browser 111. Application 111 can then generate and send a token redemption request 123 to ATI server 170 indicating the stored verification token 122. If ATI server 170 can verify the verification token indicated in token redemption request 123, ATI server 170 generates a signed redemption result 124 and sends SRR 124 to web browser 111. Each of the preceding steps can be performed before a user requests access to a specific resource 145 or portion of website 140. When a user of client device 110 requests access to a new crossword puzzle on example news organization website 140, web browser 111 can generate and send an access request 125 to example news organization website 140. Access request 125 includes SRR 124 and other key parameters, such as the required metadata or other information requested by website 140. In this particular example, example news organization website 140 is able to determine that a user has a subscription, but cannot access the user's identity or track the user's activity because the blinding or other privacy-preserving techniques used to generate the proof token produce the token in a privacy-preserving manner.When privacy-preserving technologies are used to generate proof tokens, even if the issuer does not convert the token into a signed redemption result, the proof token will allow the content publisher to determine that the user is authenticated, but will not be able to access the user's identity or track the user's activity.

[0128] In another example, if website 140 is instead a mobile application or web interface for the example news aggregation platform, where the example news aggregation platform is separate and distinct from the example news organization, then using a token redemption process and SRR instead of the token itself allows the example news aggregation platform to provide access to information maintained by the example news organization without the ability to connect or extrapolate user information or activity between the parties, either the example news aggregation platform or the example news organization, simply by knowing that the user requesting access is an authenticated user of the example news organization. In this way, the example news aggregation platform knows the user's activity within its domain, and the example news organization knows the user's activity within its domain, but the example news aggregation platform does not know the user's activity within its domain, or vice versa. Neither platform can provide access through the methods described above. Figure 1A and Figure 1B The described process is used to determine this user activity or data.

[0129] Common methods of cross-platform authentication involve requiring users to provide their credentials for a single domain or entity from different domains or entities, thereby granting those different domains or entities access to the user's information. For example, regarding... Figure 1A and Figure 1B The described process eliminates the ability of one entity to request access to another entity's user data by removing the login process from the access to a specific website or resource. Through the use of a token issuance and redemption process, this process allows users to communicate authentication without providing data in its original, understandable form to any party other than a trusted program that has already provided the information and a token-issuing server that must prove the user's authentication.

[0130] Such as about Figure 1A and Figure 1B The described process provides the ability to transfer authentication across different websites and platforms, thereby reducing user friction and providing a better user experience.

[0131] In another example, a proof token can be issued to a user with a valid subscription to the example video streaming service, which can be redeemed for an SRR. The SRR can be used to access and / or view videos embedded in social media posts that are available to users with a subscription to the example video streaming service without requiring the user to log in each time. Specifically, the described process allows users to access content without needing to log in within the app hosting the social media posts, as long as the user is already logged in to the video streaming service app.

[0132] While some methods allow users to log in once within a hosted app and allow authentication to persist throughout the app's lifetime, changes to privacy incentives could render such methods, which rely on data such as "third-party cookies," unusable in the future.

[0133] The described authentication process based on proof tokens offers better privacy features, reduces the number of logins required by third parties, and can continue to work in future scenarios where other methods do not work.

[0134] In another example, a user with a valid subscription to the sample music hosting platform is able to install the sample music hosting platform app on their device. The user is able to authenticate themselves to the sample music hosting platform app and access music available to users with a subscription to the sample music hosting platform on various websites without adding their activity to their history.

[0135] In yet another example, a user with a valid subscription to the example video streaming service is able to access videos available to users with the same subscription, videos sent to them by friends in chat messages on a social media platform. This access to the videos allows the example video streaming service to assure the user that they are an authenticated user without providing their account information.

[0136] As discussed above, in some methods, private / public key pairs (and the decisions associated with the public keys) can be used across multiple proof token variations to enhance the privacy of client devices or users against tracking. For example, client devices can generate batches of private / public key pairs and retrieve corresponding batches of proof tokens from a proof token issuing server, thereby reducing or eliminating the reuse of proof tokens. Figure 2 An illustrative example of this batching process is described in the document.

[0137] In this example, application 200 creates N public / private key pairs (201). For example, a web browser installed on application 200 can generate public / private key pairs. Public / private key pairs can be asymmetric key pairs. Each public / private key pair consists of a private key and a public key, the public key corresponding to and mathematically linked to the private key. Data digitally signed using the private key can only be verified using the corresponding public key. Similarly, data encrypted using the public key can only be decrypted using the corresponding private key.

[0138] Application 200 sends a request (202) for N proof tokens to proof token issuing server 230. The number N can be an integer greater than or equal to two. In this example, the request is for N proof tokens corresponding to N public / private key pairs. Application 200 can determine the number N of proof tokens to be requested based on the frequency with which application 200 uses the redemption results of the signature in the request. The application can generate a public / private key pair for each requested proof token and include public key data in the request. In this example, the public key data can be the public key itself. The request therefore involves passing N public keys 211 of application 200 to proof token issuing server 230. In this example, the N public keys 211 include the actual public keys, for example, the raw data of the N public keys 211. The request can also include device-level fraud detection signals. For example, a trusted program can collect device-level fraud detection signals and include these signals in the request.

[0139] Similar to the above about Figure 1A and Figure 1B The processes described in steps A and B are capable of forwarding a request from application 200 to trusted program 220. The request can include information such as the user's credentials.

[0140] The authentication token issuing server 230 receives the request (231). Based on the user credentials received from the trusted program 220, the authentication token issuing server 230 determines the authentication level of the client device (232). For example, the authentication token issuing server may have M possible authentication levels. In this example, the authentication token issuing server 230 is able to select one of these M possible authentication levels based on the user credentials as described above. The authentication level can be encoded, for example, through a specific signature.

[0141] The proof token issuing server 230 generates N proof tokens (233). The proof token issuing server 230 generates a corresponding proof token for each received public key.

[0142] Each proof token can include an authentication decision, a timestamp for the authentication decision, and one of N public keys 211 of application 200. The timestamp indicates when the proof token was generated. The proof token issuing server can generate each proof token based on one of the N public keys 211. For example, the proof token issuing server 230 can assemble a dataset including the public keys of application 200, the authentication decision, and the timestamp. In some methods, if the authentication decision includes only two possible decisions (authenticated or unauthenticated), the authentication decision can be omitted from the proof token. In other words, in these methods, the proof token issuing server can generate proof tokens for authenticated users (where those tokens omit the implied authentication decision) and simply refuse to generate proof tokens for unauthenticated users.

[0143] The proof token issuing server 230 digitally signs each of the N proof tokens (234). For example, the proof token issuing server 230 can generate a digital signature using its own private key and based on other data of the proof token (e.g., authentication decision, application 200's public key, and timestamp).

[0144] The proof token issuing server 230 transmits N proof tokens to the application (235). The application 200 receives and stores the batch of proof tokens for later use (203). The application 200 can store the proof tokens locally, for example, in a cache or secure storage maintained by the application. Each cached proof token can include, for example: (1) a judgment of trust level as determined by the proof token issuing server 230; (2) a timestamp for the creation of the proof token; (3) the application's public key; and (4) a digital signature of the token component signed using the private key of the proof token issuing server 230.

[0145] After obtaining a batch of proof tokens, such as Figure 2 As illustrated in the examples, client devices can use authentication tokens to assemble and send them as part of various requests to a website, content publisher domain, or other authentication token recipient, as discussed above. Illustrative examples of such requests are provided in... Figure 3 It is depicted as a process flowchart.

[0146] To prepare a request, application 300 is able to retrieve a proof token from the application's local storage (301). Among various methods, application 300 is able to, for example, (1) use a new proof token for each request; or (2) use the same proof token for a selected time interval (e.g., consecutive H hours) and use a different proof token as the interval elapses; or (3) use the same proof token for all requests originating from the same application or website (e.g., where different proof tokens are used for each application or website); or (4) reuse a combination of two or more of these methods using these tokens (e.g., use the same proof token for all requests originating from the same application or website within a selected time interval). Therefore, application 300 is able to retrieve the proof token based on the application or website that generated the request or the current time when the request was generated.

[0147] Application 300 can generate a request (302) to redeem the proof token. Request 311 can include, for example, payload data (as discussed above), a request creation timestamp, the retrieved proof token, a public key corresponding to the proof token, and a digital signature of the request component. In some implementations, a trusted program on the client device or a trusted component of the client device's operating system can generate request 311 by accessing the payload data and the proof token, which can include the proof token or be in the form of a proof token. The application can also determine the current time as the request creation timestamp. The application can use its private key (e.g., a private key corresponding to the public key included in the request) to generate a digital signature of the payload data, public key, and timestamp. In some methods, as a simple optimization to reduce the size of the proof token, the device public key is omitted from the proof token because the public key is already present in the proof token included as a component of the proof token.

[0148] In some implementations, the ATI server 170 assists in redeeming the token and is associated with the requested website for identification. In some implementations, when issuing tokens using privacy-preserving techniques such as blinding or group signatures, the only information the ATI server 170 learns by observing token redemption is an approximate number of users or devices to which it previously issued the token and which have accessed this second content provider, but due to the privacy-preserving nature of the token, it cannot identify any specific user or device.

[0149] The application returns 300 and then sends request 311 to the proof token issuing server 320 (303).

[0150] The proof token issuing server 320 receives the request (321). The proof token issuing server 320 verifies the request (322). For example, the proof token issuing server 320 can verify the request by using the public key included in the request to verify the digital signature of the request. The proof token issuing server 320 can attempt to verify the digital signature using the public key and the content of the request signed by application 300 (e.g., payload data, timestamp, public key, and proof token). If any of this content is changed after the digital signature is generated, the verification will fail. For example, if a malicious party inserts a proof token into another request or inserts a different proof token with a higher verdict of authentication into the request, the signature verification will fail. This ensures that the content of the request is not changed, for example, by an intermediary, during the transmission of the request.

[0151] The proof token issuing server 320 verifies the proof token (323). For example, the proof token issuing server 320 can verify the proof token by verifying the signature of the proof token using the public key of the proof token issuing server. This similarly ensures that the content of the proof token has not changed since the proof token was issued by the proof token issuing server. If the proof token includes a device public key, the verification of the proof token can also include confirming that the device public key included with the proof token matches the device public key included in the proof token.

[0152] The certificate token issuing server 320 verifies the timeliness of the certificate token and the authentication of the client device (324), for example by confirming that the certificate token was recently created (i.e., not created at a selected time interval such as H hours or D days before the time the request was made, for H, D = 1, 2, 3, ...), and by confirming that the authentication decision in the certificate token is a decision sufficient to approve the request.

[0153] If all these validity checks pass, then the proof token issuing server 320 is able to respond to the request by redeeming the proof token (325), for example, as stated above regarding Figure 1A , Figure 1B and Figure 2 The described redemption result of generating the signature, etc. If any validity check fails, it proves that the token issuing server 320 can ignore the request. For example, it proves that the token issuing server 320 can not respond to the request, can not perform the requested operation, etc.

[0154] Application 300 receives the SRR (304). Application 300 can then send an access request 313 (313) to the recipient computing system 330. The access request 313 can include the SRR 312 and other parameters, including user data, context data, or timestamps. As described above, the recipient can be the requesting website, content provider or publisher, or other entities. For example, application 300 can send the access request and SRR to content platform 150, and the content platform can send the request to one or more content publisher domains.

[0155] The receiver computing system 330 is able to receive the signed redemption result and respond to the request if all validity checks pass (331).

[0156] As discussed above, in some methods, a blind signature scheme can be used during the generation of proof tokens, so that the proof token issuing server does not see the raw data of the application's public keys. For example, an application can generate batches of private / public key pairs and then use a blind signature scheme to blind the public keys (or suitable derivatives of these public keys that can be used as values ​​for the submission phase of the blind signature scheme, such as cryptographic hashes of the public keys or cryptographic hashes of public keys cascaded with the device model) before sending the public keys to the proof token issuing server to retrieve the corresponding batches of proof tokens. In this example, the proof tokens are blind-signed using the blinded public keys. Figure 4 An illustrative example of this batching process is described in the document.

[0157] In this example, it is demonstrated that the token issuing server 420 can define M different authentication levels for the application and issue M different blind signature verification keys 411 (421) for the corresponding M authentication levels. For example, the M levels can include two levels: authenticated and unauthenticated. In another example, the M levels can include three levels: suspicious, satisfactory, and fully authenticated. In yet another example, the M levels can include four levels: fraudulent, suspicious, subscriber, and special subscriber. Other numbers of levels can also be used. Therefore, M can be an integer greater than or equal to two. In some methods, instead of assigning a blind signature verification key to the lowest authentication level (e.g., the "unauthenticated" or "fraudulent" authentication level), it is possible to omit the lowest authentication level from the M authentication levels, and it is demonstrated that the token issuing server can simply refuse to provide a blind signature to a device with the lowest authentication level. Therefore, in these methods, M can be an integer greater than or equal to one.

[0158] The proof token issuing server 420 is capable of using a blind signature scheme to generate a corresponding blind signature verification key 411 for each authentication level. The blind signature scheme can be a privately verifiable scheme, such as the Internet Engineering Task Force (IETF) verifiable unintentional pseudo-random function (VOPRF) blind signature scheme. Alternatively, the blind signature scheme can be a publicly verifiable scheme, such as the Rivest-Shamir-Adleman (RSA) blind signature scheme.

[0159] The proof token issuing server 420 is able to issue a blind signature verification key 411, enabling applications, including application 400, to obtain the blind signature verification key 411. For example, the proof token issuing server 420 can issue the blind signature verification key 411 to a website or mobile app store.

[0160] Application 400 can receive these blind signature verification keys (401). For example, application 400 can download blind signature verification key 411 and store it locally, for example, in secure storage or a cache. Application 400 can retain blind signature verification key 411 to verify blind signatures received later from proof token issuing server 420, as discussed further below. In some methods, proof token issuing server 420 can periodically issue new blind signature verification keys 411 (e.g., hourly, daily, weekly, or other suitable time periods), and such refreshing of the blind signature verification key set can be used to verify the timeliness of device integrity tokens, as described further below.

[0161] To obtain a batch of N proof tokens, application 400 creates N public / private key pairs (402). For example, a web browser can create a corresponding asymmetric public / private key pair for each proof token.

[0162] Application 400 blinds each public key or each derivative of a public key according to a blind signature scheme used to generate the blind signature verification key (403). That is, application 400 blinds the public key data of each public key, where the public key data is the public key or a derivative of the public key. Blinding the public keys can include obscuring the original value of the public key by applying a blinding factor to the original value of the public key. In this way, it is proven that the token issuing server 420 cannot access the original value of the public key received from application 400 and use those values ​​to track users or application 400, for example, data received from another entity that received the original value of the public key, along with additional data.

[0163] To reduce the amount of data that needs to be blind-signed by the proof token issuing server 420, instead of blinding the public key for each entire device, the application 400 (e.g., its trusted program) can generate derivatives of the public key and blind these derivatives. The derivatives can be cryptographic hashes of the public key. For example, the application 400 can use a cryptographic hash function to generate a cryptographic hash for each public key and then use a blind signature scheme to blind the cryptographic hashes of the public keys. In some implementations, the cryptographic hash algorithm can be SHA256.

[0164] In some implementations, Application 400 can further reduce the size of the blinded public key data by truncating the cryptographic hash, and then blind the truncated cryptographic hash. For example, such truncation can limit the cryptographic hash from the original cryptographic hash, which has a large data size, to 16 bytes. This truncation produces a shorter cryptographic hash that Application 400 blinds using a blind signature scheme.

[0165] This method reduces the amount of data to be blind-signed, thus reducing the burden on the proof token issuing server 420 when blind-signing data (e.g., reducing CPU cycles, data storage requirements, memory consumption, etc.). This allows the proof token issuing server 420 to generate blind signatures faster and more efficiently and process more requests compared to providing a blinded version of the full public key. It also reduces bandwidth consumption over the network through which requests are sent and enables the transmission of large amounts of blinded public key data in a single request.

[0166] Application 400 sends a request 412 (404) for N proof tokens to proof token issuing server 420. The number N can be an integer greater than or equal to two. The request can include blinded public key data for each public key 411 generated by application 400. For example, the request can include N blinded public keys, N blinded cryptographic hashes of the public keys, or N blinded truncated cryptographic hashes of the public keys. The request can also include, for example, device-level fraud detection signals collected by a trusted program of application 400. In some implementations, similar to... Figure 1A , Figure 1B , Figure 2 and Figure 3 In the described process, application 400 transmits request 412 through a trusted program (not shown).

[0167] The authentication token issuing server 420 receives the request (422). The authentication token issuing server 420 determines the authentication decision of application 400 based on the user credentials indicated in the request, which may have been provided by a trusted program (423). In some implementations, the authentication token issuing server 400 is capable of having M possible decisions for authentication (corresponding to the M blind signature verification keys issued in operation 421). The authentication token issuing server 420 is capable of assigning application 400 to one of the M possible decisions based on a device-level fraud detection signal.

[0168] After the authentication decision for application 400 has been determined, the proof token issuing server 420 generates a batch of proof tokens (424). For example, the proof token issuing server 400 can generate proof tokens for each public key generated in operation 402 above. Each proof token can include, for example: (1) the public key of the application for which the proof token is being generated; (2) the authentication decision as determined by the proof token issuing server; and (3) a deblinded blind signature of the blinded public key or a (e.g., truncated) cryptographic hash of the public key. In some methods, the authentication decision can be omitted from the proof token, as this can be implied from the deblinded blind signature. If the blind signature is not publicly verifiable, then when the proof token issuing server is asked to verify the blind signature (see, for example, as discussed below) Figure 5 (541) proves that the token issuing server can also return a judgment. If the blind signature is publicly verifiable, then the public key used to verify the blind signature also implies a judgment on the device's authentication.

[0169] After the authentication decision for application 400 has been determined and the proof token has been generated, the proof token issuing server 400 uses a blind signature private key to sign each piece of blinded public key data (e.g., every N blinded public keys or every blinded cryptographic hash) and the proof token (425). For example, the proof token issuing server 420 can obtain the blind signature private key corresponding to the authentication decision determined for application 400, such as the blind signature private key corresponding to the public blind signature verification key used for the determined authentication decision. Using the blind signature scheme in this way, the proof token issuing server 420 can generate a digital signature of the blinded public key data without knowing the actual value of the public key data.

[0170] The proof token issuing server 420 returns N blind signatures 413 and the proof token to the client device (426). In some implementations, the proof token is signed using a blind signature scheme, and the N blind signatures 413 comprise the blind-signed proof token. The application 400 receives the blind signatures from the proof token issuing server.

[0171] In some implementations, application 400 can use a blind signature scheme to deblind the blind signature. For example, application 400 can use the blinded public key data for which the blind signature was generated and the blind signature verification key issued by the proof token issuing server 420 to verify each blind signature to validate the validity of the token and ensure that no additional user data other than the authentication decision is encoded in the proof token. To do this, application 400 can attempt to verify the blind signature, for example, using multiple blind signature verification keys for each authentication decision. If a decision does not match the decision assigned to application 400, then the blind signature will not be verified using a blind signature verification key for that decision. The application can determine the authentication decision assigned to application 400 based on the blind signature verification key that successfully verifies the blind signature; for example, the authentication decision corresponding to the blind verification key refers to the decision assigned to application 400. If verified, the application can then use a blind signature scheme to deblind the blind signature.

[0172] Application 400 then stores the proof token (405). For example, a trusted program of application 400 can store the proof token in a secure storage for later use when sending a request that should include the proof token. The secure storage can be a token cache of application 400. As mentioned above, in some implementations, application 400 will attempt to verify the proof token before storage. In some implementations, application 400 will not attempt to verify the proof token before storage and will store the proof token upon receipt.

[0173] After a batch of proof tokens has been stored, such as Figure 4 As shown in the example, the application can then redeem the proof token from the proof token issuing server. Once redeemed, the proof token issuing server provides a redemption result with a signature indicating that the proof token was successfully redeemed, without providing additional user information or other information that could be used to track user activity.

[0174] Upon receiving a signed redemption result, the application can store the signed redemption result as part of a request for access to a content publisher domain, a specific portion of the website, and / or specific content, as well as other requests, as discussed above. An illustrative example of such a request is... Figure 5 It is depicted as a process flowchart.

[0175] To prepare a request, application 500 can, for example, retrieve a signed redemption result from the application's security cache (501). Among various methods, the application can, for example: (1) use a new signed redemption result for each request; or (2) use the same signed redemption result within a selected time interval (e.g., consecutive H hours); or (3) use the same signed redemption result for all requests originating from the same application or website; or (4) reuse a combination of methods using these redemption results (e.g., using the same signed redemption result for all requests originating from the same application or website within a selected time interval). Therefore, application 500 can retrieve a signed redemption result based on the application or website that generated the request or the current time when the request was generated.

[0176] Application 500 can assemble a request 511 comprising a content set including a request payload (as described above), a request creation timestamp indicating when the request was generated, a signed redemption result, and a device public key corresponding to the signed redemption result (e.g., the public key data is blind-signed and included in the signed redemption result along with the deblinded blind signature). The request can also include a digital signature (502) of the content set signed using the application's private key (e.g., a private key corresponding to the public key included in the request). For example, a trusted program of application 500 can generate a digital signature based on the content set using the private key. The request can include a signed redemption result or a redemption result in the form of a signed document. For example, the request can include a content set (e.g., a signed redemption result) and a digital signature.

[0177] Application 500 sends request 511 to the recipient's computing system 520 (503). The recipient can be, for example, a website requesting access or a content hosting platform requesting access to or from the content requested by it.

[0178] The receiver computing system 520 verifies the request (522). The receiver computing system 520 can verify the request by verifying the digital signature of the request using the device public key included with the request. The receiver computing system 520 can also verify the request by comparing the timestamp in the request with the time when the request was received. If the signature is successfully verified and the timestamp is within a threshold duration of the current time, the application 500 can consider the request to be verified.

[0179] The receiver computation system 520 also verifies the redemption result of the signature. This verification process can vary depending on the blind signature scheme used by the proof token issuing server 540 when generating the blind signature. If the blind signature scheme is a publicly verifiable scheme (e.g., RSA), the receiver computation system 520 can verify the redemption result of the signature without invoking the proof token issuing server (523a). In this example, the receiver computation system 520 can use the blind signature scheme to verify the deblinded blind signature of the public key data included in the redemption result of the signature. If a cryptographic hash of the public key is used, the receiver computation system 520 can use the same cryptographic hash function as application 500 to generate the cryptographic hash of the public key included in the request (and truncate it where appropriate), and use the blind signature scheme to verify the deblinded blind signature of the cryptographic hash.

[0180] If the blind signature scheme is a privately verifiable scheme (e.g., IETF VOPRF), then the receiver computation system 520 can invoke the proof token issuing server 540 to verify the deblinded blind signature (523b). In this example, the receiver computation system 520 can send the deblinded blind signature and a public key or a cryptographic hash of the public key to the proof token issuing server 540.

[0181] The token issuing server 540 proves that it can attempt to verify the deblinded blind signature using a blind signature scheme (541). The response can indicate whether the verification was successful, and the level of trust of the client device corresponding to the blind signature verification key used to verify the deblinded blind signature.

[0182] The receiver computation system 520 verifies the timeliness of the redemption result of the signature and the trustworthiness of the client device (524), for example, by confirming that the redemption result of the signature was recently created and by determining that the trustworthiness in the redemption result of the signature is sufficient to approve the request. Because the proof token issuing server 540 can periodically reissue new blind signature verification keys, the timeliness verification can include that the blind signature confirming the redemption result of the signature was not signed using an invalid or outdated key, for example, by determining that the redemption result of the signature was verified using an expired blind signature verification key. In one approach, the receiver computation system can determine that the blind signature verification key has expired because the expiration date of the blind signature verification key is encoded as part of the URL of the issued key. In another approach, the receiver computation system can determine that the blind signature verification key has expired because the verification key is issued along with metadata encoding the expiration date of the verification key.

[0183] If all these validity checks pass, the receiver computing system 520 can respond to the request (525), for example, by providing access to the resource or delivering the resource as discussed above. If any validity check fails, the receiver computing system 520 can ignore the request, for example, by choosing not to send a response to the request, updating settings, etc.

[0184] In addition to the above description, users may be provided with controls that allow them to choose whether and when the system, program, or feature described herein can enable the collection of user information (e.g., information about the user's social networks, social behavior, or activities, occupation, user preferences, or the user's current location) and whether to send personalized content or communications to the user from the server. Furthermore, some data may be processed in one or more ways before it is stored or used, thereby removing personally identifiable information. For example, a user's identity may be processed so that personally identifiable information (e.g., phone number, IMEI, device serial number) cannot be determined for that user, or, if location information is obtained, the user's geographic location may be generalized (e.g., down to the city, zip code, or state level), making it impossible to determine the user's specific location. Therefore, users can control what information is collected from them, how that information is used, information retention policies, and what information is provided to them.

[0185] Figure 6 This is a block diagram of an example computer system 600 capable of performing the operations described above. System 600 includes a processor 610, memory 620, storage device 630, and input / output device 640. Each of components 610, 620, 630, and 640 can be interconnected, for example, using a system bus 650. Processor 610 is capable of processing instructions for execution within system 600. In some implementations, processor 610 is a single-threaded processor. In another implementation, processor 610 is a multi-threaded processor. Processor 610 is capable of processing instructions stored in memory 620 or storage device 630.

[0186] Memory 620 stores information within system 600. In one implementation, memory 620 is a computer-readable medium. In some implementations, memory 620 is a volatile memory cell. In another implementation, memory 620 is a non-volatile memory cell.

[0187] Storage device 630 provides mass storage for system 600. In some implementations, storage device 630 is a computer-readable medium. In various implementations, storage device 630 may include, for example, a hard disk drive, an optical disk drive, a storage device shared by multiple computing devices over a network (e.g., a cloud storage device), or some other mass storage device.

[0188] Input / output device 640 provides input / output operations for system 600. In some implementations, input / output device 640 may include one or more of the following: a network interface device, such as an Ethernet card; a serial communication device, such as an RS-232 port; and / or a wireless interface device, such as an 802.11 card. In another implementation, the input / output device may include a driver device configured to receive input data and send output data to external device 660 (e.g., a keyboard, printer, and display device). However, other implementations, such as mobile computing devices, mobile communication devices, set-top box television client devices, etc., are also possible.

[0189] Although already Figure 6 An example processing system is described herein, but the subject matter and functional operations described herein can be implemented using other types of digital electronic circuit systems, or using computer software, firmware, or hardware (including the structures disclosed herein and their equivalents), or a combination thereof.

[0190] The embodiments of the subject matter and operation described in this specification can be implemented using digital electronic circuit systems, or using computer software, firmware, or hardware (including the structures disclosed in this specification and their equivalents), or a combination thereof. The embodiments of the subject matter described in this specification can be implemented as one or more computer programs, that is, one or more modules of computer program instructions encoded on a computer storage medium (or media) for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively, or additionally, the program instructions can be encoded on artificially generated propagating signals (e.g., machine-generated electrical signals, optical signals, or electromagnetic signals) generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus. The computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination thereof. Furthermore, although the computer storage medium is not a propagating signal, it can be a source or destination of computer program instructions encoded in artificially generated propagating signals. Computer storage media can also be one or more separate physical components or media (e.g., multiple CDs, disks or other storage devices), or be included in one or more separate physical components or media (e.g., multiple CDs, disks or other storage devices).

[0191] The operations described in this specification can be implemented as operations performed by a data processing device on data stored on one or more computer-readable storage devices or received from other sources.

[0192] The term "data processing apparatus" encompasses all kinds of devices, apparatuses, and machines for processing data, including, for example, programmable processors, computers, systems-on-a-chip (SoCs), or multiple programmable processors, computers, or SoCs, or combinations thereof. The apparatus can include dedicated logic circuit systems, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). In addition to hardware, the apparatus can include code that creates an execution environment for the computer program, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. The apparatus and execution environment can implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0193] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but does not necessarily, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to said program, or in multiple coordinating files (e.g., a file storing portions of one or more modules, subroutines, or code). A computer program can be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected via a communication network.

[0194] The processes and logic flows described in this specification can be executed by one or more programmable processors executing one or more computer programs to perform actions by manipulating input data and generating output. The processes and logic flows can also be executed by a dedicated logic circuit system, and the device can be implemented as a dedicated logic circuit system, such as an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit).

[0195] As an example, processors suitable for executing computer programs include both general-purpose microprocessors and special-purpose microprocessors. Typically, a processor receives instructions and data from read-only memory or random access memory, or both. Essential components of a computer are a processor for performing actions according to instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, or devices operatively coupled to receive data from or transfer data to one or more mass storage devices, or a combination thereof; these mass storage devices may be, for example, magnetic disks, magneto-optical disks, or optical disks. However, a computer does not necessarily need to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Processors and memory can be supplemented by dedicated logic circuitry systems or incorporated into dedicated logic circuitry systems.

[0196] To provide interaction with the user, embodiments of the subject matter described herein can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, and a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, voice, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on the user's client device in response to a request received from a web browser.

[0197] Embodiments of the subject matter described herein can be implemented in a computing system, which includes back-end components such as a data server, or middleware components such as an application server, or front-end components such as a client computer having a graphical user interface or web browser that a user can interact with through an implementation of the subject matter described herein, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium, such as a communication network. Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), interconnected networks (e.g., the Internet) and peer-to-peer networks (e.g., self-organizing peer-to-peer networks).

[0198] A computing system can include clients and servers. Clients and servers are typically geographically separated and interact via a communication network. The client-server relationship is established by means of computer programs running on respective computers and having a client-server relationship with each other. In some embodiments, the server transmits data (e.g., HTML pages) to the client device (e.g., for the purpose of displaying data to a user interacting with the client device and receiving user input from the user interacting with the client device). It is possible to receive data generated at the client device (e.g., the result of user interaction) at the server.

[0199] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or potentially claimed content, but rather as descriptions of features specific to particular embodiments of a particular invention. Certain features described in this specification within the context of individual embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented individually in multiple embodiments or in any suitable sub-combination. Furthermore, although features may be described above as functioning in certain combinations and even initially claimed in this way, one or more features from a claimed combination can be removed from that combination in some cases, and the claimed combination may involve sub-combinations or variations thereof.

[0200] Similarly, although operations are described in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific order shown or in sequential order, or requiring all illustrated operations to achieve the desired result. In some cases, multitasking and parallel processing can be advantageous. Furthermore, the separation of various system components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0201] Therefore, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions described in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing can be advantageous.

Claims

1. A method for anonymous proof, comprising: An application on a client device sends a first request for an anonymous proof token to a trusted program, the trusted program having access to the user's credentials for entity authentication, the anonymous proof token being used to prove user authentication for a second content provider; The trusted procedure transmits a token request for the anonymous proof token to the proof token issuing system, the token request including a set of credentials for the user to be verified by the proof token issuing system; The application receives the anonymous proof token from the proof token issuance system, the anonymous proof token comprising: (i) a proof token creation timestamp indicating the creation time of the anonymous proof token; and (ii) a second digital signature of the proof token issuance system; The application receives an authentication request from a first server hosted on a first domain of a first content provider that is different from the second content provider. The authentication request is used to authenticate the user to receive content from a second domain of the second content provider. In response to receiving the authentication request, the application uses the proof token issuance system to redeem the anonymous proof token by sending the anonymous proof token along with the second request to the proof token issuance system. In response to the second request, the application receives a redemption result from the proof token issuance system, the redemption result indicating whether the proof token was successfully redeemed and signed by the proof token issuance system using a digital signature, wherein the redemption result does not include personally identifiable information; and The application transmits the redemption result, signed by the proof token issuance system, to the first content provider.

2. The method according to claim 1, wherein, The second content provider is a news provider. The first content provider is a news aggregator domain, and The redemption result, signed by the proof token issuance system, is transmitted by the application to the first content provider in response to a user action requesting access to resources hosted by the news provider.

3. The method according to claim 1, wherein, The second content provider is a media hosting platform, and The first content provider is a social media platform, and The redemption result, signed by the proof token issuance system, is transmitted by the application to the first content provider in response to a user action requesting access to resources hosted by the media hosting platform.

4. The method according to claim 1, wherein, The second digital signature is created using a private key maintained by the proof token issuance system, and wherein the second digital signature can be verified using a public key, which is (i) corresponding to the private key; and (ii) issued by the proof token issuance system.

5. The method of claim 1, further comprising: The application requests content from the second content provider through the electronic resources of the first content provider.

6. The method of claim 5, further comprising: The application receives the content from the second content provider.

7. The method according to claim 1, wherein, The digital signature of the proof token issuance system is created according to a blind signature scheme.

8. The method according to claim 1, wherein, The digital signature of the proof token issuance system is created using a group signature scheme and an anonymous certificate issued to the client device; and the method further includes: The anonymous certificate is stored in a secure private keystore on the client device.

9. The method according to claim 1, wherein, Transmitting the redemption result signed by the proof token issuance system further includes: providing additional data, which is (i) signed by the application; and (ii) does not associate the user with the credential set.

10. The method according to claim 1, wherein, The token request indicates the number of proof tokens to be issued.

11. The method according to claim 1, wherein, The second request is signed using a private key maintained by the application with a third digital signature, wherein the third digital signature can be verified using a public key, which is (i) corresponding to the private key; and (ii) issued by the application.

12. The method according to claim 1, wherein, The redemption result includes a single bit indicating whether the proof token was successfully redeemed.

13. A system comprising: One or more processors of the client device; as well as One or more memories storing computer-readable instructions configured to cause the one or more processors to perform the method according to any one of claims 1 to 12.

14. A non-transitory computer-readable medium storing instructions that, when executed by one or more computers, cause the one or more computers to perform the method according to any one of claims 1 to 12.

Images