System and method for anonymous exchange of age proofs

Abstract

A system and method for facilitating commercial arrangements and anonymous age verification between relying parties and age verification providers. The system maintains user anonymity while verifying age and keeping an anonymous tally of age verifications through a secure application.

Description

System and Method for Anonymous Exchange of Age ProofsCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. serial no. 63 / 667,153 filed on July 3, 2024 entitled SYSTEM AND METHOD FOR ANONYMOUS EXCHANGE OF AGE PROOFS, the subject matter of which is incorporated by reference herein in its entirety.FIELD

[0002] Embodiments relate to systems and methods relating to data security, and, more particularly, data security in connection with verification of user characteristics, such as age, gender, or eye color, by way of non-limiting example, in a networked environment. More particularly, a computerized system and method for facilitating commercial arrangements and enabling anonymous age verification between relying parties and age verification providers, wherein the system maintains user anonymity while verifying age and establishing an anonymous tally of age verifications via a secure application.BACKGROUND

[0003] A wide variety of products, services, commercial spaces and the like are restricted to persons meeting one or more age requirements, such as a minimum age for many contexts, a maximum age, in contexts such as resources intended exclusively for children, or within an age band. Technological issues abound in connection with the goal for having one age check to be used across multiple website, without a user requirement for further actions, all while preserving privacy through anonymity. Further technological issues are associated with obtaining via a networked computer system and associated algorithmic computer processing parental consent, whereby if a child is less than a threshold age (e.g. 13-16 yearsold, dependent upon the law of a member state), a parent’s consent is required before agreement to their personal data being processed.

