Проверьте протокол проверки электронной почты с помощью пробной версии.

Rowan Merewood

Опубликовано: 8 июля 2026 г.

При сборе адреса электронной почты в рамках регистрации, входа в систему, подписки, оформления заказа, восстановления учетной записи или других процессов обычно требуется подтверждение того, что адрес электронной почты принадлежит человеку, который его вводит. Существующие методы проверки, такие как одноразовые пароли (OTP) или ссылки для подтверждения по электронной почте (магические ссылки), требуют от пользователя перехода на другой сайт. Этот неудобный процесс может увеличить риск того, что пользователь, будь то человек или агент, полностью прервет свою сессию и так и не завершит процесс аутентификации.

API проверки электронной почты — это предложение, позволяющее браузеру напрямую взаимодействовать с почтовым провайдером для проверки того, что пользователь действительно является владельцем адреса электронной почты. Пользователи выбирают адрес электронной почты из подсказок автозаполнения браузера, отправляют форму, и сайт проверяет адрес электронной почты у провайдера без отправки электронного письма и без прерывания процесса пользователя.

Сбор адресов электронной почты — это критически важный этап в процессе взаимодействия пользователя с сайтом, и Chrome хотел бы получить отзывы о предложении от сайтов, желающих проверять адреса электронной почты, от почтовых провайдеров, которые могут выполнять эту проверку, и от пользователей, уже знакомых с этим процессом. Вы можете зарегистрироваться для участия в пробной версии Origin уже сегодня и следовать инструкциям по внедрению здесь. Общие сведения о настройке пробной версии Origin см. в разделе «Начало работы с пробными версиями Origin» .

Вы можете протестировать процесс, используя демо-аккаунт:

• Демонстрационная версия для эмитентов предоставляет вам фиктивный адрес электронной почты и сессию.
• Демонстрационная версия Verifier позволит проверить любого участвующего поставщика.

Процесс подтверждения электронной почты

В следующих разделах объясняется, что вам и вашим пользователям необходимо для запуска процесса подтверждения электронной почты, а также весь рабочий процесс при использовании протокола подтверждения электронной почты.

Ключевые термины

Ключевые термины для API подтверждения электронной почты следующие:

• Верификатор : Сайт, который собирает адрес электронной почты и хочет его проверить. Верификатор также называется проверяющей стороной .
• Поставщик услуг электронной почты : Сервис, предоставляющий адрес электронной почты пользователя, например gmail.com .
• Эмитент : Сервис, управляющий учетной записью электронной почты пользователя, например accounts.google.com . Эмитента также называют поставщиком идентификационных данных .

В некоторых случаях почтовый провайдер и отправитель могут работать в одном домене. Однако важно различать наличие адреса электронной почты и наличие активной сессии для связанной с ним учетной записи.

Предварительные требования

• Пользователь должен быть авторизован в своей учетной записи почтового провайдера или эмитента в том же профиле браузера. Например, если он использует Gmail, он должен быть авторизован в своей учетной записи Google.
• В качестве участвующего сайта-верификатора вы должны зарегистрироваться для участия в пробном периоде и предоставить токен на той же странице, что и форма для отправки электронного письма.

