Практическое руководство по проверке доступа для взрослых с ограничением объёма данных, получаемых платформой.

Вашей платформе нужно знать, исполнилось ли посетителю 18 лет. Почему тогда после регистрации у вас остаётся копия его паспорта?
Представим сервис подписки с контентом для взрослых. Пользователь создаёт аккаунт, подтверждает адрес электронной почты, загружает документ и ждёт решения. Ему нужен доступ; бизнесу — надёжная проверка возраста. Но документ может раскрыть имя, фотографию, дату рождения и номер удостоверения. Для решения о доступе нужен более узкий ответ: достиг ли человек установленного возраста?
Эта разница важна для платформ, использующих проверку цифровой личности. Данные, на основании которых устанавливается возраст, не обязательно должны попадать в архив платформы, принимающей решение. Под выражением «без передачи документов» здесь понимается отказ от передачи исходных документов этой платформе. В других частях процесса документы и персональные данные всё равно могут обрабатываться.
Проверка возраста состоит из трёх этапов. Сначала оценивают доказательства: это может быть документ или другой подходящий источник. Затем передают результат, который сообщает, что именно удалось установить. Наконец, принимающая платформа решает, достаточно ли этого результата для нужного действия.
В модели проверяемых цифровых удостоверений W3C различие показано на примере утверждения о достижении возрастного порога вместо передачи точной даты рождения. Получатель узнаёт, соблюдено ли условие, не получая саму дату. Это принцип проектирования, а не описание технологии, которую применяет каждый поставщик услуг.
Поэтому команде платформы полезно сначала определить решение, а затем объём запрашиваемых данных. Формулировка «подтвердить право доступа к этому сервису» гораздо точнее запроса на все доступные сведения о пользователе.
В нашем примере зритель хочет открыть контент для взрослых. Платформе нужно определить применимый возрастной порог, требуемую степень уверенности и сведения, которые ей необходимо сохранить о проведённой проверке.
Это отличается от регистрации автора, которому будут перечисляться выплаты. Для автора могут потребоваться отдельные сведения о личности, компании или праве получать платежи. Успешная проверка возраста зрителя не должна автоматически открывать аккаунт для выплат.
Подтверждение того, что человеку исполнилось 18 лет, само по себе не доказывает, что ему уже 21 год, что он владеет платёжной картой или вправе управлять чужим аккаунтом. Другие решения могут потребовать дополнительных проверок, и цель каждой из них должна быть обозначена отдельно.
В опубликованном соглашении с партнёрами ProperUser описывает передачу платформам статуса проверки и подтверждения возраста. Соглашение исключает передачу партнёрам исходных документов, биометрических данных, видеозаписей, шаблонов лица и загруженных файлов.
Для передачи сведений требуются действие и разрешение пользователя, а также аутентифицированное взаимодействие через API. Принимающая платформа сама решает, предоставить ли доступ, отказать или запросить дополнительную проверку. Её нормативные обязанности остаются за ней; ProperUser не заявляет, что одна проверка удовлетворит все требования конкретного партнёра.
Получить результат вместо исходных материалов полезно лишь тогда, когда команда понимает, что именно этот результат подтверждает.
Предположим, посетитель ввёл одноразовый код из письма, но проверка возраста ещё не завершилась. Можно ли показать ему контент для взрослых? Обычный код из письма или SMS подтверждает доступ к соответствующему каналу связи. Сам по себе он не устанавливает возрастной порог.
Об этом стоит помнить при оценке решений с одноразовыми кодами для платформ. ProperUser описывает подтверждение одноразовым паролем для аутентификации в поддерживаемых приложениях. Если платформа использует и подтверждение возраста, и код, ей необходимо понимать назначение каждого результата. Пользователю также следует объяснить, какой результат запрашивается, какие сведения будут переданы и что произойдёт, если возраст подтвердить не удастся.
Разрешение пользователя на передачу результата не заменяет правового основания для обработки данных, понятной информации о конфиденциальности и правил хранения. Например, британский регулятор ICO требует определить правовое основание до обработки данных для установления возраста.
В нашей предыдущей статье о безопасной проверке личности без раскрытия лишних данных рассматривается более широкий вопрос регистрации. Здесь вопрос уже: что должна получить платформа с возрастным ограничением, чтобы решить, открывать ли доступ?
Если платформа не получает изображение паспорта, это не значит, что другая организация его не обрабатывала. Это также не значит, что сама платформа не узнаёт пользователя по существующему аккаунту, электронной почте или иной активности.
Руководство W3C различает сокращение объёма раскрываемых сведений и невозможность связывать действия одного человека. Постоянные идентификаторы могут соединять отдельные взаимодействия, даже если при каждом раскрывается меньше атрибутов.
Избирательное раскрытие отвечает на вопрос, какие сведения видит получатель. Отсутствие возможности связывать действия отвечает на другой вопрос: можно ли сопоставить отдельные обращения. Подписчик, вошедший в существующий аккаунт, может оставаться узнаваемым для платформы, даже если проверка возраста не раскрывает его имя. Ограничение передачи документов не делает посещение анонимным автоматически.
Поэтому полезно составить карту данных: что собирает каждая сторона, что поступает на платформу, что записывается и кому доступно. Одного обещания не передавать документы недостаточно для ответа на эти вопросы.
Следующие вопросы помогают оценивать интеграцию; они не описывают подтверждённые функции ProperUser.
Уточните возрастной порог и значение каждого статуса. Общее слово «проверен» не обязательно подтверждает возраст, который нужен вашему сервису.
Выясните, как устанавливаются источник и целостность ответа и как он связывается с конкретным запросом. Сообщение об успехе на экране само по себе не является надёжным сигналом для открытия доступа.
Спросите, как система учитывает повторное использование ответа, общие устройства и помощь взрослого несовершеннолетнему. Модель угроз европейского проекта по проверке возраста рассматривает повторное воспроизведение ответа и обход с помощью взрослых. Настоящий результат одного человека не должен превращаться в разрешение для другого. Ни одна проверка не исключает обход полностью.
Различайте отрицательный результат, техническую ошибку и незавершённую проверку. Определите, как каждый случай влияет на доступ. Сбой поставщика не должен незаметно открывать обход обязательной проверки; при этом не следует объявлять пользователя несовершеннолетним лишь потому, что процесс прервался.
Решите, какие сведения о принятом решении необходимы, кто получит к ним доступ и как долго они должны храниться. Проверьте восстановление аккаунта, работу поддержки и другие пути к закрытым разделам: исключение в одном из них может ослабить хорошо устроенный возрастной барьер.
Метод может раскрывать мало данных и при этом не подходить для конкретной обязанности по установлению возраста. Британский регулятор Ofcom относит цифровые сервисы идентификации к методам, которые потенциально могут эффективно определять, исполнилось ли человеку 18 лет. Это не является автоматическим одобрением конкретного поставщика или его внедрения.
В руководстве Ofcom рассматриваются техническая точность, устойчивость к обходу в реальных условиях, надёжность и справедливость, а также доступность и совместимость. Применимые обязанности зависят от сервиса и размещаемого контента; ответственность за действенность процесса остаётся за оператором платформы.
Поэтому при выборе поставщика запрашивайте доказательства, относящиеся именно к вашему сценарию. Заявление «мы не получаем исходные документы» отвечает на вопрос о передаче данных, но не на все вопросы о качестве проверки и управлении доступом.
Разрабатываемое Европейской комиссией решение для проверки возраста — отдельный пример такого подхода. Согласно опубликованному описанию, пользователь может сообщить сайту о достижении возрастного порога без передачи полных сведений о личности. Доступность решения зависит от внедрения государствами или другими поставщиками.
Это не означает, что ProperUser использует европейское решение. Пример показывает направление проектирования: подтвердить признак, необходимый для решения, не раскрывая каждый раз всю личность.
Прежде чем подключать проверку возраста, запишите одним предложением, какой факт должна установить платформа. Затем определите приемлемый результат, действия при ошибке, необходимые записи и условия повторной проверки.
Так легче увидеть пробелы, скрытые за общей отметкой «пользователь проверен». Обсуждая подход с ProperUser, начните с решения о возрасте, которое предстоит принять, и данных, которые действительно нужны вашей платформе. Цель — обоснованный доступ на основе подходящих доказательств без накопления лишних копий документов.
Да. Некоторые подходы отделяют оценку доказательств от результата, получаемого платформой. Достаточность конкретного подхода зависит от метода, внедрения и применимых требований.
Нет. Возрастной порог — более узкий вопрос. KYC может включать установление личности и другие проверки, необходимые для соответствующих отношений или регулируемой деятельности.
Не обязательно. Сведения об аккаунте и другие идентификаторы всё ещё могут позволять узнать человека или связать его действия.
Нет. Платформа должна оценить, соответствуют ли сама проверка и связанные с ней меры требованиям, применимым к её сервису.