[0004] Challenges that have arisen include the myriad technical problems associated with the goal of creating applications to store anonymized tokens issued by approved age assurance providers to users who successfully complete certain requirements (e.g. an online age check, using audited and / or certified method(s). Technological gaps including modeling and scalability, untrackability, device based processing, regulatory and technical requirement compatibility, integration with elDAS 2.0 EUDI Wallet, token signing and enablement within a commercial services ecosystem, are but a few of the architectural and technological problems associated with development and deployment of an app, system, method, and infrastructure for computerized age verification and consent.

[0005] Alternative systems and methods addressing one or more of these problems are desired.SUMMARY

[0006] In embodiments, there is provided a secure and anonymous computerized system and method for age verification, allowing relying parties and age verification providers to establish commercial agreements without compromising user privacy. The system maintains an anonymous tally of proofs of age exchanged via a computer application (online or offline app), ensuring data security and user anonymity. This tally is used to keep track of the number of proofs anonymously exchanged between the age verification provider, the verifying user, and the relying party. The tally also facilitates the monitoring and mitigation of malicious activity and supports an age proof blacklisting feature via a gatekeeper service.

[0007] In embodiments, there is provided a system for facilitating commercial arrangements and anonymous age verification, comprising: an application that mediates interactions between relying parties and age verification providers; sending and receiving anonymous age verification requests and confirmations; maintaining an anonymous tally of age verifications; and monitoring and mitigating malicious activity. In one aspect, the application is operative to ensure no personally identifiable information is stored.

[0008] In an embodiment, a computerized system for facilitating commercial arrangements for verifying personal attributes, comprising:an application operative on a user device that mediates interactions between relying parties and age verification providers; an anonymizing service configured to transmit anonymous age verification requests and confirmations; a tally service configured to maintain an anonymous tally of age verification tokens exchanged; and a gatekeeper service operative to monitor token usage and mitigate malicious activity, includingblacklisting of tokens, wherein the application ensures no personally identifiable information is stored or transmitted during any transaction. The system includes means of identifying first and subsequent uses of a token with a particular Relying Party for the purpose of a flexible charging by an Issuer; and wherein a double blind process is implemented where the Relying Party only sees requested attributes included in the token and the identity of the Relying Party is unknown to the Issuer of the token.

[0009] In another embodiment, there is disclosed a method for enabling anonymous age verification via a secure application, comprising: receiving, by an application on a user device, a request for proof of age from a relying party; determining whether a stored cryptographically signed token satisfies the relying party’s proof requirement; if not, transmitting the user to an age verification provider to obtain a new cryptographically signed token; transmitting, via an anonymizing service, a verification package including the token to the relying party; and updating a tally service with the anonymized token hash and associated metadata, wherein all transmissions exclude personally identifiable information and are encrypted in transit and at rest.

[0010] In another embodiment, there is disclosed a system for anonymous age verification, the system comprising: a mobile application operative to store cryptographically signed tokens issued by age assurance providers; an anonymizing service operative to obfuscate the digital service provider endpoint and strip identifiable metadata; a tally service operative to receive anonymized data for commercial tracking of token usage; and a gatekeeper service configured to enforce token usage rules and blacklist misused tokens; wherein the system supports multi-factor authentication and enables zero-knowledge proof mechanisms to verify age qualifications.

[0011] In an embodiment, there is provided a secure application that mediates interactions between relying parties, verifying users, and age verification providers. The process includes the following:1 . User Registration: Users register with the application using non-identifiable credentials.2. Request for Age Verification: A relying party requests an age verification by sending a request for proof signed token through the application.3. Anonymous Verification: The application either matches the request to an existing proof or sends the verifying user to an age verification provider.4. Verification Confirmation: The age verification provider confirms the user's age and sends a cryptographically signed token back to the application in the form of a Verification Package.5. Send Token: The application sends the token via the anonymizing service to the relying party.6. Tallying: The anonymizing service interfaces with the tally service to maintain an anonymous tally of age verification proofs for commercial reporting purposes.The application ensures no personally identifiable information is stored at any stage. The anonymizing layer keeps an anonymous tally of these verifications, facilitating the monitoring and mitigation of malicious activity and supporting an age proof blacklisting feature. The tallying service further provides a means of identifying first and subsequent uses of a token with a particular Relying Party for the purpose of a flexible charging by an Issuer. A double blind process is implemented wherein the Relying Party only seesrequested attributes included in the token, and the Issuer of the token does not know the identity of the Relying Party.

[0012] The Verification Package includes a cryptographically signed token that confirms the user's age without revealing any personal information.

[0013] These technological implementations, at least in combination, provide for a technical solution to the technical challenge of preventing misappropriation of user data provided in connection with anonymous age verification.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a schematic system architecture illustrating the interaction between relying parties, age verification providers, and the application according to an embodiment of the present disclosure.

[0015] FIG. 2 is a flowchart of the age verification process and anonymous tallying according to an embodiment of the present disclosure.

[0016] FIG. 3 is a schematic diagram showing components of an ecosystem useful for implementing the present disclosure.

[0017] FIG. 4 is a schematic flow diagram showing process flow associated with wrappers and tokens within an ecosystem useful for implementing the present disclosure.

[0018] FIGs. 5A-5J illustrate exemplary user displays for steps associated with new user account creation according to an embodiment of the present disclosure.

[0019] FIGs. 6A-6D illustrate exemplary user displays for steps associated with obtaining access for an existing authenticated user according to an embodiment of the present disclosure.

[0020] FIGs. 7A-7C illustrate exemplary user displays for steps associated with obtaining access for an existing user requiring authentication according to an embodiment of the present disclosure.

[0021] FIG. 8 is a more detailed illustration of the system architecture according to an embodiment of the present disclosure.

[0022] FIG. 9 is a more detailed illustration of the software system architecture and infrastructure according to an embodiment of the present disclosure.DETAILED DESCRIPTION

[0023] Disclosed herein are processor-executable methods, computing systems, and related processing relating to data security and verification of age of users in a networked environment. Conventional details of systems known to those of ordinary skill in the art are not shown. Those of ordinary skill in the art may recognize that other elements and / or steps are desirable and / or required in implementing the present invention. However, because such elements and steps are well known in the art, and because they do not facilitate a better understanding of the present invention, a discussion of such elements and steps is not provided herein.

[0024] Embodiments of the systems, methods and devices (apps) disclosed herein provide unconventional technological solutions to the technological challenges of achieving age verification with enhanced security.

[0025] Referring now to FIGs. 1 and 2, in conjunction with FIG. 4, there is provided an anonymous device-based distributed network of AV tokens, that allows for the counting of transactions with traceability of the tokens. As illustrated in FIG. 1 , app 200 is configured to enable a relying party 600 to interact with an app on a user’s device, without leaking identifiable information (including IP address). Age verification provider 100 is operative to create tokens with an associated set of rules so that the app 200 can provide the correct token to the relying party. A tally service 400 is adapted to count the transactions taking place, so that a commercial network ecosystem can exist, without leaking information that can be used to track the user.The tally service 400 allows the network to distinguish between first time and reuse of a token by a relying party. As used herein, the term "relying party" (RP) refers generally to an entity — digital or non-digital — that depends on user verification, authentication, or credentialing as part of a transaction or interaction. This includes, but is not limited to, online service providers, physical access control systems, financial institutions, and governmental agencies.

[0026] In certain embodiments and examples, the term "Digital Service Provider" (DSP) may be used interchangeably with or as a specific example of a Relying Party. References to a DSP should be understood as illustrative of digital implementations of a Relying Party, and not limiting. Unless explicitly indicated otherwise, any description directed to a DSP is intended to also encompass equivalent functionality or roles provided by non-digital Relying Parties.

[0027] The system of the present disclosure comprises a number of services and an app which facilitate the anonymous transfer of digitally signed age proofs from an originating issuer of a verified token, such as an Age Assurance Provider (“AAP”) to a user to Digital Services Provider (“DSP”).

[0028] In an embodiment, there is provided a secure application that mediates interactions between relying parties, verifying users, and age verification providers. Referring to FIG. 2, in conjunction with FIG. 1 , the process includes the following:1 . User Registration: Users register with the application using credentials (block 200). These credentials include, but are not limited to, biometric, PIN or passcode, passkey credentials.2. Request for Age Verification: A relying party ((600) in FIG. 1 ) requests an age verification (block 210) by sending a request for proof signed token through the application.3. Anonymous Verification: The application (200 in FIG. 1.) either matches the request to an existing proof or sends the verifying user to an age verification provider (block 240).4. Verification Confirmation: The age verification provider ((100) in FIG. 1 ) confirms the user's age and sends a cryptographically signed token back to the application in the form of a Verification Package (block 220).5. Send Token: The application sends the token via the anonymizing service ((500) in FIG. 1 ) to the relying party (block 230).6. Tallying: The anonymizing service (block 230) interfaces with the tally service (400) to maintain an anonymous tally of age verification proofs (block 240) for commercial reporting purposes.The application ensures no personally identifiable information is stored at any stage. The anonymizing layer keeps an anonymous tally of these verifications, facilitating the monitoring and mitigation of malicious activity and supporting an age proof blacklisting feature.

[0029] The Verification Package includes a cryptographically signed token that confirms the user's age without revealing any personal information.

[0030] The App (AAP) 200 is the primary means by which a user will interact with the present system. Its main features include creation of accounts that only exist on the device, the creation of proofs via AAPs that only exist on the device, and the facility to transfer these proofs anonymously to a DSP.

[0031] The other services in the present ecosystem include:

[0032] -Maintain a competitive marketplace for AAPs;

[0033] -Facilitate billing and the reconciliation of the exchange of proofs;

[0034] -Maintain a user’s anonymity;

[0035] - Control access and manage the ecosystem.

[0036] System Architecture Overview

[0037] Referring now to FIG. 3, there is illustrated a schematic diagram showing components of an ecosystem useful for implementing the present disclosure. As shown, the contracted issuer is the organization contracted to provide a service (e.g. age assurance) for a relying party (600).

[0038] The originating issuer creates tokens and provides them to the application (App 200). The contracted issuer and the originating issuer may or may not be the same entity. The contracted issuer may generate its own tokens and / or use tokens from other originating issuers when delivering the contracted service to the client.

[0039] The application (200) resides on a physical device belonging to the end user. This is where tokens are stored following a successful verification.

[0040] The gatekeeper I certification authority (300) issues cryptographic keys to ensure that only authorized entities can engage with the network.

[0041] The tally service (400) enables organizations within the network to receive information on the number of checks performed by issuers on behalf of their relying parties, for example, for billing purposes. The information is restricted by organization and only shows the activity relevant to that entity.

[0042] Referring now to FIG. 8 and FIG. 9, the system of the present disclosure is composed of a globally distributed Content Delivery Network (CDN) edge server 800 that serves static application files to internet clients, and a global load balancer 810 which directs dynamic requests to one of four core microservices in the core service layer. These component modules include the following:

[0043] Gatekeeper Service 300 is responsible for controlling Issuer and Relying Party access to the network, blacklisting tokens and referencing relying party configuration locations using data in the Gatekeeper Database.

[0044] PKI Service 350 is configured to handle certificate issuance, revocation, and validation, storing keys and certificate metadata in the PKI Database.

[0045] Anonymization Proxy 500 is configured to intercept sensitive payloads, apply pseudonym ization or redaction rules, and forward the transformed data to an external Relying Party (600).

[0046] Tally Service 400 is operative for aggregating and counting event data, writing results to the Tally Database for durable storage and subsequent reporting.

[0047] All services run on one or more conventional computing devices (each comprising a processor, volatile memory, persistent storage, and network interface) interconnected via a high-speed internal network. The CDN Edge 800 and Global Load Balancer 810 ensure low-latency delivery of both static assets and API calls, while each microservice’s dedicated datastore provides isolation, scalability, and fault tolerance.

[0048] As illustrated herein, functionality associated with the component modules include the following:

[0049] App functionality:

[0050] - Exchanges “request for proof” and “proof” tokens;

[0051] - Creates and authenticates an on-device user account;

[0052] - Renders Issuer Ills in iframes for generating “proof” tokens.

[0053] Execution may be by way of a web application running on the end-user’s mobile or desktop device.

[0054] Issuer Integration SDK functionality:

[0055] - Provides App with methods to request and receive “proof” tokens fromIssuers.

[0056] Execution may be by way of embedded library within the App; the backend API hosted by the Issuer or a third-party.

[0057] Anonymizing Service functionality:

[0058] - Strips or pseudonym izes identifying fields in incoming HTTP requests.

[0059] - Validates that tokens pass through unchanged.

[0060] - Forwards the anonymized payload to the Relying Party.

[0061] - Triggers the Tally Service to increment counts.

[0062] Execution: Stateless containerized microservice behind the global load balancer.

[0063] Tally Service functionality:

[0064] - Maintains counts for each combination of Contracted Issuer, OriginatingIssuer, Relying Party, and token instance.

[0065] - Exposes APIs for reporting and auditing of tallied data.

[0066] Execution: Containerized microservice with a managed database backend.

[0067] PKI Service functionality:

[0068] - Manages public keys used to validate “proof” tokens network-wide.

[0069] - Publishes and revokes keys as needed.

[0070] Execution: Containerized microservice backed by a secure key store and managed database.

[0071] Gatekeeper Service functionality:

[0072] - Authenticates and authorizes Issuers and Relying Parties.

[0073] - Blacklists compromised tokens.

[0074] - Supplies Relying Party configuration (e.g., endpoints, policies).

[0075] Execution: Containerized microservice with its own managed data store.

[0076] Relying Party Integration functionality:

[0077] - Receives and processes “proof” tokens from the Anonymizing Service according to the Relying Party’s business logic.

[0078] Execution: Lightweight SDK loaded into the Relying Party’s backend that may be combined with DNS-level routing adjustments on the Relying Party’s domain.

[0079] System Attributes

[0080] The system and method according to embodiments of the present disclosure implement the following:

[0081] Trust: A Zero Trust architecture is implemented that continuously verifies every user and device in the network. When a Relying Party requires proof, it issues a signed, ephemeral “request for proof” selective disclosure token — issued just-in-time (JIT) and valid only for that transaction. That token, verifiable at each step, travels through the app to the Age Assurance Provider (AAP) without revealing the Relying Party’s identity. The AAP then issues a token, signed by the AAP and bound to the verified device and user, which is returned via the app and an anonymization service. Finally, the originating Relying Party confirms the token’s signature against the network’s registry of AAPs before granting continued access.

[0082] Data Security: All user data is encrypted on the device using strong, industry-standard algorithms before it ever leaves the user’s control. While at rest — whether saved to local storage or to backups — data remains encrypted, and in transit between the app and any backend or service it is protected by transportlayer security (e.g. TLS) to guard against eavesdropping or tampering. No personally identifiable information (PH) is retained by the app or backend. Therefore, no information is available for an attacker to exfiltrate that could directly link data back to an individual. Together, these measures ensure that even if a device is lost, storage media is compromised, or network traffic is intercepted, the contents remain unintelligible without the proper decryption keys, and no user identity can be reconstructed from the stored or transmitted data.

[0083] Authentication: Use of on-device authentication methods, including passcodes and biometrics, to authenticate user access.

[0084] Control: The system and method of the present disclosure empower users with complete control over the use of their age proofs.

[0085] Verifiable: The system and method of the present disclosure utilize digitally signed tokens to provide verifiable proofs of age.

[0086] Anonymous: The system and method of the present disclosure provides that all proofs sent to a DSP are anonymous to protect the user’s identity.

[0087] Environmentally responsible: Infrastructure and functionality (e g. software) that forms part of the ecosystem has a small energy footprint so as to make the most efficient use of resources.

[0088] Anonymizing Service

[0089] The system and method according to embodiments of the present disclosure implement the following:

[0090] The Anonymizing Service processes requests being made to a DSP by the App, by stripping out any personally identifiable information.

[0091] The Anonymizing Service includes an Application Programming Interface (“API”).

[0092] The Anonymizing Service operates to map a unique identifier (ID) to a specific DSP domain endpoint. For example, the unique ID “12345abcdef” links to a specific domain endpoint (e.g. www.adultsite.com / endpoint). This means that DSP’s endpoints are obfuscated to ensure that the user’s device is not exchanging proofs directly with the DSP.

[0093] The IDs and DSP domain endpoint mapping is created when an AAP registers a Relying Party on the network.

[0094] All requests to a DSP through the present App pass through the Anonymizing Service.

[0095] The output from passing a request through the Anonymizing Service is a request that contains only:

[0096] - POST request - IP address of the Anonymizing Service, Content-Type(application / json), Content-Length, Host (e.g. com.anonified.app), the DSP endpoint and the request body (any query strings are stripped).

[0097] - GET request - IP address of the Anonymizing Service, Content-Length,Host (e.g. com.anonified.app) and the DSP endpoint (any query strings should be stripped).

[0098] When a proof passes through the Anonymizing Service it calls the Tally Service with reference for the AAP(s), DSP and the Verification Package hash value.

[0099] Authentication and access to this service API is provided by the Commercial Services Organization (“CSO”) to the AAP.

[0100] AAPs have access to the service API that facilitates the creation, updating or deleting of a DSP endpoint.

[0101] An AAP can only see a DSP endpoint configuration that was either created by the CSO and assigned to the AAP or created by the AAP themselves. They cannot see other AAP’s DSP endpoint configurations

[0102] The CSO has ultimate control over all DSP endpoint configuration entries in the service.

[0103] Tally Service

[0104] The system and method according to embodiments of the present disclosure implement the following:

[0105] The Tally Service (400 in FIG. 1 ) allows for the recording of token, AAP and DSP combinations. This essential part of the system helps to facilitate the reuse of tokens and maintain commercial operations between AAPs and between DSPs and AAPs.

[0106] The Tally Service includes an API.

[0107] The CSO has ultimate control over who has access to the Tally Service and Tally Service API.

[0108] The CSO can delegate restricted access to the Tally Service API so that AAPs can calculate token usage for specific AAP DSP combinations.

[0109] An AAP cannot see another contracted AAP DSP combination token usage.

[0110] An AAP can also see the tally of contracted AAP and issuing AAP combinations for cross charging purposes between AAPs.

[0111] The data stored as part of the tally count comprise: token hash, token classification, contracted AAP ID, issuing AAP ID and DSP Anonymizing Service ID.

[0112] Entries to the tally are added by the Anonymizing Service.

[0113] The Anonymizing Service only has insert access to the Tally Service solely for the purpose of adding count entries.

[0114] No other service or role can add entries to the Tally Service.

[0115] Entries cannot be deleted from the Tally Service. This may be recorded in a distributed ledger (e.g. blockchain).

[0116] AAPs access the tally data through an API endpoint.

[0117] An AAP would specify their DSP Anonymizing Service ID in the request along with a date range. In return they would receive the tally count data including:token classification, contracted AAP ID, issuing AAP ID, total usage count for the token classification, contracted AAP ID and issuing AAP ID combinations.

[0118] An AAP would also specify AAP to AAP token count data. They would receive data on how many times their tokens were used by other AAPs for cross charging purposes.

[0119] The Tally Service has no knowledge of the pricing of any token or commissions paid between AAPs for the re-use of their tokens.

[0120] The tally service allows the network to distinguish between first time and reuse of a token by a relying party. In an embodiment, to determine first vs. subsequent uses of a proof token by an RP, the tally service generates a usage key by hashing together a selectable combination of identifying fields — for example, the Issuing AAP ID (IAAPJD), Relying Party ID (RP_ID), the token’s JWT ID (JTI), and optionally the Consumer AAP ID (CAAPJD). In the instance of first Presentation: If this usage key is not yet in the ledger (table of counts within Tally service), the service creates a new entry with usageCount = 1 and records firstSeen = <timestamp>. For subsequent Presentations: If the key already exists, the module increments usageCount and updates lastSeen = <timestamp>. By exposing usageCount plus the firstSeen / lastSeen timestamps, the RP and Issuer can implement any billing model (per-use, tiered, subscription, overage, etc.) based on whether a token redemption is a first or repeated use.

[0121] Gatekeeper Service

[0122] The system and method according to embodiments of the present disclosure implement the following:

[0123] The Gatekeeper Service facilitates the adding of AAPs and DSPs to allow access to the CSO ecosystem.

[0124] The Gatekeeper Service can use the Tally Service and a set of predefined and agreed rules to check for token misuse. Such rules could include for example, blacklisting a token that exceeds normal usage limits.

[0125] The Gatekeeper Service is operative to blacklist token hashes based on predefined rules and using the Tally Service as the source of data the rules could be applied to.

[0126] Tokens can be individually blacklisted or all tokens from a particular AAP can be blacklisted, e.g., when an AAP loses its certification to participate in the CSO.

[0127] The CSO is the administrator of the Gatekeeper Service.

[0128] The CSO uses the Gatekeeper Service API to add AAPs to the ecosystem.

[0129] The CSO can pause or remove AAPs from the ecosystem.

[0130] The CSO can pause or remove DSPs from the ecosystem. (This is a control, not a function of the CSO).

[0131] AAPs have restricted access to the Gatekeeper Service API (provided and controlled by the CSO) that allows for the adding, pausing and removing of DSPs only.

[0132] An AAP only has control over DSP entries they create.

[0133] PKI Service

[0134] The system and method according to embodiments of the present disclosure implement the following:1.1. A service that provides AAPs and RPs with a means of publishing their public keys for verifying the signed tokens they create on the network.1 .2. The PKI Service is accessed by a restricted private endpoint for AAPs and an unrestricted public endpoint for DSPs.1 .3. The CSO is responsible for the administration of the PKI Service.1 .4. The CSO controls access to the PKI Service.1 .5. An AAP would access the PKI Service via an API.1 .6. A DSP would access the PKI Service via a public endpoint over https or another similarly secure method.1 .7. Other PKI Service criteria:1.7.1. In an embodiment, the service is designed to meet or exceed X.509, RFC 5280 PKI standard.1 .7.2. In an embodiment, the service is designed to meet or exceed Public- Key Cryptography Standards (PKCS) #1, PKCS #10, PKCS #12.1 .7.3. In an embodiment, the service is designed to meet or exceed secure cryptographic algorithms (e.g., RSA 2048-bit, ECC 256-bit, SHA- 256).1 .7.4. In an embodiment, the service is designed to provide secure key generation and storage.1 .7.5. In one embodiment, the service supports periodic cryptographic key rotation, certificate renewal, and automatic expiry enforcement, according to configurable policies set by the governing authority.1.7.6. In an embodiment, the service is designed to follow ETSI standards (e.g., ETSI EN 319 411 )

[0135] 2. Present App

[0136] As shown in FIGs. 5A-5J, The Present App allows a user to create an account that exists on their device only, that requires authentication (e.g., includingbiometric) to restrict access, that only stores data on the device, that encrypts all data stored on the device, that provides a means of the verification of age by certified AAPs that are part of the CSO’s scheme and facilitates the storage and anonymous transfer of digitally signed tokens to a DSP.

[0137] In an embodiment, the user may be prompted to install an appropriate version of the Present App by the first AAP the user accesses which is operating as part of the CSO. It is understood that installation is optional and is not required to use the service.

[0138] The user will only require one app per device, and multiple AAPs can use the same app.

[0139] The user creates an account on their device which is using the Present App. As part of the account creation process the app requests for the creation of a compulsory passcode, username and optional biometric authentication (certain use-cases may require periodic biometric authentication).

[0140] Once an account is created, each time the user opens the app they will be required to authenticate unless the user has given consent for the app to operate continuously throughout a session for certain purposes. This period may be limited by regulation, and DSPs can trigger a requirement for a fresh authentication. Higher levels of assurance may also require fresh authentication as standard.

[0141] All data stored on the app is encrypted.

[0142] There are no cookies or session cookies.

[0143] App and app user data is only stored on the user’s device, with no means to store data off device.

[0144] The app allows for the selection of AAPs shown to be based on the contracted AAPs preferences for each DSP. In an embodiment, only one app isrequired / used for sending proofs to DSPs. The app works with multiple AAPs and each AAP can configure their own preferences based on the contractual agreement with their DSP. A DSP could have contracts with multiple AAPs but they would have to implement multiple integrations (one for each AAP) to access each contracted deal rate. In a preferred embodiment, implementation is through one AAP.

[0145] The level of assurance and any specific requirements from the DSP is passed through to the AAP chosen by the user. All AAPs or methods the app shows to the user should fulfil the requirements of the DSP. The user can only choose between methods and AAPs that meet the requirements of the DSP.

[0146] The user would verify with an AAP chosen from the list of AAPs and in return receive a signed token that is saved on to their device that fulfills the type of verification required by the DSP.

[0147] The app then creates a verification package that contains the level of assurance and any other information required that determines how the token should be used in the wrapper and the token itself. It is to be understood that the token is sent to the DSP, and may include other information such as the request for proof and the proof type that was originally requested / configured.

[0148] If the user has already verified previously the app uses the verification packages to match DSP requests for verification with any existing, suitable tokens provided by AAPs.

[0149] The app will inform the user that the DSP has requested proof and if the user allows it, initiates the transfer of the token to the DSP via the Anonymizing Service.

[0150] The app requires either the scanning of a DSP QR code or entry of a DSP passcode to start the process for transferring a token to prove age. In an embodiment, the app can also be opened via a link. Also, based on a user settingthe SDK (once a user has sent the first proof to a DSP) it is possible to automatically send proofs to other sites without asking.

[0151] The app may be provided as both a PWA, Native App and be able to work with other smart internet connected devices.

[0152] Administration of the app is via the CSO.

[0153] Infrastructure for hosting the app in its various forms may be internationally distributed for optimal performance wherever the user is.

[0154] The CSO is responsible for the maintenance and development of the app.

[0155] There should be no tracking or analytics enabled on the app.irtual Private Networks

[0156] The application is compatible with Virtual Private Network (“VPN”) usage, so that a user who wishes to remain anonymous to the relying party (through the use of a VPN) is not compromising through the use of this technology. The app operates the same way whether a user is browsing using a VPN or not. From the user's perspective they should not have to do anything different.4. Software Development Kit (SDK)

[0157] A Software Development Kit (“SDK”) provides the DSP with the means to integrate their website or service with the CSO ecosystem for proof of age. The SDK may be implemented in a variety of tools and / or libraries to assist with build, compile, run, and debug of applications, such as Java, The DSP uses the SDK to initiate the proof of age process with a user.

[0158] The SDK is provided by the CSO via the AAP to the DSP.

[0159] As part of the files and instructions provided to a DSP, the AAP may also include an encoded configuration file that details the AAPs to be shown in the Present App for a particular DSP and the type of verification required by the DSP.

[0160] Configuration file specification is to be defined by the CSO.

[0161] When initialized this SDK will show a QR code or a passcode to the user. This is used to initiate a proof of age token exchange with the Present App. (for token creation, not authentication).

[0162] 5. Device user journeys5.1 Process on web5.1.1 Opening an account5.1.2 Surfing age-appropriate websites (many in a session).5.2 Process in app6. Verification Package (Wrapper + Token) a. A Verification Package (“VP”) consists of two parts: the wrapper and the token. b. The VP wrapper contains all the information the Present App needs to verify that a supplied token which can include: i. Meets the DSP’s proof criteria — for example, confirming the user’s age falls within an allowed range, the token was issued by a trusted AAP, and the token hasn’t expired or been revoked. ii. Complies with regulatory and policy requirements — such as regional data-protection laws or industry-specific age-verification standards that the DSP must follow. iii. Aligns with the DSP’s business rules — including permitted geographies, approved device types, and any contractual limits on how many proofs can be requested or when they can be requested. iv. Satisfies financial terms — ensuring the request falls within the DSP’s agreed pricing or subscription model (for instance, not exceeding a prepaid proof quota).By embedding these data points in the VP wrapper, the Present App can automatically determine whether a given token is both technically valid and acceptable under the DSP’s legal, operational, and commercial guidelines. c. The token is a digitally signed proof that can be used to prove an 18 or above age. d. Schemas for the VP components:i. System 2.0 VP wrapper. The schema will be defined by the CSO but, in an exemplary embodiment, includes:1. AAP ID (uuidv4 type ID, for example: 758c17d8-2578-4ea5- 9687-970a8373cb0e)2. Level of Age Assurance (lower numbers indicate lower assurance; for example T is the lowest level of assurance)3. [Date of issue] [Expiry Date], for example. ii. System 2.0 Token. The Schema will be defined by the CSO but, in an exemplary embodiment, includes:1. Date of Birth MM DDYYYY. In embodiments, because the token schema is open for the CSO to specify the system may accommodate range proofs. This could take the form of non- interactive zero knowledge proofs. Range proofs can handle above age, below age and between ages. e. Token signing i. AAP is provided with private keys for signing tokens through the PKI Service. f. Token authentication i. DSP has access to the public keys for token authentication through an unrestricted public endpoint. They could be downloaded in advance or served via a CDN. g. It is understood that the wrapper and token schema may evolve over time. The ecosystem should be sufficiently flexible (within certain limitations) to accommodate these changes.h. Administration of schema should be facilitated by the oversight body and involve the CSO and all AAPs. P setup on ecosystem a. For each DSP, the AAP creates a configuration file detailing which AAPs should appear or be used to provide a proof of age, and the level of assurance and any additional specific requirements by the DSP. In embodiments, different ways may be facilitated to preference AAPs and methods. If an AAP requires a specific feature for commercial operation and the CSO agrees, then it may be incorporated into the ecosystem configuration. i. The configuration file should allow the AAP the flexibility to specify commercial and contractually specific details to tailor deals with DSPs. b. The AAP is required to have access to the Gatekeeper Service. c. The AAP has access to read Tally Service (only for specific DSPs and issuing AAPs). d. The AAP is operative to create and digitally sign tokens (with access to the PKI Service). mple User Proof methods a. If a method of proving age such as the Personal Identification Data (“PID”) in the EU Digital Identity Wallet is offered by an AAP then this should result in the creation of a signed token on the user’s App with a high level of assurance reflecting the quality of the source. The verification package assurance level would be set high for this type of token e.g. assuranceLevel = 5. Relying parties may only want to accept tokens with higher levels of assurance. P setup on ecosystem a. The AAP’s responsibilities are as follows: i. To register the DSP on the ecosystem. ii. To provide the DSP with the SDK instructions and configuration file. b. The DSP’s responsibilities: i. Add code and place files as instructed by the AAP. ii. Create an endpoint for the receiving of tokens sent through the anonymization service, including creating signed request for proof tokens and uploading public keys to the PKI service for verifying their request for proof tokens. iii. Authenticating tokens. ryption and data storage a. The present disclosure utilizes strong encryption algorithms which i. Meet or exceed well-established and secure encryption algorithms such as AES-256 for symmetric encryption and RSA-2048 or ECC- 256 for asymmetric encryption. b. Encrypt Data at Rest i. Ensure that all data stored in the app and other services within the ecosystem (in databases, file systems, backups) is encrypted to protect it from unauthorized access. c. Encrypt Data in Transiti. Use TLS (Transport Layer Security) to encrypt data transmitted over networks, ensuring secure communication channels. d. Use Secure Key Storage i. Where it is possible store encryption keys in a secure environment such as Hardware Security Modules (HSMs) or cloud-based key management services (KMS) like AWS KMS or Azure Key Vault. e. Key Rotation i. Regularly rotate encryption keys to minimize the risk of key compromise. Implement automated key rotation policies where possible. f. Key Backup and Recovery i. Implement secure backup and recovery mechanisms for encryption keys to ensure they can be restored in case of loss. g. Separate Key Usage i. Use different keys for different purposes (e.g., separate keys for encryption, signing, and authentication) to reduce risk exposure. h. Principle of Least Privilege i. Grant access to data and encryption keys based on the principle of least privilege, ensuring users and applications have the minimum necessary access. i. Multi-Factor Authentication (MFA) i. Implement MFA for accessing systems that store or manage encryption keys and sensitive data (Tally, Gatekeeper, PKI, Anonymizing services). j. Role-Based Access Control (RBAC)i. Use RBAC to manage permissions and access to data and keys based on user roles within the CSO and associated AAPs. k. Compliance with Standards i. Ensure that your encryption and data storage practices comply with relevant industry standards and regulations such as GDPR, HIPAA, PCI DSS, and NIST. hentication a. Password Minimum Length and Complexity i. Enforce a minimum password length (e.g., 8-12 characters) and require a mix of letters, numbers, and special characters. b. Password Hashing i. Store passwords securely using strong, one-way hashing algorithms like bcrypt, scrypt, or Argon2. c. Password Expiry and Rotation i. Implement policies for periodic password changes and prevent reuse of recent passwords. d. Avoid Common Passwords i. Disallow the use of commonly used passwords (e.g., "password 123") by checking against a known database of common passwords. e. Additional Layers of Security (MFA) i. Use MFA to add an extra layer of security by requiring two or more verification methods (e.g., something the user knows, something the user has, and something the user is). f. MFA Methodsi. Implement methods like SMS-based OTPs, authenticator apps (e.g., Google Authenticator), hardware tokens (e.g., YubiKey), and biometric verification (e.g., fingerprint, facial recognition). g. Email Verification i. When using email verifications, use secure, token-based password reset mechanisms sent to the user’s registered email address. h. Security Questions i. Do not use security questions for password recovery as they are susceptible to social engineering attacks. i. Rate Limiting i. Implement rate limiting to prevent automated attacks on the password recovery mechanism. j. Secure Cookies (not applicable to the present App) i. Use secure cookies with the HttpOnly and Secure flags to protect session cookies from being accessed by client-side scripts and transmitted over non-secure channels. k. Session Expiry i. Set appropriate session timeouts and implement mechanisms for session renewal. l. Logout Functionality i. Ensure a reliable and secure logout process to terminate user sessions. m. Role-Based Access Control (RBAC) i. Assign permissions based on user roles and ensure the principle of least privilege.n. Granular Permissions i. Define fine-grained permissions for accessing various resources and actions within the application. o. Brute Force Protection i. Implement account lockout mechanisms after a certain number of failed login attempts to prevent brute force attacks. p. Monitoring and Alerts i. Monitor authentication attempts and alert users of suspicious activities such as multiple failed login attempts or logins from unusual locations. q. For accessing services (Gatekeeper, Tally, PKI, etc.) by AAPs i. OAuth 2.0 or OpenlD r. For User account creation i. As well as the items detailed in this section, authentication for ecosystem services should also implement best practice authentication as detailed in: ISO / IEC 27002, NIST Special Publication 800-124r2, etc. ck vector mitigation a. Monitoring service should be available for all ecosystem services b. The Gatekeeper Service has an agreed set of rules that are enforced for token usage. c. There should be an audit trail of interactions with the ecosystem services. Including things like login attempts and the types of requests being made by whom and when.d. Automated authentication attack mitigation mechanism inline with requirements in the Authentication section. e. Regular review of system health and security i. This should take the form of both manual and automated reviews.13.Auditinq a. All elements that make up the ecosystem need to be auditable. Auditing should ensure that: i. the security policies in place are effective, active and enforced ii. the process for engaging with the user to verify (via an AAP), producing the signed proof and the transfer of a proof complies with the relevant schemes iii. check that the ecosystem is meeting the agreed pillars for the scheme.13.2 Auditing should be conducted by industry auditors approved by the UK Accreditation Service (or its international equivalents under the ILAC Treaty) and an appropriate approved scheme e.g. the Age Check Certification Scheme (“ACCS”).

[0163] Examples

[0164] A. User Experience

[0165] By way of further non-limiting example, the basic process (for first use) may also be implemented as follows: .1. The basic process (for the first use) is as follows: a. With reference to FIG. 5A, a user attempts to access an age-restricted website or application, collectively termed “digitalservice providers” (DSP). A notification message 510 advising that a characteristic for verification (e.g. age) is required before being granted access to see image 520 (which is blurred out). b. The DSP creates a signed “request for proof” token. This token is a selective disclosure token. There are two parts to the “request for proof”; namely, (1 ): the claim (or disclosure) which is the DSP ID on the network and a random salt; and (2) a signed token that contains a cryptographically processed version of the claim. Both parts are sent to the present App, but only the signed token is forwarded on to the AAP. This ensures that the AAP does not know the identity of the DSP. c. User is directed by the digital service to the present App (a progressive web application website rendered on the User’s device). The present App is specifically designed to provide all the functionality required to facilitate the token exchanges in script that is run only on the User’s device browser. User can authenticate in the app to verify that it is the same person that created the account. In an embodiment, users are automatically logged out after a predetermined interval. The interval is configurable on a per relying party basis and may be different depending on the jurisdiction in which the relying party is operating. Such interval may be specified in the relying party's configuration. As shown, User selection 515 of a request for verification (FIG. 5A) and subsequent selection 518 (FIG. 5B) continues the verification process.d. The User selects an age verification method from one or more possible options 532, 534, 536, 538 (FIG. 5C) and from one or more Providers or AAPs 542, 544, 546 (FIG. 5D) and undergoes an age assurance check (which can be either age verification or age estimation or age inference). e. The selected AAP 546 receives the “request for proof” via the present App without the DSP ID and uses it to validate that it is a genuine “request for proof”. (FIG. 5E). At this point, the AAP has taken control of the screen display. It is to be understood that when the user is interacting with the application the information is going direct to the verification provider and not to the application. Thus, there is a separation of information between the verifier and the application. f. Upon a successful check, with consent, a token is placed on the User’s device (FIG. 5G) and the app 200 regains control of the screen. g. User agrees to submit the token to one or more DSPs. It is to be understood that agreeing to submit a token can be optional, although it is implied when using the service that one is sending a proof / token to the relying parties as a user with whom one is engaging. The example given is with implied consent and sends a proof token to the DSP (FIG. 5G) h. The DSP receives a token (with no personal data beyond the answer to the age-related qualification question due to the function of the Anonymization Service).i. The tally service records this use of an AAPs token with a DSP to enable billing, (see FIG. 5C). j. The User is presented with the option to create an account 572 or just continue without creating an account 574. (FIG. 5G). k. If the User selects “Create an account” the token and user data is encrypted and saved on the User’s device. The authentication mechanism used for creating an account is Passkey and leverages the device’s native biometric authentication 582. (FIG. 5H) l. The User is advised of completion 590 and directed back to the Digital Service to access 520’ if qualified, (see FIG. 51 and FIG. 5J). e basic process (repeat use where the App is already operating on the user’s device) is as follows: a. User attempts to access an age-restricted digital service. The User is either redirected to the present App or prompted to verify with the present App. (see FIG. 6A and FIG. 7A). b. The DSP creates a signed “request for proof” token. This token is a selective disclosure token. There are two parts to the “request for proof”, first is the claim (or disclosure) which is the DSP ID on the network and a random salt, the second part is a signed token that contains a cryptographically processed version of the claim. Both parts are sent to the present App butonly the signed token is forwarded on to the AAP. This ensures that the AAP does not know who the DSP is. c. The present App receives the “request for proof” token and validates that it is genuine, (see FIG. 6B and FIG. 7B). d. If the present App requires the User to reauthenticate as part of the DSP configuration it will prompt the User here (see 582 FIG. 7B). e. The App on the user’s device then checks 630 (FIG. 6B) if a suitable token exists on the device that meets their criteria, (see FIG. 6B and FIG. 7B). f. If the App determines that there is no suitable token, the App then directs the User to undergo a verification with an AAP, as illustrated in FIG. 5C and subsequently in FIG. 5D, FIG. 5E, FIG. 51, and FIG. 5J. g. User agrees to submit the token to one or more DSPs. It is to be understood that agreeing to submit a token can be optional, although it is implied when using the service that one is sending a proof / token to the relying parties as a user with whom one is engaging. The example provided is with implied consent and sends a proof token to the DSP (FIG. 6B and FIG. 7B). h. The DSP receives a token (with no personal data beyond the answer to the age-related qualification question). i. The User is directed by the App back to the Digital Service, (see FIG. 6D and FIG. 7C).ditional features of this system are that: a. Private content of the token is supplied via an anonymization service (operated by the same entity which supplies the application) which prevents the transmission of any personal data other than the “yes” or “no” answer to an age-related question e.g. “Is this user 14 or older?”• The agent can facilitate a number of different token types from simple cryptographically signed tokens to more complex non-interactive zero knowledge proof. b. A tallying service records the usage of each provider’s tokens by each digital service, to facilitate billing for the provision of the age assurance service. c. In one embodiment, the Certification Authority (such as scheme ASBL, by way of non-limiting example) allows only AAPs audited and certified to participate in the ecosystem to issue signed system tokens. e benefits of this approach include: a. A “double-blind” solution:• The digital service being accessed cannot know the identity of the user and the provider cannot know which digital service the user is accessing (the first requirement of being double-blind).• It is “on-device” - the digital service can confirm if the user meets an age qualification without asking a third party toconfirm their age to the digital service directly (which facilitates the second aspect of the double- blind feature).• In one embodiment, the double-blind proof process is implemented as follows:1 . Blind Proof Request: The Relying Party (RP) generates a signed “request for proof” token that includes a separate, cryptographic reference claim. Because the claim is detached, the token can be forwarded to the AAP without revealing the RP’s identity — yet the AAP can still validate the request’s integrity.2. Anonymized Mediation: All messages between the RP and the AAP flow through the user’s App, which strips any identifying metadata. As a result, when the AAP receives the “request for proof” token, it can verify the signature and reference claim but has no way to link the request back to a specific RP. b. The addition of a tallying service enables a sustainable commercial market by giving providers the management information they need to invoice for their services without breaching the double-blind principle. Without a tallying service, the raw design of double-blind operations would mean providers have no information about which digital service was making use of their age assurance services, so would not be able to secure any revenue to fund their operation. c. The Certification Authority maintains high standards across theecosystem by requiring audit and certification before a provider can join the ecosystem. In one embodiment, the certification authority is a neutral not-for-profit entity, which establishes a trust framework between all the providers so digital services have sufficient threshold confidence level that any token has come from a provider which meets the minimum standards for accuracy, privacy and security.1.5. Adoption of this system and method overcomes multiple issues associated with various alternatives, including but not limited to: failures to define a standard for the suppliers of age data, against which they could be audited and certified; AAP and digital services being unable to rely on the quality of age checks from previous unknown sources; lack of sustainable commercial models to deliver age assurance services; requirements for the devices themselves to be sold under certain restrictions (e.g. as restricted to children with the operating system imposing parental controls); and / or utilization of app-store based age checks, however, it is recognized that a single app can be a gateway to a wide-range of content and functionality, suitable for differing age-ranges.

[0166] B. System Components

[0167] By way of further non-limiting example, embodiments may also be implemented as follows: . Tokens2.1 . Tokens are a way to hold and share data securely, in a manner where the contents can be relied upon. a. Tokens have public and private content. b. Tokens provide the information necessary for the App to make decisions on the applicability of a token. c. Tokens are available to the digital service when they contract to pay to access to the present ecosystem, via their relationship with a Provider. d. The actual date of birth is not provided to the digital service; only the answer “yes” or “no” to an age eligibility question, e.g. “is this user over 15?”. e. The App allows a user to create an account that exists on their device only, that requires authentication (including biometric) torestrict access, that only stores data on the device, that encrypts all data stored on the device, that provides a means of the verification of age by certified AAPs that are part of the CSO’s scheme and facilitates the storage and anonymous transfer of digitally signed tokens to a DSP. f. The user will be prompted to install an appropriate version of the present App by the first AAP the user accesses which is operating as part of the CSO. g. The user will only require one app per device, and multiple AAPs can use the same app. h. The user creates an account on their device which is using the present App. As part of the account creation process the app asked for the creation of a compulsory passcode, username and optional biometric authentication (certain use-cases may require periodic biometric authentication). i. Once an account is created, every time the user opens the app they will be required to authenticate unless the user has given consent for the app to operate continuously throughout a session for certain purposes. This period may be limited by regulation, and DSPs can trigger a requirement for afreshauthentication. Higher levels of assurance may also require fresh authentication as standard. j. All data stored on the app is encrypted. k. There are no cookies or session cookies. l. App and app user data is only stored on the user’s device, there should be no means to store data off device. m. The app allows for the selection of AAPs shown to be based on the contracted AAPs preferences for each DSP. n. The level of assurance and any specific criteria for the type of verification requirements by the DSP is passed through to the AAP chosen by the user. o. The user would verify with an AAP chosen from the list of AAPs and in return receive a signed token that is saved on to their device that fulfils the type of verification required by the DSP. p. The app will create a verification package that contains the level of assurance and any other information required that determines how the token should be used in the wrapper andthe token itself (only the token is sent to the DSP). q. If the user has already completed an age check, the app uses the verification packages to match DSP requests for verification with any existing suitable tokens provided by AAPs. r. The app will inform the user that the DSP has requested proof and if the user allows it, initiates the transfer of the token to the DSP via the Anonymizing Service. s. The app requires an activation event such as the scanning of a DSP QR code or entry of a DSP passcode to start the process for transferring a token to prove age. In other embodiments, activation of the app may be accomplished by means of a web link or may be triggered via an RFID tag or reader interaction. t. The app should be provided as both a PWA, Native App and be able to work with other smart internet connected devices. u. Administration of the app is via the CSO. v. Infrastructure for hosting the app in its various forms should be internationally distributed for optimal performancewherever the user is. w. The CSO is responsible for the maintenance and development of theapp. x. There should be no tracking or analytics enabled on the app. y. The app and its associated Anonymizing Service are contestable elements of the ecosystem.

[0168] By way of further non-limiting example, embodiments may also be implemented as follows: . Application Agent3.1. The Application allows a device to store system approved / authorized tokens.(a) A number of agents will be developed for different devices and operating systems. Initially, these will be created for use across:• operating systems■ Apple iOSAndroid• Smartphones• Tablets• Desktop and laptops■ PCs■ Apple Macs• Games consoles■ Sony PlayStation;■ Nintendo Switch;• Xbox

[0169] By way of further non-limiting example, embodiments may also be implemented as follows: . Anonymization Service4.1 . The purpose of this service is to prevent the transmission of personally identifiable information (PI I) between the user and the digital service.• This is achieved by removing data including IP addresses,User-Agent and any other information that could be used to personally identify the user from the request.• The Anonymizing Service processes requests being made to a DSP by the present App, stripping out any PH. b. The Anonymizing Service has an Application Programming Interface (“API”). c. It maps a unique identifier to a specific DSP domain endpoint. For example,“12345abcdef” would link to“www.adultsite.com / endpoint”. This means that DSP’s endpoints are obfuscated to ensure that the user’s device is not exchanging proofs directly with the DSP. d. The IDs and DSP domain endpoint mapping is created when an AAP registers a Relying Party on the network. e. All requests to a DSP through the App pass through the Anonymizing Service. f. The output of passing a request through the AnonymizingService should be a request that contains only:• POST request - IP address of the Anonymizing Service, Content-Type (application / Json), Content-Length, Host (com.anonified.app), the DSP endpoint and the request body (any query strings should bestripped).• GET request - IP address of the Anonymizing Service, Content-Length, Host (com.anonified.app) and the DSP endpoint (any query strings should be stripped). g. When a proof passes through the Anonymizing Service it should call the Tally Service with reference for the AAP, DSP and the Verification Package (see section 12) hash value. h. Authentication and access to this service API is provided by the Commercial Services Organization (“CSO”) to the AAP. i. AAPs have access to the service API that facilitates the creation, updating or deleting of a DSP endpoint. j. An AAP can only see a DSP endpoint configuration that was either created by the CSO and assigned to the AAP or created by the AAP themselves. They cannot see other AAP’s DSP endpoint configurations. k. The CSO has ultimate control over all DSP endpoint configuration entries in the service.

[0170] By way of further non-limiting example, embodiments may also be implemented as follows: . Tallying Service5.1 . The purpose of this service is to be a trusted source of management information about which provider tokens have been used by which digital service. a. Providers (or a shared commercial scheme - see below) can then issue invoices to those digital services. b. The Tally Service allows for the recording of token, AAP and DSP combinations. This is an essential part of the ecosystem that helps to facilitate the reuse of tokens and maintain commercial operations between AAPs and between DSPs and AAPs. c. The Tally Service has an API. d. The CSO has ultimate control over who has access to the Tally Service and the Tally Service’s API.The CSO can delegate restricted access to the TallyService API so that AAPs can calculate token usage forspecific AAP DSP combinations.• An AAP cannot see another contracted AAP DSP combination token usage.• An AAP can also see the tally of contracted AAP and issuing AAP combinations for cross charging purposes between AAPs. e. The data stored as part of the tally count is: the token hash, token classification, contracted AAP ID, issuing AAP ID and DSP Anonymizing Service ID. f. Entries to the tally are added by the Anonymizing Service.• The Anonymizing Service has direct and restricted access to the Tally Service solely for the purpose of adding count entries.• No other service or role can add entries to the Tally Service. g. Entries cannot be deleted from the Tally Service which could be recorded in a distributed ledger. h. AAPs access the tally data through an API endpoint.• An AAP would specify their DSP Anonymizing Service ID in the request along with a date range. In return theywould receive the tally count data including: token classification, contracted AAP ID, issuing AAP ID, total usage count for the token classification, contracted AAP ID and issuing AAP ID combinations.• An AAP would also specify AAP to AAP token count data. They would receive data on how many times their tokens were used by other AAPs for cross charging purposes.• The Tally Service has no knowledge of the pricing of any token or commissions paid between AAPs for the re-use of their tokens.

[0171] By way of further non-limiting example, embodiments may also be implemented as follows: . Gatekeeper Service6.1. The Gatekeeper Service facilitates the adding of AAPs and DSPs to allow access to the CSO ecosystem. a. The Gatekeeper Service can use the Tally Service and a set of predefined and agreed rules to check for token misuse.The Gatekeeper Service can blacklist token hashes basedon predefined rules and using the Tally Service as the source of data the rules could be applied to.• Tokens can be individually blacklisted or all tokens from a particular AAP can be blacklisted, e.g. when an AAP loses its certification to participate in the CSO. b. The CSO is the administrator of the Gatekeeper Service. c. The CSO would use the Gatekeeper Service API to add AAPs to the ecosystem. d. The CSO can pause or remove AAPs from the ecosystem. e. The CSO can pause or remove DSPs from the ecosystem (this is a control, not a function of the CSO). f. AAPs have restricted access to the Gatekeeper Service API (provided and controlled by the CSO) that allows for the adding, pausing and removing of DSPs only.• An AAP only has control over DSP entries they create.

[0172] By way of further non-limiting example, embodiments may also be implemented as follows:PKI Service7.1 . The PKI Service is for serving public keys provided by AAPs andRPs for the purpose of authenticating tokens. a. The PKI Service is accessed by a restricted private endpoint for AAPs and an unrestricted public endpoint for DSPs. b. The CSO is responsible for the administration of the PKI Service. c. The CSO controls access to the PKI Service. d. An AAP would access the PKI Service via an API. e. A DSP would access the PKI Service via a public endpoint over https or another similarly secure method. f. Other PKI Service criteria:• Meet or exceed X.509, RFC 5280• Meet or exceed PKCS #1 , PKCS #10, PKCS #12• Meet or exceed secure cryptographic algorithms (e.g., RSA2048— bit, ECC 256-bit, SHA-256)• Secure key generation and storage• Regular key rotation, renewal processes and certificate expiry - policy to be set by the System / control AuthorityFollow ETSI standards (e.g., ETSI EN 319411 )

[0173] By way of further non-limiting example, embodiments may also be implemented as follows: . Service Configuration8.1. The software is configurable to allow the Provider to exercise choice overwhich tokens it uses, so it can fulfil its contract obligations to Digital Services. This will include, but is not limited to: a. Level of assurance required b. Maximum Price c. Preferred Providers d. Excluded Providers.8.2. The Digital Services software ecosystem removes the direct relationship between a digital service and an AAP, so the digital service implements software to allow it to look for tokens, choose between them, and ask them age qualification questions.8.3. The digital service will be able to set the following parameters:a. Limiting which provider tokens to use b. A maximum price it is willing to pay for each level of age assurance c. A preference for a particular provider or providers (for example, bulk buys)

[0174] By way of further non-limiting example, embodiments may also be implemented as follows:9. JavaScript Software Development Kit (“SDK”)The JavaScript Software Development Kit (“SDK”) provides the DSP with the means to integrate their website or service with the CSO ecosystem for proof of age. a. The DSP uses the SDK to initiate the proof of age process with a user. b. The SDK is provided by the CSO via the AAP to the DSP. c. As part of the files and instructions provided to a DSP, the AAP should also include an encoded configuration file that details the AAPs to be shown in the App for a particular DSP and the type of verification required by the DSP. d. Configuration file specification to be defined by the CSO.e. When initialized this SDK will show a QR code or a passcode to the user. This is used to initiate a proof of age token exchange with the App.AAP Software - Each provider needs to be able to create system authorized tokens in the required format, and to sign them using their private key, corresponding to a public key held by the Certification Authority and made available to digital services to authenticate the tokens they choose to use. AAP setup on ecosystem - For each DSP, the AAP should create a configuration file which can detail which AAPs should appear or be used to provide a proof of age and the level of assurance and any additional specific criteria required for the type of proof requirements by the DSP. a. The configuration file allows the AAP the flexibility to specify commercial and contractually specific details to tailor deals with DSPs. b. The AAP has access to the Gatekeeper Service. c. The AAP has access to read the Tally Service (only for specific DSPs and issuing AAPs). d. The AAP is able to create and digitally sign tokens (withaccess to the PKI Service).

[0175] By way of further non-limiting example, embodiments may also be implemented as follows: 0. Verification Package (Wrapper + Token)10.1 . A Verification Package (“VP”) consists of two parts: the wrapper and the token.10.2. The VP wrapper contains data that is used by the present App to determine whether a token matches a DSP’s proof requirement and is commercially acceptable.10.3. The token is a digitally signed proof that can be used to prove an age requirement. (Initially this will be x+ e.g. 5+, 13+, 16+, 18+, 21 + but the design can accommodate <x and age-ranges).10.4. Schemas for the VP components: a. System 2.0 VP wrapper. The Schema will be defined by the CSO but is expected to include:• AAP ID• Level of Age Assurance[Date of issue] [Expiry Date] b. System 2.0 Token. The Schema will be defined by the CSO but is expected to include:• Date of Birth MMDDYYYY10.5. Token signing a. AAP is provided with private keys for signing tokens through the PKI Service.10.6. Token authentication a. DSP has access to the public keys for token authentication through an unrestricted public endpoint.10.7. Administration of the schema should be facilitated by the oversight body and involve the CSO and all AAPs.10.8. Example User Proof methods a. If a method of proving age such as the Personal Identification Data (“PID”) in the EU Digital Identity Wallet is offered by an AAP, then this should result in the creation of a signed token on the users’ App with a high level of assurance reflecting the quality of the source. The verification package assurance level would be set high for this type of token e.g. assurance Level =5. Relying parties may only want to accept tokens with higher levels of assurance.

[0176] DSP Setup on ecosystem

[0177] By way of further non-limiting example, embodiments may also be implemented as follows:

[0178] The AAP’s responsibilities include:

[0179] A) register the DSP on the ecosystem;