• Пользователь должен выбрать свой адрес электронной почты из выпадающего списка автозаполнения или автоподполнения.

  • Если пользователь ранее вводил адрес электронной почты в это поле, он будет предложен с помощью функции автозаполнения.

  • Если пользователь добавил свой адрес электронной почты через настройки Chrome в разделе «Автозаполнение и пароль» ( chrome://settings/autofill ), то он будет предложен для автозаполнения.

• При первом вводе адреса электронной почты для подтверждения пользователь увидит запрос на предоставление разрешения. Это происходит только один раз для каждого адреса электронной почты.

Как только у пользователя будет активная сессия в браузере, он может начать процесс:

1. В форме с полем для ввода адреса электронной почты пользователь выбирает свой адрес электронной почты из выпадающего списка автозаполнения. Сайт проверки предоставляет в форме скрытое поле с одноразовым кодом (nonce) для проверки этого запроса.

2. Затем браузер получит DNS-запись подтверждения электронной почты для почтового домена. Это укажет браузеру на отправителя. Отправитель подтвердит наличие активной сессии для этого адреса электронной почты.

3. Затем эмитент предоставит свой токен подтверждения электронной почты (EVT) для этого адреса. Браузер объединит его с токеном EVT, источником сайта и одноразовым кодом (nonce) из формы ввода в JWT, привязав к нему ключ.

4. После отправки формы пакет EVT добавляется в скрытое поле и отправляется на сайт.

5. Затем сайт-верификатор проверяет каждую из этих деталей: ожидаемый адрес электронной почты, одноразовый код (nonce) и подписи браузера и эмитента.

6. Пользователь видит небольшое уведомление о том, что его почтовый провайдер подтвердил его адрес.

Этот процесс предоставляет сайту-верификатору подтверждение того, что адрес электронной почты действителен и принадлежит текущему пользователю, что позволяет сайту не отправлять подтверждающее письмо.

Пользователи могут управлять своими подтвержденными адресами электронной почты в разделе «Настройки» > «Автозаполнение и пароли» > «Контактная информация» > «Подтвержденный адрес электронной почты» (или откройте chrome://settings/contactInfo ).

Рассмотрение вариантов использования

Подтверждение электронной почты — это постепенное улучшение существующего процесса, устраняющее необходимость для пользователя покидать ваш сайт для получения одноразового пароля (OTP) или перехода по ссылке. Сайты могут добавлять поля подтверждения электронной почты во все соответствующие формы, такие как формы входа, подписки на рассылку, создания учетной записи и восстановления пароля. Подтверждение электронной почты срабатывает только в том случае, если браузер его поддерживает. Если код не получен при отправке или какой-либо из этапов проверки не пройден, вы можете вернуться к стандартному процессу подтверждения по электронной почте. Это также означает, что для API не предусмотрено определение функций; сайт-верификатор рассматривает подтверждение электронной почты как необязательное, обрабатывая его, если оно присутствует в запросе.

Подтверждение электронной почты показывает, что у пользователя активная сессия с провайдером его почтового адреса. Оно не подтверждает, что ваше письмо дошло до пользователя. Возможно, вам все еще нужно отправлять существующие приветственные или ознакомительные письма, и вы можете захотеть или нуждаться в том, чтобы предложить пользователю проверить настройки спама.

Внедрить сайт верификатора

Для получения более подробной информации вы можете ознакомиться с полным кодом демонстрационного примера и шагами проверки, описанными в предложениях по API и протоколу проверки электронной почты .

Настройка полей формы

Убедитесь, что поля вашей формы имеют правильные атрибуты:

<input
  name="email-address"
  type="email"
  autocomplete="email">
<input
  type="hidden"
  name="token"
  nonce="rAnD0m-VaLuE"
  autocomplete="email-verification-token">

Установите атрибуты type и autocomplete для поля ввода email на email , чтобы браузер мог предлагать автозаполнение для адреса электронной почты.

Новое hidden поле будет заполнено токеном подтверждения электронной почты при отправке формы. Необходимые атрибуты:

• Установите type="hidden" поскольку это поле не требует ввода данных пользователем.
• Установите nonce="rAnD0m-VaLuE" . Сайт должен предоставить уникальный nonce, привязанный к сессии, для проверки отправки формы.
• Установите autocomplete="email-verification-token" . Браузер использует этот атрибут для идентификации поля, которое необходимо заполнить.

Проверьте элементы формы, отметив раздел «Сеть» в инструментах разработчика. При выборе адреса электронной почты браузер запускает DNS-запросы и последующие запросы на поиск учетной записи у поставщика и отправителя электронной почты. Это внутренние запросы браузера; ваш сайт ничего не получает до момента отправки формы.

Проверьте EVT

Для проверки каждого компонента пакета EVT необходимо выполнить пять шагов.

1. Разберите токен.
2. Проверьте ожидаемые значения.
3. Проверьте привязку клавиш.
4. Проверьте DNS-запись.
5. Определите эмитента и проверьте подпись EVT.

1. Разберите токен.

Исходные данные из отправленной формы содержат EVT и подписанные утверждения в формате JSON Web Token (SD-JWT+KB) с выборочным раскрытием, разделенные тильдой (символ ~ ). Вам потребуется разделить их и декодировать заголовки и полезные нагрузки Javascript Object Signing and Encryption (JOSE) (например, используя jose для Node.js).

Если example.com подтвердит подлинность demo@gmail.com , расшифрованная полезная нагрузка будет выглядеть примерно так:

{
  "evtJwtDecodedPayload": {
    "cnf": {
      "jwk": {
        "crv": "Ed25519",
        "kty": "OKP",
        "x": "pUbLiCkEy123pUbLiCkEy123pUbLiCkEy123"
      }
    },
    "email": "demo@gmail.com",
    "email_verified": true,
    "iat": 1782911685,
    "iss": "https://accounts.google.com"
  },
  "kbJwtDecodedPayload": {
    "aud": "https://example.com",
    "iat": 1782911685,
    "nonce": "rAnDoM123rAnDoM123rAnDoM123rAnDoM123",
    "sd_hash": "hAsH456hAsH456hAsH456hAsH456hAsH456"
  }
}

2. Проверьте ожидаемые значения.

Убедитесь, что основные значения в полезной нагрузке соответствуют предоставленным вами значениям:

• Убедитесь, что email_verified установлен в true .
• Убедитесь, что email совпадает с адресом, указанным в вашей форме.
• Убедитесь, что nonce совпадает со значением nonce, указанным в вашей форме.
• Убедитесь, что aud совпадает с источником вашего сайта.
• Убедитесь, что метка времени iat относительно недавняя, например, получена после отображения формы.

3. Проверка привязки клавиш

Браузер создает временный, эфемерный ключ для транзакции, чтобы подтвердить, что он подписал токен. Извлеките этот ключ из утверждения cnf (подтверждение) в EVT, а затем используйте его для проверки привязанного к ключу JWT.

Затем вычислите ожидаемый хеш и сравните его с утверждением sd_hash . Следующий пример на Node.js показывает, как выполнить это вычисление:

const calculatedHash = createHash("sha256")
        .update(evtJwt + "~")
        .digest("base64url");

4. Проверка записи DNS

Проверьте DNS-запись _email-verification для домена адреса электронной почты. Например, для demo@gmail.com запросите TXT -запись _email-verification.gmail.com . Для этого провайдера запрос вернет местоположение поставщика учетных записей, то есть accounts.google.com .

$ dig +short TXT _email-verification.gmail.com
"iss=accounts.google.com"

5. Определите эмитента и проверьте подпись EVT.

Убедитесь, что эмитент предоставляет ресурс /.well-known/email-verification , который содержит конечные точки для выпуска токена, JSON Web Key (JWK) для сайта и поддерживаемые алгоритмы подписи.

$ curl https://accounts.google.com/.well-known/email-verification
{
  "issuance_endpoint": "https://accounts.google.com/gsi/email-verification/issue",
  "jwks_uri": "https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA"]
}

Используйте JWK для проверки JWT EVT, извлеченного из токена. Большинство библиотек JOSE предоставляют функции для выполнения этой проверки.

Если все пять шагов пройдены успешно, значит, вы подтвердили адрес электронной почты у провайдера. В противном случае, как обычно, отправьте пользователю подтверждающее письмо.

Внедрить сервисы поставщика и эмитента электронной почты.

Для получения более подробной информации вы можете ознакомиться с демонстрационным кодом тестового поставщика услуг электронной почты и обратиться к шагам, описанным для эмитентов, в предложениях по API и протоколу проверки электронной почты .

Как эмитенту, вам не нужно регистрироваться для участия в пробном периоде или предоставлять токен, поскольку поведение браузера запускается сайтом зависимой стороны. Вам нужно лишь убедиться, что необходимые конечные точки настроены для обработки этих запросов.

Настройка обнаружения эмитентов

Чтобы браузеры могли автоматически обнаруживать ваши точки подтверждения при выборе адреса электронной почты, принадлежащего вашему домену, предоставьте доступ к вашей конфигурации через DNS и HTTP-точку доступа .well-known .

Настройка записи делегата DNS

Настройте DNS TXT -запись в вашем почтовом домене, которая делегирует полномочия по проверке вашему идентификатору эмитента. В зависимости от вашей инфраструктуры эти идентификаторы могут использовать один и тот же домен.

Формат записи: _email-verification.<email-domain>

Пример файла зоны:

_email-verification.example.com IN TXT "iss=accounts.issuer.example"

Разместите конечную точку .well-known/email-verification

Разместите файл метаданных в формате JSON на домене вашего эмитента по пути /.well-known/ . Этот файл описывает ваши возможности выпуска ценных бумаг и алгоритмы криптографической подписи, поддерживаемые вашей инфраструктурой.

Конечная точка: https://<issuer-domain>/.well-known/email-verification

Пример ответа:

{
  "issuance_endpoint": "https://accounts.issuer.example/email-verification/issuance",
  "jwks_uri": "https://accounts.issuer.example/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA", "ES256"]
}

