Вопросы спецификации UCAN: рекомендация одноразового номера, пример факта, доказательство prf, механизмы кэширования владельца UCAN, идентификатор содержимого сеанса, ограничения SPKI
У меня есть несколько вопросов о спецификации UCAN :
- спецификация объясняет, что UCAN относится к
SPKIсемья. Однако в статье «Разрушение мифов о возможностях», ссылка на которую содержится в главе «Интуиция», упоминается, что SPKI ограничены по сравнению сobject capabilitiesмодель (см. рисунок 15 ниже, извлеченный из бумаги). Обоснование в спецификации UCAN: "Since offline operation and self-verifiability are two requirements, UCAN adopts an approach closely related to SPKI«Можете ли вы предоставить больше информации о компромиссах различных подходов? В документе модель возможностей объекта представлена как серебряная пуля.
- есть ли какие-либо рекомендации по безопасности для размера ? Он просто должен быть уникальным? Как убедиться, что он уникален, если UCAN генерируются децентрализованно различными организациями? Как убедиться, что используется одна и та же функция? Является ли UUID хорошей реализацией? Это
ownerответственный за предоставление рекомендаций относительно того, как создатьnonce? - что это значит
factsдолжны быть внешне проверяемыми? Делаетself-evidentозначает самоочевидность, то есть имя переменной должно иметь смысл? См. - DID никогда не нужно на самом деле разрешать с помощью их метода, верно?
- нет примера для затухания https://github.com/ucan-wg/spec#324-facts .https://github.com/ucan-wg/spec#324-facts - можете ли вы его предоставить?
- что такое корневая точка входа
/? См. https://github.com/ucan-wg/spec#71-canonical-json-collection. - я не понимаю как
prfработает. Как рассчитываются доказательства? Не могли бы вы привести практический пример шага, который приводит к созданию канонического представления ? - Представьте себе централизованный сервер, предоставляющий API, авторизованный с помощью UCAN.
- Чтобы предотвратить повторные атаки, они должны отслеживать все сгенерированные ими UCAN в некоторой базе данных (скажем, в таблице в PostgreSQL для простоты). Но им также нужно вставить новый действительный делегированный UCAN, который они получают, верно?
- Им также необходимо отслеживать каждый отозванный UCAN. Отозванный UCAN может быть UCAN, который сервер никогда не генерировал сам, например, UCAN, который был делегирован из созданного им UCAN. Таким образом, сервер должен предоставить общедоступную конечную точку для отзыва UCAN и вести отдельную таблицу со всеми отозванными UCAN. Я прав?
- Как сделать так, чтобы таблицы действительных UCAN и отозванных UCAN не стали слишком большими? Я полагаю, что сервер ДОЛЖЕН периодически удалять из своей базы данных все просроченные UCAN (проверка времени)?
- Я не понимаю ID сеанса контента. Что значит
dischargingанinvokationозначает? Вызывать его? Означает ли это, что отправитель хочет использовать несколько возможностей одновременно?the sender and receiver MAY agree to use the triple of CID, nonce, and signature rather than reissuing- тройной, но тогда я не вижу ни одногоtripleв приведенном примере:
{
"cid": cid(ucan)
"nnc": "ABC",
"sig": sign(ucan.iss.privateKey, cid(ucan) + "ABC")
}
Спасибо.