[0180] B) provide the DSP with the SDK instructions and configuration file.

[0181] The DSP’s responsibilities include:

[0182] A) Add code and place files as instructed by the AAP.

[0183] B) Create endpoint for receiving tokens sent through the anonymization service.

[0184] C) Authenticating tokens.

[0185] Encryption and Data Storage

[0186] By way of further non-limiting example, embodiments may also be implemented as follows:Use Strong Encryption Algorithms i. Meet or exceed well-established and secure encryption algorithms such as AES-256 for symmetric encryption and RSA-2048 or ECC-256 for asymmetric encryption.Encrypt Data at Rest ii. Ensure that all data stored in the app and other services within the ecosystem (in databases, file systems, backups) is encrypted to protect it from unauthorized access.Encrypt Data in Transit iii. Use TLS (Transport Layer Security) to encrypt data transmitted over networks, ensuring secure communication channels.Use Secure Key Storage iv. Where it is possible store encryption keys in a secure environment such as Hardware Security Modules (HSMs) or cloud-based key management services (KMS) like AWS KMS or Azure Key Vault.Key Rotation v. Regularly rotate encryption keys to minimize the risk of key compromise. Implement automated key rotation policies where possible.Key Backup and Recovery vi. Implement secure backup and recovery mechanisms for encryption keys to ensure they can be restored in case of loss.Separate Key Usage vii. Use different keys for different purposes (e.g., separate keys for encryption, signing, and authentication) to reduce risk exposure.Principle of Least Privilege viii. Grant access to data and encryption keys based on the principle of least privilege, ensuring users and applications have the minimum necessary access.Multi-Factor Authentication (MFA) ix. Implement MFA for accessing systems that store or manage encryption keys and sensitive data (Tally, Gatekeeper, PKI, Anonymizing services).Role-Based Access Control (RBAC) - Use RBAC to manage permissions and access to data and keys based on user roles within the CSO and associated AAPs.Compliance with Standards - Ensure that your encryption and data storage practices comply with relevant industry standards and regulations such as GDPR, HIPAA, PCI DSS, and NIST.