Разместите конечную точку .well-known/web-identity

Дополнительный JSON-ресурс .well-known который вы, возможно, уже использовали в рамках API федеративных учетных данных (FedCM) . Он предоставляет ссылки на конечную точку ваших учетных записей и URL-адрес для входа в систему.

Конечная точка: https://<domain>/.well-known/web-identity

Пример ответа:

{
  "accounts_endpoint": "https://accounts.issuer.example/accounts",
  "login_url": "https://accounts.issuer.example/login"
}

Используйте конечную точку учетных записей.

В данный момент конечная точка accounts в API FedCM предоставляет список авторизованных учетных записей. В следующем примере показан минимальный ответ. Для получения более подробной информации обратитесь к руководству по внедрению поставщика идентификации .

Конечная точка: как указано в .well-known/web-identity

Ниже приведён пример ответа:

{
  "accounts": [
    {
      "id": "demo-example",
      "name": "Demo User",
      "email": "demo@example.com",
      "given_name": "Demo"
    }
  ]
}

Интеграция с API статуса входа в систему.

У пользователя должна быть активная сессия с провайдером, и вы должны сообщить об этом браузеру с помощью API статуса входа в систему .

При успешном входе или выходе пользователя из системы необходимо отправить соответствующий заголовок HTTP-ответа:

Set-Login: logged-in
Set-Login: logged-out

В качестве альтернативы, вы можете обновить статус с помощью JavaScript в контексте вашего веб-приложения:

navigator.login.setStatus("logged-in");
navigator.login.setStatus("logged-out");

Обработка запросов на выдачу документов.

Ваш issuance_endpoint получает POST запрос application/x-www-form-urlencoded , содержащий request_token .

В следующих разделах представлен полный процесс обработки запросов на выдачу документов.

1. Проверьте запрос на выдачу.

Анализ и проверка входящих данных, передаваемых браузером:

• Метод: POST
• Проверка сессии: Проверка подлинности файлов cookie session/authentication пользователя, передаваемых вместе с запросом, для обеспечения наличия активного и авторизованного контекста идентификации.
• Проверка параметров: Извлеките параметр request_token (подписанный JWT, сгенерированный браузером). Убедитесь, что он содержит ожидаемый временный открытый ключ, целевой адрес электронной почты, правильную целевую аудиторию и действительную метку времени.

Расшифрованный токен должен выглядеть примерно так:

{
  "decodedHeader": {
    "alg": "ES256",
    "typ": "JWT",
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "decodedPayload": {
    "iss": "https://accounts.issuer.example",
    "sub": "demo@example.com",
    "email": "demo@example.com",
    "iat": 1780272000,
    "exp": 1780272300
  },
  "signature": "SIGnatURE-123_SIGnatURE-123_SIGnatURE-123"
}

2. Ответьте жетоном.

После успешной проверки сессии и токена запроса сгенерируйте подписанный JWT с выборочным раскрытием (SD-JWT), используя полезную нагрузку:

{
  "iss": "https://accounts.issuer.example",
  "iat": 1780272000,
  "exp": 1780272300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "email": "demo@example.com",
  "email_verified": true
}

Подпишите полезную нагрузку, используя свой закрытый ключ и поддерживаемый алгоритм. Например, используя jose в Node.js:

const evtJwt = await new SignJWT(evtPayload)
   .setProtectedHeader({
     alg: "EdDSA",
     kid: PRIVATE_KEY_JWK.kid, // Key ID corresponding to our JWKS keys
     typ: "evt+jwt", // Standard Token Type for EVTs
   })
   .sign(privateKey);

 // Standard SD-JWT compatibility requires appending a trailing tilde "~"
 // to separate the signed token from the key binding section.
 const issuanceToken = `${evtJwt}~`;

Пример успешного ответа (HTTP 200):

{
  "issuance_token": "tOkEn123tOkEn123tOkEn123...~"
}

Вопросы, касающиеся испытаний происхождения

Эксперименты Origin — это исследования, направленные на сбор обратной связи, поэтому ваш вклад имеет решающее значение, если вы участвуете в них в качестве зависимой стороны или поставщика идентификационных данных. Для сообщения о проблемах используйте следующие репозитории GitHub:

• API для проверки электронной почты в браузере: WICG/email-verification
• Протокол проверки электронной почты: dickhardt/email-verification

Если вы обнаружите ошибки в реализации Chrome, сообщите об этом компоненту:

• Новый выпуск: Chromium > Blink > Identity > EVP

Включение функции пробного периода контролируется для каждого ответа отдельно путем добавления вами токена OT. Это означает, что у вас есть возможность детального контроля, если вы хотите ограничить использование функции для части ваших пользователей. Например, если у вас уже есть платформа для A/B-тестирования, вы можете интегрировать пробный период туда для контролируемой экспериментальной группы. В качестве альтернативы, если у вас есть группа бета-тестирования или раннего предварительного просмотра, вам может потребоваться включить эту функцию для них. В этом случае проверьте указанный адрес электронной почты, прежде чем выдавать или подтверждать токен.

В ходе пробных запусков также действуют ограничения на трафик, чтобы минимизировать зависимость сайтов от этой функции до её официального запуска. API эмитента находится в разработке, и следует ожидать обратно несовместимых изменений, а также обновлений пользовательского интерфейса Chrome.

Дальнейшие обновления будут публиковаться в блоге здесь и в списке рассылки evp-announce@chromium.org по мере продвижения разработки.