Я нашёл странную границу в Citadel 2: доказательство с нулевым разглашением может быть валидным, а пользователь всё равно может быть отклонён.
Поток строже, чем «докажи личность — получи доступ». Провайдер лицензий проверяет пользователя вне цепочки, подписывает соответствующие атрибуты и регистрирует зашифрованную лицензию в контракте Citadel. Позже пользователь доказывает, что владеет лицензией, подписанной зарегистрированным LP, не размещая персональные данные или точные данные лицензии в блокчейне. Citadel проверяет это доказательство и фиксирует публичную сессию.
Но сессия — это не разрешение. Поставщику сервиса всё равно нужно решить, каким Провайдерам лицензий он доверяет, соответствует ли раскрытый атрибут его правилу, является ли сессия истёкшей или отозванной, и можно ли повторно использовать cookie.
Именно этот разрыв я постоянно отслеживаю. Если я строю регулируемый сервис на Dusk, криптография доказывает путь к учётным данным. Моей политике всё равно принадлежит окончательное решение о доступе. Устаревшая или ошибочно доверенная сессия должна погибнуть на этой границе, а не превратиться в пропуск, который выглядит действительным.
Слабое место (pressure point) простое: когда политика меняется быстрее, чем учётные данные, сервис отклоняет правильную сессию до того, как будет предоставлен доступ?
#dusk $DUSK @Dusk
#USJulyCPI&PPIDueThisWeek
Поток строже, чем «докажи личность — получи доступ». Провайдер лицензий проверяет пользователя вне цепочки, подписывает соответствующие атрибуты и регистрирует зашифрованную лицензию в контракте Citadel. Позже пользователь доказывает, что владеет лицензией, подписанной зарегистрированным LP, не размещая персональные данные или точные данные лицензии в блокчейне. Citadel проверяет это доказательство и фиксирует публичную сессию.
Но сессия — это не разрешение. Поставщику сервиса всё равно нужно решить, каким Провайдерам лицензий он доверяет, соответствует ли раскрытый атрибут его правилу, является ли сессия истёкшей или отозванной, и можно ли повторно использовать cookie.
Именно этот разрыв я постоянно отслеживаю. Если я строю регулируемый сервис на Dusk, криптография доказывает путь к учётным данным. Моей политике всё равно принадлежит окончательное решение о доступе. Устаревшая или ошибочно доверенная сессия должна погибнуть на этой границе, а не превратиться в пропуск, который выглядит действительным.
Слабое место (pressure point) простое: когда политика меняется быстрее, чем учётные данные, сервис отклоняет правильную сессию до того, как будет предоставлен доступ?
#dusk $DUSK @Dusk
#USJulyCPI&PPIDueThisWeek