[0187] Authentication

[0188] By way of further non-limiting example, embodiments may also be implemented as follows:

[0189] Password Minimum Length and Complexity.

[0190] A. Enforce a minimum password length (e.g., 8-12 characters) and require a mix of letters, numbers, and special characters.

[0191] Password Hashing.

[0192] A. Store passwords securely using strong, one-way hashing algorithms like bcrypt, scrypt, or Argon2.

[0193] Password Expiry and Rotation.

[0194] A. Implement policies for periodic password changes and prevent reuse of recent passwords.

[0195] Avoid Common Passwords.

[0196] A. Disallow the use of commonly used passwords (e.g., "password 123") by checking against a known database of common passwords.

[0197] Additional Layers of Security (MFA).

[0198] A. Use MFA to add an extra layer of security by requiring two or more verification methods (e.g., something the user knows, something the user has, and something the user is).

[0199] MFA Methods.

[0200] A. Implement methods like SMS-based OTPs, authenticator apps (e.g., Google Authenticator), hardware tokens (e.g., YubiKey), and biometric verification (e.g., fingerprint, facial recognition).

[0201] Email Verification

[0202] A. When using email verifications, use secure, token-based password reset mechanisms sent to the user’s registered email address.

[0203] Security Questions

[0204] A. Do not use security questions for password recovery as they are susceptible to social engineering attacks.

