Кратко

  • Для проверки цифрового ключа приложению нужна конкретная запись, а HTTP-сервер доставляет документ целиком. Ошибка на последнем шаге оставит пользователя у закрытой двери даже после успешного ответа сервера; поэтому два шага требуют отдельных проверок.
  • В версии W3C от 1 октября сетевой разыменователь DID URL имел свой класс соответствия и примеры работы через HTTP(S). Редакции от 24 и 26 октября убрали эти положения; разрешение DID через HTTPS осталось.

Приложение проверяет подпись и запрашивает did:example:123#key-1. Резолвер возвращает документ DID. Затем приложение ищет в нём нужный метод проверки и решает, подходит ли ключ для этой операции. Пользователь видит один вход; инженер разбирает два разных шага. Если вход не сработал, журнал сервера с HTTP 200 закрывает лишь первую половину вопроса. Для второй нужна трасса выбора фрагмента и обработки результата в клиенте.

Проект от 1 октября описывал общую HTTP(S)-привязку для разрешения DID и разыменования DID URL. В нём были сетевой класс соответствия и примеры запросов к разыменователю. В редакции от 24 октября этот класс исчез вместе с HTTP-примерами разыменования. Текст от 26 октября закрепил границу и указал, что разыменование убрано также из определения OpenAPI.

Сетевая дверь для разрешения осталась рабочей частью проекта. Соответствующий требованиям резолвер должен поддерживать GET через HTTPS; POST разрешён по желанию. Ответ содержит документ DID и метаданные. Это позволяет приложениям получать исходный документ по общей схеме, даже когда сами DID-методы различаются.

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

Спор о границе начался раньше публикации. В вопросе 306 участник группы ещё в марте указал, что удалённый сервис не завершит работу с фрагментом, который интерпретирует клиент. Протокол заседания 15 октября фиксирует обсуждение того, как испытывать абстрактный алгоритм через конкретный интерфейс. Если в отчёте о сбое записан лишь ответ резолвера, команда не увидит, какой обработчик выбрала программа и какой ключ получила. Нужны две проверяемые записи: документ на выходе сервера и результат обработки полного URL.

Разыменование пока помечено в Candidate Recommendation как функция, которая может измениться. Поэтому в сегодняшнем отчёте о внедрении стоит хранить обе строки маршрута. Код HTTP сообщает, что произошло у двери; судьбу ключа выясняют уже внутри приложения.