Раньше я считал, что как только блокчейн может доказать, что кто-то обладает действительным удостоверением, решение о доступе практически уже завершено.
Читая о Citadel 2 у @Dusk, я понял, что это на самом деле два разных вопроса.
Citadel 2 позволяет пользователю сгенерировать доказательство с нулевым разглашением, показывающее, что у него есть зарегистрированная лицензия, подписанная License Provider, при этом не раскрывая, какая именно лицензия используется. Контракт Citadel проверяет доказательство и записывает публичную сессию.
Но криптографически корректная сессия не означает автоматически, что доступ должен быть предоставлен.
Документация Dusk делает это различие явным. Service Provider по-прежнему решает, каким License Provider он доверяет, какие атрибуты принимает, истекла ли сессия или была отозвана, а также можно ли повторно использовать cookie сессии.
Это разделение изменило то, как я думаю о цифровой идентичности.
Протокол может проверять криптографическую корректность сессии, оставляя при этом сервисную политику на стороне Service Provider.
Для меня это указывает на важную границу: доказательство того, что сессионное удостоверение на основе учетных данных является действительным, — это не то же самое, что решение о том, удовлетворяет ли это доказательство требованиям конкретного сервиса.
Так что, возможно, лучший вопрос про идентичность — не просто в том, может ли пользователь доказать что-то о своих удостоверениях.
Вопрос в том, что именно криптография должна проверять, а что должно оставаться решением политики для сервиса, который использует это доказательство.
Для меня это различие — одна из самых интересных идей за Citadel 2.
$DUSK #dusk @Dusk
Читая о Citadel 2 у @Dusk, я понял, что это на самом деле два разных вопроса.
Citadel 2 позволяет пользователю сгенерировать доказательство с нулевым разглашением, показывающее, что у него есть зарегистрированная лицензия, подписанная License Provider, при этом не раскрывая, какая именно лицензия используется. Контракт Citadel проверяет доказательство и записывает публичную сессию.
Но криптографически корректная сессия не означает автоматически, что доступ должен быть предоставлен.
Документация Dusk делает это различие явным. Service Provider по-прежнему решает, каким License Provider он доверяет, какие атрибуты принимает, истекла ли сессия или была отозвана, а также можно ли повторно использовать cookie сессии.
Это разделение изменило то, как я думаю о цифровой идентичности.
Протокол может проверять криптографическую корректность сессии, оставляя при этом сервисную политику на стороне Service Provider.
Для меня это указывает на важную границу: доказательство того, что сессионное удостоверение на основе учетных данных является действительным, — это не то же самое, что решение о том, удовлетворяет ли это доказательство требованиям конкретного сервиса.
Так что, возможно, лучший вопрос про идентичность — не просто в том, может ли пользователь доказать что-то о своих удостоверениях.
Вопрос в том, что именно криптография должна проверять, а что должно оставаться решением политики для сервиса, который использует это доказательство.
Для меня это различие — одна из самых интересных идей за Citadel 2.
$DUSK #dusk @Dusk