[0205] Rate Limiting

[0206] A. Implement rate limiting to prevent automated attacks on the password recovery mechanism.

[0207] Secure Cookies (not applicable to the present App).

[0208] Thus, there is disclosed a computerized system for facilitating commercial arrangements for verifying personal attributes, comprising: an application operative on a user device that mediates interactions between relying parties and age verification providers; an anonymizing configured to transmit anonymous age verification requests and confirmations; a tally service configured to maintain an anonymous tally of age verification tokens exchanged; and a gatekeeper service operative to monitor token usage and mitigate malicious activity, including blacklisting of tokens; wherein the application ensures no personally identifiable information is stored or transmitted during any transaction; means of identifying first and subsequent uses of a token with a particular Relying Party; and wherein a double blind process is implemented where the Relying Party only sees requested attributes included in the token and the identity of the Relying Party is unknown to the Issuer of the token.

[0209] In an embodiment, the anonymizing service maps a unique identifier to a domain endpoint associated with a relying party.

[0210] In an embodiment, the tally service stores token classification, issuing provider ID, and anonymizing service ID in a digital ledger.

[0211] In an embodiment, the tokens are valid for a predefined time period and classified by level of age assurance.

[0212] In an embodiment, the gatekeeper service is administered by a central services organization configured to manage access to the anonymizing and tally services.

