Облачный агент OIDC против пограничного агента SIOP
Мы начинаем POC (подтверждение концепции) с Децентрализованной Идентификацией (DID) и получили документ, рассказывающий о методе аутентификации, который нужно использовать:
Облачный агент OIDC против пограничного агента SIOP.
Я не понимаю, что это за две вещи? а также каковы преимущества или недостатки использования того или другого.
Я знаю OpenId Connect, но не эти два, любые объяснения или ссылки для чтения будут высоко оценены.
Спасибо
1 ответ
В этом ответе предполагается, что вы знакомы с Indy, Aries, DID, проверяемыми учетными данными и OIDC. Я много знаю о первом наборе тем, но я не эксперт по OIDC, так что терпите меня:-).
SIOP (самостоятельно выданный поставщик соединений OpendID) является стандартным расширением OIDC, хотя оно не реализовано большинством поставщиков IAM. Когда реализовано, проверяющая сторона OIDC (RP) может использовать протокол SIOP, чтобы напрямую связаться с владельцем DID (скажем, Identity Wallet) и вернуть проверенный идентификатор, используя стандартный протокол OIDC. Проект (Interop Project) в Decentralized Identity Foundation (DIF) использует SIOP для реализации DID-аутентификации. Здесь есть статья о подходе - https://medium.com/decentralized-identity/using-openid-connect-with-decentralized-identifiers-24733f6fa636. Проект взаимодействия можно найти здесь: https://github.com/decentralized-identity/interop-project
Альтернатива, над которой мы работаем в губернаторе Британской Колумбии (Британская Колумбия) с Mattr Global (Новая Зеландия), использует облачный агент OIDC для реализации стандартного OIDC Identity Provider (OP), который взаимодействует с OIDC с одной стороны, и использует протокол DID (DIDComm).) с другой стороны, чтобы поговорить с проверяемым держателем учетных данных (опять же, Identity Wallet). Мы используем стандартную клиентскую библиотеку OIDC с одной стороны, чтобы получать запросы авторизации от RP, а затем (используя HTTP) отправлять запросы агенту Aries (на основе Indy) для взаимодействия с Identity Wallet (сам агент Aries) - или, по крайней мере, один, который говорит DIDComm), чтобы запросить доказательство и получить обратно доказательство. Затем библиотека OIDC берет данные из утверждений, отображает их в токен OIDC для возврата в RP. Внедрение предполагает, что RP и IdP (комбинация клиентской библиотеки OIDC и агента Aries) управляются организацией, запрашивающей авторизацию.
Эта ссылка содержит изображение того, как эти две реализации выглядят: https://github.com/decentralized-identity/interop-project/issues/16
Обратите внимание, что реализация SIOP предназначена для проверки DID, в то время как реализация агента OIDC направлена на проверку заявок на основе проверяемых учетных данных (VC). Мы думаем, что вырожденный случай авторизации VC является доказательством DID, поэтому подход агента OIDC может быть в состоянии обработать оба случая.
Здесь есть хорошее обсуждение / краткое изложение плюсов и минусов подходов: https://github.com/decentralized-identity/interop-project/issues/9
Работа, которую мы (BC Gov и Mattr Global), здесь: https://github.com/bcgov/vc-authn-oidc