AR
и в этом весь вопрос
почему не можешь получить? она же не заишфрованная - ее и Вася видел и я.
или надо зашифровать ее?
Size: a a a
2019 December 11
AR
это условие говорит о том, что не можешь, а у тебя как раз можешь )
AR
вот тут все описано, если я как-то не понятно объясняю
MP
в смысле мимо меня хрень должна проходить шифрованной?
AR
шифрованой она не должна быть. должно быть криптографически невозможно получить token1 обладая token2
MP
валидатор чтобы не мог токен1 получить?
MP
а зачем вообще в token2 класть токен1?
AR
Ну ок, пойдем этим путем )
Я хочу сделать что-то вроде Capabilities-Based Access Control для распределенных систем. Т.е. сервис при создании ресурса генерирует (forge) некий рутовые токены (capabilities), которые и должны использоваться при операциях с этим ресурсом. Обладание таким токеном само по себе означает право (authority) на совершение этих действий. Обладатель токена может его свободно передавать другим агентам (delegation). Кроме того, любой обладатель токена может "обернуть" его, т.е. сузить возможности токена. Добавив к нему слой и подписав его.
Для того чтобы как-то решить проблему возможности отзыва (и не только, на этом же строится аудит и квоты) токенов при каждом таком оборачивании в токен добавляется key. Верификатор проверяет, что все такие key валидны и не были отозваны.
Структурно это такой JWT с возможность наслаивания. И если с имплементацией симметричных подписей у меня проблем нет (верификатор по key вытаскивает соответсвующие secrets), то вот асимметричная криптография поставила в тупик.
Я хочу сделать что-то вроде Capabilities-Based Access Control для распределенных систем. Т.е. сервис при создании ресурса генерирует (forge) некий рутовые токены (capabilities), которые и должны использоваться при операциях с этим ресурсом. Обладание таким токеном само по себе означает право (authority) на совершение этих действий. Обладатель токена может его свободно передавать другим агентам (delegation). Кроме того, любой обладатель токена может "обернуть" его, т.е. сузить возможности токена. Добавив к нему слой и подписав его.
Для того чтобы как-то решить проблему возможности отзыва (и не только, на этом же строится аудит и квоты) токенов при каждом таком оборачивании в токен добавляется key. Верификатор проверяет, что все такие key валидны и не были отозваны.
Структурно это такой JWT с возможность наслаивания. И если с имплементацией симметричных подписей у меня проблем нет (верификатор по key вытаскивает соответсвующие secrets), то вот асимметричная криптография поставила в тупик.
.
AR
валидатор чтобы не мог токен1 получить?
любой обладатель токен2
MP
вообще, вот тут есть реализация каскадной мультиподписи M из N
https://github.com/nemtech/catapult-server
https://github.com/nemtech/catapult-server
MP
любой обладатель токен2
а зачем в цепочка вообще токен1, если достаточно только подписи от него?
MP
или от его хэша.
AR
ну во-первых надо, по условию задачи
AR
вообще, вот тут есть реализация каскадной мультиподписи M из N
https://github.com/nemtech/catapult-server
https://github.com/nemtech/catapult-server
вооот, мульти подписи, агрегейтед подписи, на вот это я как раз и скидываю линки со словами похоже )
MP
то есть в token2 должен быть token1 в каком-то виде, но чтобы его не все могли видеть?
AR
я не знаю что добавить к тому что я уже сказал
AR
не "не все могли видеть", а "должно быть криптографически невозможно получить token1 обладая token2"