[0213] There is further disclosed a method for enabling anonymous age verification via a secure application, comprising: receiving, by an application on a user device, a request for proof of age from a relying party; determining whether a stored cryptographically signed token satisfies the relying party’s proof requirement; if not, transmitting the user to an age verification provider to obtain a new cryptographically signed token; transmitting, via an anonymizing service, a verification package including the token to the relying party; and updating a tally service with the anonymized token hash and associated metadata, wherein all transmissions exclude personally identifiable information and are encrypted in transit and at rest.

[0214] In an embodiment, the method further comprises prompting the user to authenticate using biometric or passcode credentials before transmitting the token.

[0215] In an embodiment, the cryptographically signed token comprises a non- interactive zero-knowledge proof of age eligibility.

[0216] There is further disclosed a system for anonymous age verification, the system comprising: a mobile application operative to store cryptographically signed tokens issued by age assurance providers; an anonymizing service operative to obfuscate the digital service provider endpoint and strip identifiable metadata; a tally service operative to receive anonymized data for commercial tracking of token usage; and a gatekeeper service configured to enforce token usage rules and blacklist misused tokens; wherein the system supports multi-factor authentication and enables zero-knowledge proof mechanisms to verify age qualifications.

[0217] In an embodiment, the application ensures no personally identifiable information is stored.

