ssi что это такое при банковском переводе
Простое объяснение движения денег в банковской системе
От переводчика: В последние месяцы в жизнь многих людей прочно вошли новости сферы финансов. Одна из недавних тем — возможное отключение России от системы SWIFT. Угроза выглядит очень серьезно, но что на самом деле грозит стране, если события будут развиваться по этому сценарию? Наш сегодняшний материал призван помочь разобраться с тем, как все устроено в глобальном мире финансов.
На прошлой неделе [статья опубликована в ноябре 2013] Twitter сошел с ума из-за того, что кто-то перевел почти 150 миллионов долларов за одну транзакцию в криптовалюте. Появление такого твита было в порядке вещей:
Транзакция 194 993 биткоинов стоимостью в 147 миллионов долларов порождает много тайн и спекуляций
Было много комментариев о том, насколько дорого и сложно было бы это реализовать в обычной банковской системе, и, вполне возможно, что так оно и есть. Но при этом я обратил внимание вот на что: по своему опыту знаю, что почти никто не понимает, как на самом деле работают платежные системы. То есть: когда вы «перечисляете» денежные средства поставщику или «производите платеж» на чей-либо счет, как деньги переходят с вашего счета на счета других?
С помощью этой статьи я попытаюсь изменить ситуацию и проведу простой, но, надеюсь, не слишком упрощенный, анализ в этой области.
Для начала найдем точки соприкосновения
Думаю, прежде всего, нужно понимать, что банковские депозиты являются обязательствами [банка перед вами]. Когда вы кладете деньги в банк, фактически у вас нет депозита. Это не мешок с деньгами, на котором написано ваше имя. Вместо этого, вы дали взаймы эти деньги банку. Он должен их вам. Эти деньги становятся одним из обязательств банка. Именно поэтому мы говорим, что наши деньги находятся на кредитном счету: мы предоставили банку кредит. Аналогично, если вы превышаете кредит и оказываетесь должны банку, это становится уже вашим обязательством и их активом. Чтобы понимать, как движутся деньги, важно понять, что каждую запись в бухгалтерском отчете можно рассматривать с этих двух точек зрения.
Перевод средств на счет клиента того же банка
Начнем с простого примера. Представьте, будто вас зовут Элис, и вы являетесь клиентом, скажем, банка Barclays. Вы должны 10 фунтов своему другу по имени Боб, который тоже пользуется услугами Barclays. С Бобом легко расплатиться: вы говорите банку о своих намерениях, он снимает денежные средства с вашего счета и вносит 10 фунтов на счет вашего друга. Процедура осуществляется в электронном виде через автоматизированную банковскую систему Barclays, все предельно просто: деньги ни поступают в банк, ни выводятся из него; происходит лишь обновление системы счетов. Банк должен вам на 10 фунтов меньше, а Бобу – на 10 фунтов больше. Все уравновешивается, и все происходит внутри банка: говорят, что транзакция «зафиксирована» в бухгалтерских книгах банка. Это представлено на схеме ниже: участие принимают лишь три стороны – вы, Боб и Barclays. (Естественно, тот же анализ можно провести, если вы осуществляете транзакцию в евро через Deutsche Bank или в долларах через Citi и т.п.)
Но что происходит, когда вам нужно перевести деньги на счет клиента другого банка?
Здесь ситуация интереснее. Представьте, что вам нужно заплатить некоему Чарли, клиенту банка HSBC. Возникает проблема: банку Barclays несложно снять 10 фунтов с вашего счета, но как им убедить HSBC, чтобы те увеличили счет Чарли на 10 фунтов? Зачем банку HSBC соглашаться на то, чтобы быть должными Чарли больше, чем раньше? Они же не благотворительная организация! Ясно, что ответ заключается в том, что, если мы хотим, чтобы HSBC были должны Чарли немного больше, им нужно быть должными кому-то другому немного меньше.
Кем же должен быть этот «другой»? Это точно не Элис: если помните, она никак не связана с HSBC. Методом исключения выясняется, что единственный возможный вариант – это Barclays. И первое, что при этом приходит на ум: что, если HSBC откроет счет в Barclays, а Barclays откроет счет в HSBC? Каждый из банков мог бы открыть счет в другом банке и регулировать эти счета для решения такого рода проблем…
Вот как можно поступить:
Такая модель обработки платежей (и ее более сложные разновидности) известна как деятельность банков на основе корреспондентских отношений. Графически ее можно представить подобно схеме, представленной ниже. В качестве основы берется предыдущая схема и добавляется второй коммерческий банк; важно отметить, что наличие корреспондентских отношений позволяет банкам облегчить выплату платежей соответствующим клиентам.
Схема работает довольно неплохо, но возникают некоторые сложности:
Погодите… зачем все усложнять? Нельзя ли просто воспользоваться системой SWIFT [англ. Society for Worldwide Interbank Financial Telecommunications – Международная межбанковская система передачи информации и совершения платежей] и покончить с этим?
Как правило, во время обсуждения платежных систем обязательно найдется человек, который будет махать руками, кричать «SWIFT» и считать, что вопрос решен. По-моему, это только подтверждает, что такие люди, наверняка, не понимают, о чем говорят.
Сеть SWIFT позволяет банкам беспрепятственно обмениваться друг с другом электронными сообщениями. Один из типов сообщений, который поддерживается сетью SWIFT – это MT103. MT103 дает возможность одному банку давать указания другому банку, чтобы последний перечислил сумму на счет одного из своих клиентов, в то время как та же сумма списывается со счета организации, посылающей сообщение, в банке, принимающем его, так чтобы все уравновешивалось. Можете представить, как сообщение MT103 применялось бы в случае, описанном в предыдущей части.
Таким образом, в результате отправления сообщения MT103 в сети SWIFT деньги «пересылаются» между двумя банками, но особенно важно понять, что же происходит на самом деле: сообщение по сети SWIFT – всего лишь указание; движение денежных средств осуществляется при их перечислении на некоторые счета и зависит от банков, имеющих счета в других банках (непосредственно или через банки-посредники). Просто махать руками и кричать: «SWIFT!», – значит скрывать эти сложности, и поэтому препятствовать пониманию системы.
Ладно… Понятно. А как быть с ACH, EURO1, Faster Payments, BACS, CHAPS, FedWire, Target2 и так далее, и так далее.
Стоп… Давайте-ка сначала вкратце повторим.
Мы показали, что перечисление денег между двумя владельцами счетов в одном и том же банке не вызывает трудностей.
Также мы показали, как можно перечислять деньги между двумя владельцами счетов в разных банках довольно хитроумным способом: сделать так, чтобы каждый из банков открыл счет в другом банке.
Кроме того, мы обсудили, как системы электронного обмена сообщениями вроде SWIFT могут управлять потоком информации между двумя банками и следить за тем, чтобы переводы осуществлялись быстро, надежно и дешево.
Но у нас есть, что еще обсудить… так как возникают такие серьезные вопросы, как риск контрагента, ликвидность и расходы.
Сначала рассмотрим ликвидность и расходы.
Нам необходимо решить проблему ликвидности и расходов
Во-первых, нужно учесть, что сеть SWIFT стоит денег. Если бы Barclays нужно было посылать сообщение по сети SWIFT банку HSBC каждый раз, когда вы захотите перевести на счет Чарли 10 фунтов, в скором времени вы бы обнаружили существенные затраты в своей выписке. Но что хуже, возникает более серьезная проблема – ликвидность.
Подумайте, сколько денег понадобилось бы Barclays, чтобы каждый день находиться на связи со всеми банками-корреспондентами, если бы система, описанная ранее, применялась на практике. Им нужно было бы иметь крупные суммы на счетах во всех других банках на случай, если один из их клиентов захочет перевести деньги на счет клиента HSBC, Lloyds, Co-op или куда-нибудь еще. Эти наличные можно было бы вложить, дать взаймы или еще каким-либо образом потратить.
Но тут может возникнуть весьма интересная мысль: в конечном счете, клиент Barclays, наверняка, станет переводить деньги на счет клиента HSBC с той же степенью вероятности, что и клиент HSBC станет переводить деньги на счет клиента Barclays в определенный момент времени.
То есть что, если бы мы продолжали отслеживать все многочисленные платежи в течение дня и фиксировали бы только разницу? При таком подходе у каждого из банков могло бы быть гораздо меньше наличных на каждом из корреспондентских счетов, и каждый смог бы вложить свои деньги эффективнее, сокращая при этом затраты и (хотелось бы надеяться) пересылая часть этих денег в ваш банк. Такие рассуждения привели к появлению систем отложенных нетто-расчетов (СОНР). В Великобритании такой системой является BACS, и в любой стране можно найти ее аналоги. В таких системах не обмениваются сообщениями через сеть SWIFT. Вместо этого, сообщения (или файлы) попадают в центральную «клиринговую» систему (такую как BACS), которая отслеживает все платежи и затем в определенные сроки рассчитывает нетто-сумму, которую каждый из банков должен любому другому банку. После этого они проводят между собой определенные операции (возможно, пересылая денежные средства на/со счетов, которые каждый из банков имеет в другом банке) или применяют систему RTGS, описанную далее.
Такой метод значительно сокращает требования к затратам и ликвидности и дополняет нашу схему еще одним блоком:
Стоит обратить внимание на то, что таким же образом (как СОНР) можно описать механизмы использования кредитных карт и даже системы PayPal: все они характеризуются процессом расчета внутренних транзакционных издержек, результатом которого является только нетто-сумма, определенная для крупных банков.
Но и при таком подходе возникает потенциально более серьезная проблема – потеря завершенности расчета. Вы можете отправить указание по вашему платежу утром, однако банк-получатель не сможет получить (чистые) денежные средства до определенного момента.
Поэтому банку-получателю приходится ждать получения (чистого) расчета по счету на случай возможного банкротства отправителя во время перевода: было бы опрометчиво перечислять средства принимающей стороне заранее. В результате возникает задержка.
С другой стороны, можно было бы взять на себя риск и в случае возникновения проблемы отменить транзакцию. Но тогда расчет никогда бы не считался «завершенным», и в этом случае получатель никак не смог бы рассчитывать на получение этих денежных средств до определенного срока.
Можно ли достичь и завершенности расчета, и нулевого риска контрагента?
Здесь как раз и складываются все кусочки мозаики. Ни один из подходов, рассмотренных ранее, нельзя применить в ситуациях, где нужно быть абсолютно уверенным, что платеж осуществится быстро, и его нельзя будет отменить, даже если банк-отправитель впоследствии разорится. Вам крайне необходима такого рода гарантия, например, если вы намерены создать систему расчетов по операциям с ценными бумагами: никто не предоставит вам 150 миллионов долларов облигациями или акциями, если есть риск, что эти 150 миллионов не будут выплачены, или их нельзя будет вернуть!
Необходима система, подобно первой из тех, что мы рассматривали (Элис переводит деньги на счет Боба в том же банке) – так как в ней все происходит действительно быстро – но которая будет работать при участии более чем одного банка. Многосторонняя межбанковская система, рассмотренная ранее, вроде бы работает, но становится довольно запутанной при переводе достаточно крупных сумм и при наличии вероятности того, что тот или иной банк может разориться.
Вот если бы банки могли иметь счета в таком банке, который не сможет обанкротиться… своего рода банк, который находился бы в самом центре системы. Можно придумать ему название. Назовем его центральным банком!
Следуя этой логике, возникает идея системы валовых расчетов в режиме реального времени [англ. Real-Time Gross Settlement system, RTGS].
Если все крупнейшие банки страны будут иметь счета в центральном банке, они смогут переводить деньги из одного банка в другой, просто давая указания центральному банку на списание средств с одного счета и их зачисление на другой. Для этого и предназначены системы CHAPS, FedWire и Target 2, которые занимаются переводами фунтов, долларов и евро соответственно. Эти системы осуществляют движение денежных средств в режиме реального времени между счетами, которые банки имеют в соответствующем центральном банке. Итак, это система:
Я думал, эта статья как-то связана с Bitcoin
Хорошо, что напомнили. Теперь встает вопрос: можно ли поместить в эту модель Bitcoin?
Мне кажется, что Bitcoin очень сильно напоминает систему RTGS. В ней нет учета задолженности, (очевидно) нет корреспондентских отношений между банками, и все расчеты валовые, завершенные.
Однако «традиционный» финансовый ландшафт интересен тем, что большинство розничных сделок сегодня осуществляются не через систему RTGS. К примеру, прямые электронные платежи между жителями Великобритании осуществляются через систему ускоренной оплаты FPS [англ. Faster Payments system], выполняющей зачет встречных требований несколько раз в день, не мгновенно. Почему так? Я бы сказал, потому что, в первую очередь, FPS – (почти) бесплатная, в то время как стоимость платежей в системе CHAPS составляет 25 фунтов. Многие клиенты, наверняка, пользовались бы системой RTGS, если бы она была такой же удобной и дешевой.
Поэтому мой вопрос, оставшийся без ответа: останется ли система платежей Bitcoin лишь подобием традиционной RTGS, осуществляющей только наиболее значимые переводы? Или же изменения в базовой сети (ограничения по размерам блоков, каналы для микроплатежей и т.д.) произойдут и будут происходить достаточно быстро с увеличением объемов сделок, позволяя системе оставаться доступной как для более значимых, так и для менее значимых платежей?
Мне кажется, вопрос еще остается открытым: я уверен, что Bitcoin изменит мир, но вместе с тем я не так уверен, что мы будем жить в мире, где каждая транзакция, проведенная с помощью сети Bitcoin, «пройдет» через базу Blockchain.
Что такое суверенная идентичность (Self-Sovereign Identity)?
Экспертные консультации для этого материала предоставил автор Telegram-канала CryptoEssay Степан Гершуни.
Что такое суверенная идентичность?
Суверенная идентичность (Self-Sovereign Identity, SSI) — это набор сведений о личности, которыми она может управлять, делиться с любыми частными лицами или публичными институтами, и отзывать к ним доступ в любое время по своему желанию.
Система SSI основана на децентрализованных технологических архитектурах и призвана сделать приоритетом безопасность, конфиденциальность, индивидуальную автономию и возможность самореализации пользователя.
Какие возможности предоставляет суверенная идентичность?
SSI позволяет создавать универсальную пожизненную цифровую идентичность и идентификационные данные, не зависящие от централизованных провайдеров. Экономические выгоды от этой технологии можно получить благодаря следующим уникальным особенностям SSI:
Какие проблемы решает SSI?
Цифровой мир с его множеством взаимосвязей требует документов нового типа — открытых и доступных для каждого пользователя, нативно цифровых, доступных на персональном компьютере или телефоне, постоянных, доказуемых и не требующих зависимости пользователя от поставщика.
В качестве альтернативы социальным сетям, банкам и государственным учреждениям SSI предлагает универсальное решение, способное объединять различные приложения и позволяющее совместно использовать данные.
Предустановленный характер стандартов облегчает их принятие и снижает стоимость их поддержания и развития. В отличие от традиционных моделей установки сотен и тысяч API, SSI позволяет только единожды установить схему документа, после чего он сразу же становится доступен любой третьей стороне. Хотя схемы носят публичный характер, любыми личными данными можно делиться только с однозначного позволения их владельца.
Другое преимущество объединения изолированных систем хранения данных состоит в том, что оно позволяет извлечь пользу из сырых данных. Например, рабочий, который всегда приходит на завод вовремя, может подтвердить свою пунктуальность будущему работодателю. Выполнивший тысячи домашних заданий школьник может выстроить персонализированную стратегию обучения к моменту поступления в университет.
Неэффективная обработка документов
Как правило, ценность любого сертификата (удостоверяющего документа) заключается не в содержании документа, а в услугах, продуктах и возможностях, которые открываются его владельцу. Например, чтобы найти работу или получить научно-исследовательский грант, может понадобиться диплом об образовании; для получения кредитной карты или создания корпоративного банковского счета необходимы финансовые данные и т. д.
Чтобы повысить скорость предоставления услуг и сделать их более удобными, необходимо автоматизировать бюрократические системы. Верификацию и накопление идентификационных данных, а также работу с документами должен производить алгоритм, а не человек. Автоматизация рационализирует, модернизирует, стандартизирует и ускоряет процесс, а также решает проблемы коррупции, дискриминации и личной предвзятости.
С ростом числа бюрократических систем, использующих верифицируемые идентификационные данные и SSI, будет возрастать доверие к процессу. Например, после завершения проверки банком деловой репутации и соответствия KYC, клиент может использовать результаты для получения другой услуги от иной организации, с условием, что эта организация доверяет банку.
Чтобы масштабировать и автоматизировать существующие системы доверия еще больше, необходимо внедрение стандарта, нативного как для людей, так и для машин. С увеличением количества документов, которые выпускаются и верифицируются с помощью программного обеспечения, возрастает потребность в стандартизированных форматах машиночитаемых данных.
Стандартизация данных также решает проблему интеграции различных провайдеров данных и верифицирующих сторон. Вместо того, чтобы создавать взаимно однозначные интеграции API — это дорогостоящий и затратный по времени процесс — вся индустрия или страна могут принять совместно используемый формат данных, подкрепленный верифицированными идентификационными данными.
Конечные пользователи и регуляторы придают все большее значение защите данных. Бизнес вынужден принимать в расчет требования регуляторов — Закон Калифорнии о защите персональных данных потребителей, Общий регламент защиты персональных данных Европейского союза, Федеральный закон США об управлении информационной безопасностью и многие другие.
Технология SSI позволяет реализовать все функции защиты конфиденциальности: прозрачное использование данных, право на забвение, аудиторскую проверку использования данных, менеджмент разрешений регулирующих органов посредством систем управлениями версиями.
В цифровую эпоху SSI может быть решением проблемы «надзорного капитализма». Если пользователь сумеет контролировать свои личные данные и выбирать, с кем ими делиться и когда отзывать доступ, то эти данные невозможно будет использовать в преступных целях. Интернет-компании не смогут монетизировать своих пользователей без однозначного позволения со стороны последних. Кроме того, они будут обязаны делиться с пользователями прибылью. Онлайн-бизнес изменит парадигму: от стремления получать максимальное количество данных пользователей он перейдет к обеспечению лучшего сервиса.
Как возникла суверенная идентичность?
По мнению ряда исследователей, концепция суверенной идентичности появилась в результате попытки реализовать на индивидуальном уровне Bестфальскую систему международных отношений. Эта система возникла в Европе на основе Вестфальского мира как соглашения, которое подвело итоги Тридцатилетней войны, закончившейся в 1648 году. Ключевые принципы Вестфальского мира — суверенной государственности, самоопределения и прямого самоуправления — действуют и поныне.
Идеологическим прародителем SSI стала концепция суверенного самоуправления (self-sovereign authority). Носители концепции считали, что возможность независимого (суверенного) самоуправления является «врожденной» отличительной чертой человеческого естества. Она присутствовала еще до возникновения процесса «регистрации», который делает возможным участие в общественной жизни. Акт «регистрации» подразумевает, что для существования идентичности необходим контролируемый обществом процесс администрирования. При этом общество рассматривается как владелец идентичности, а индивидуум — как своего рода продукт социально-экономического администрирования.
В деле достижения цифровой суверенности, т. е. способности индивидуумов совершать действия и принимать решения осознанным и независимым образом, а также контроля над собственными данными, устройствами, программным обеспечением, средствами вычислительной техники и другими технологиями, ключевым фактором является управление идентификационными данными.
Зачастую, термин «суверенная идентичность» используется как взаимозаменяемый с такими выражениями, как «децентрализованная идентичность» (decentralized identity) и «цифровая идентичность» (digital identity).
Цифровая идентичность, которая выражается и хранится в цифровой форме, начала развиваться одновременно с изобретением интернета. Доменные имена, адреса электронной почты, аккаунты социальных сетей — это образцы цифровой идентичности, без которых невозможна повседневная жизнь современного человека.
Как устроена архитектура SSI?
Цифровая идентичность состоит из трех элементов: децентрализованного идентификатора (DID), системы аутентификации и системы сертификации посредством верифицируемых идентификационных документов (Verifiable Credentials).
Помимо этих элементов, SSI включает DKMS — систему децентрализованного управления ключами (Decentralized Key Management System). С ее помощью осуществляется управление закрытыми ключами с помощью цифровой подписи.
Децентрализованный идентификатор (DID)
DID — это машиночитаемый идентификатор любой личности, организации или предмета. С помощью него можно подтверждать контроль над цифровой идентичностью и выпускать или получать верифицируемые идентификационные данные.
Пользователь может иметь множество идентификаторов (для бизнеса, для правительства, для близких друзей). Как правило, идентификаторы бесплатны, их легко генерировать и контролировать.
Верифицируемые идентификационные документы (Verifiable Credential)
Верифицируемые идентификационные документы — документы и факты, выпускаемые одним DID-эмитентом, а затем пересылаемые другому (владельцу). Эмитент и владелец могут быть одной и той же структурой, хотя обычно это не так. В зависимости от сценария использования, верифицируемые идентификационные документы могут быть как самым простым фрагментом данных (подтверждением адреса электронной почты, телефонного номера или физического адреса), так и относительно сложной структурой вроде выписки с банковского счета.
Архитектура SSI. Данные: Medium.
Четыре элемента SSI образуют стековую архитектуру:
После успешной аутентификации на уровне Verifiable Credentials можно посылать различные идентификационные документы для подтверждения пользовательской идентичности. Взаимодействие уровней напоминает работу набора TCP/IP-протоколов. Каждый уровень имеет свои собственные протоколы и спецификации.
Какие организации SSI существуют?
Поскольку SSI требует тесного взаимодействия и координации серий протоколов, прогресс технологии зависит от унифицированной спецификации и хорошо проработанного протокола. Их могут обеспечить некоммерческие профильные организации, такие как:
Эти организации плодотворно работают на протяжении последних пяти лет. Самая активная из них — RWoT. С 2016 года, организация опубликовала 56 white papers, а также множество технических спецификаций и открытых исходных кодов.
Технические спецификации RWoT были представлены W3C и IETF для дальнейшей спецификации. Черновик спецификации DID в значительной степени основан на работе RWoT (даже сам термин SSI был создан в RWoT).
Какие спецификации используются в архитектуре SSI?
1. Децентрализованный идентификатор (DID)
DID — низший и самый критически важный уровень архитектуры SSI. Он отвечает за написание/прочтение идентичности в распределенном реестре. Состоящий из букв и цифр децентрализованный идентификатор уникален и привязан к DID-документу в конкретном распределенном реестре.
DID состоит из следующих компонентов:
2. Система децентрализованного управления ключами (Decentralized Key Management System)
Архитектура DKMS. Данные: Medium.
DKMS — основной интерфейс, позволяющий использовать SSI. Помимо связи с базовым DID, он должен обеспечивать хранение идентификационных данных, дубль закрытых ключей и т. д.
С точки зрения спецификаций, DKMS можно разделить на три подуровня:
Пока не существует единого стандарта спецификаций аутентификации DID, однако RWoT опубликовал множество документов, в которых рассматривается стандартизация.
Система DID-аутентификации выполняет одну задачу: позволяет пользователю подтверждать, что он обладает идентичностью. Требуется лишь доказать, что пользователь владеет закрытыми ключами, соответствующими открытым ключам SSI. После завершения аутентификации появляется возможность создать канал коммуникации, посредством которого индивидуумы могут обмениваться верифицированными идентификационными данными и другими ресурсами.
Существуют различные протоколы аутентификации — OAuth, OpenID и другие. Аналогично этим протоколам, система DID-аутентификации использует модель «вопрос-ответ»: верифицирующая сторона делает запрос, владелец ID отвечает, сторона подтверждает аутентичность ответа.
DID-аутентификация. Данные: Medium.
4. Verifiable Credential (VC)
VC — самая ранняя и зрелая спецификация в архитектуре SSI. В качестве протокола высокого уровня SSI она имеет только одно назначение: замещает все идентификационные документы в кошельке пользователя.
VC — криптографически защищенный цифровый сертификат, который можно использовать в различных приложениях. Благодаря VC идентичность представляет собой единое целое. Ее полностью контролирует владелец, который, в зависимости от сценария использования, может предъявлять те или иные идентификационные документы.
VC состоит из трех частей:
Как развивается SSI?
Последние несколько лет экосистема SSI стремительно развивается — появляются новые приложения, протоколы, спецификации.
Продукты и пилотные проекты на основе этой технологии запускают правительственные учреждения, корпорации и университеты: Министерство внутренней безопасности США, Комиссия Европейского Союза, Europass, Всемирный банк, Всемирный экономический форум, Массачусетский технологический институт, Гарвардский университет, Университет Беркли, Национальная служба здравоохранения Великобритании, Управление иммиграции и пограничного контроля Сингапура, компании IBM, Microsoft, SAP, Oracle, правительства Финляндии, Канады, Южной Кореи и многие другие.
В марте 2021 года корпорация Microsoft запустила решение децентрализованной идентификации личности ION на блокчейне биткоина с открытым исходным кодом. Технология позволит пользователям идентифицировать свою личность для получения доступа к определенной информации. В случае удаления учетной записи доступ к привязанным к аккаунту сервисам сохранится. По аналогии с подписанием транзакций в сети первой криптовалюты DID является доказательством владения. Индивидуальные ноды ION отвечают за мониторинг идентификаторов и внесение временных меток в блокчейн.
В апреле 2021 года стоящая за криптовалютой Cardano компания IOG (ранее IOHK) и правительство Эфиопии заключили соглашения о развертывании в этой стране децентрализованной идентификационной системы Atala PRISM. Решение внедрят в 3500 школах Эфиопии для защиты от несанкционированного доступа к записям об успеваемости 5 млн учащихся. В IOG считают, что Cardano и Atala Prism позволят «демократизировать социальные и финансовые услуги для 1,7 млрд африканцев».
Сотрудничество с IOG запустит реализацию правительственной стратегии «Цифровая Эфиопия 2025», в рамках которой власти ввели национальный стандарт идентификации. Atala PRISM стала первой системой выдачи удостоверений на его основе.
Количество приложений для конечного пользователя пока не настолько велико, как можно было бы ожидать от технологии, потенциально адресованной миллиардам пользователей.
Какие препятствия возникают на пути развития и принятия SSI?
На пути к массовому принятию технологии суверенной идентичности возникают следующие препятствия:
Причины, по которым традиционные бизнес-модели не работают в сфере SSI:
Подписывайтесь на новости ForkLog в Twitter!