[0218] In an embodiment, the verification package includes a wrapper indicating level of assurance and expiry date.

[0001] In an embodiment, the anonymizing service strips IP address, user agent, and query strings from the transmitted request.

[0002] While embodiments have been described in connection with verification of age, verification of other user characteristics may also be implemented, including but not limited to verification of gender, or eye color, hair color, or other user characteristics, by way of non-limiting example. The embodiments described herein are solely for the purpose of illustration. Those in the art will recognize that other embodiments may be practiced with modifications and alterations.

Claims

CLAIMSWhat is claimed is:

1. A computerized system for facilitating commercial arrangements for verifying personal attributes, comprising: an application operative on a user device that mediates interactions between relying parties and age verification providers; an anonymizing service configured to transmit anonymous age verification requests and confirmations; a tally service configured to maintain an anonymous tally of age verification tokens exchanged; and a gatekeeper service operative to monitor token usage and mitigate malicious activity, including blacklisting of tokens; wherein the application ensures no personally identifiable information is stored or transmitted during any transaction; means of identifying first and subsequent uses of a token with a particular Relying Party for the purpose of a flexible charging by an Issuer; and wherein a double blind process is implemented where the Relying Party only sees requested attributes included in the token and the identity of the Relying Party is unknown to the Issuer of the token.

2. The system of claim 1 , wherein the anonymizing service maps a unique identifier to a domain endpoint associated with a relying party.

3. The system of claim 1 , wherein the tally service stores token classification, issuing provider ID, and anonymizing service ID in a digital ledger.

4. The system of claim 1 , wherein the tokens are valid for a predefined time period and classified by level of age assurance.

5. The system of claim 1 , wherein the gatekeeper service is administered by a central services organization configured to manage access to the anonymizing and tally services.

6. A method for enabling anonymous age verification via a secure application, comprising: receiving, by an application on a user device, a request for proof of age from a relying party; determining whether a stored cryptographically signed token satisfies the relying party’s proof requirement; if not, transmitting the user to an age verification provider to obtain a new cryptographically signed token; transmitting, via an anonymizing service, a verification package including the token to the relying party; andupdating a tally service with the anonymized token hash and associated metadata, wherein all transmissions exclude personally identifiable information and are encrypted in transit and at rest.

7. The method of claim 6, further comprising prompting the user to authenticate using biometric or passcode credentials before transmitting the token.

8. The method of claim 6, wherein the cryptographically signed token comprises a non- interactive zero-knowledge proof of age eligibility.

9. A system for anonymous age verification, the system comprising: a mobile application operative to store cryptographically signed tokens issued by age assurance providers; an anonymizing service operative to obfuscate the digital service provider endpoint and strip identifiable metadata; a tally service operative to receive anonymized data for commercial tracking of token usage; and a gatekeeper service configured to enforce token usage rules and blacklist misused tokens; wherein the system supports multi-factor authentication and enables zeroknowledge proof mechanisms to verify age qualifications.

10. The system of claim 9, wherein the application ensures no personally identifiable information is stored.11 . The system of claim 9, wherein the verification package includes a wrapper indicating level of assurance and expiry date.

12. The system of claim 9, wherein the anonymizing service strips IP address, user agent, and query strings from the transmitted request.

Images