ラベル SSI の投稿を表示しています。 すべての投稿を表示
ラベル SSI の投稿を表示しています。 すべての投稿を表示

2024年7月24日水曜日

空港でのVerifiable Credentialsのユースケース、Digi Yatraが400万ユーザを超えたらしい

こんにちは、富士榮です。

インドの空港で使える、Verifiable Credentialsベースのクレデンシャルにより空港でのシームレス体験*を提供するDigi Yatraが14の空港、400万ユーザを超えたらしいです。
* 空港でのチェックイン、保安検査場、ゲート入場、荷物預けを顔認証でできるらしい

ちょっと前のニュースですがCXO Onlineの記事

Starting with just three airports, Delhi, Bengaluru, and Varanasi, Digi Yatra has expanded its footprint across major airports in the country, including Mumbai, Hyderabad, Pune and Kolkata. Currently operational at 14 airports, very soon  Digi Yatra plans to expand to an additional 15 airports.

3つの空港から始まって現在14の空港で利用でき、もうすぐ15番目の空港でも使えるようにする予定らしいです。

By adopting Digi Yatra, passengers have been able to cut down on airport entry time from 15-20 seconds to around 5 seconds.

これまで15-20秒かかっていた空港への入場が5秒で済むようになったとのこと。20秒ならいいじゃんって思ってしまいますが、インドくらいの人口のところだとものすごい効果なのかもしれません。

まぁ、日本でも顔認証ゲートは導入されているので、VCベースかどうかは置いておいて、この流れは世界へ広がっていくんでしょうね。

羽田の顔認証ゲート

https://tokyo-haneda.com/site_resource/flight/pdf/how_to_use_Face_Express_en.pdf




ちなみにあまり詳しい技術情報は書いてありませんが、Digi YatraのCEOの方がFinancial Expressに寄稿した記事には分散Ledgerを使ったDIDとVCによる自己主権型アイデンティティのソリューションである、と書いています。

https://www.financialexpress.com/business/industry-verifiable-credentials-facilitating-safe-travel-amid-privacy-issues-3558500/


どうしてもTravel Passというとe-Passport系の話に頭が入ってしまいますが、空港での顧客体験の向上、というキーワードでも色々と適用できそうな場面はありそうですね。

2024年3月30日土曜日

自己主権型IDとフェデレーション型IDに関する議論

こんにちは、富士榮です。

今日はちょっと前の記事ですが、SSIとFederationについてHeather Flanaganさんが考えを書いているので紹介しようと思います。IDProや古くはKantaraやREFEDSなどで活動されている方ですね。しかしSSIがいいのかFederationがいいのかっていうのは色々なところで色々な人たちが議論をしていますが、明快な答えってないですよね。まぁそれもそのはず「時と場合による」話でしかないのと、一番大きいのが技術の話をしているのか思想の話をしているのか、みなさんMixしているのでクリアな議論にならないっていうのがあるからですね。

ということでちょっと見ていきましょう。
Federated Identity and SSI – YMMV

ご本人もYMMV(your mileage may vary)って書かれているように、「どう受け取るかはみなさん次第」ということです。

また冒頭にも記載されていますが、そんなに世の中単純じゃないので全てにフィットするものなんてないよね、ということを書かれています。
There is no “one size fits all,” though passionate proponents of various technologies may beg to differ. Alas, the world is not that simple:
そして、こうとも書かれています。
誰もが SSI という用語を好むわけではないことを認識しましょう。デジタルウォレットテクノロジーがこのカテゴリーに該当するかどうかは不明です。そうだと言う人もいれば、そうでない人もいます。 SSI の初期の支持者たちがほぼブロックチェーン技術だけに焦点を当てていたことに、すぐに嫌悪感を抱く人もいます。
すみません。技術としてブロックチェーンの良し悪しを述べるつもりはありませんが、私もSSIアレルギーっぽくなってしまってきているのはこの点なのかもしれません。

そして、色々な切り口でSSIとFederated Identityを比較していっています。

Dicsovery

まずはDiscoveryです。
どちらのモデルでも、個人がどの資格情報を使用するかを選択できる必要があります。これは、Federated Identity 内で、リストから ID プロバイダー (IdP) を選択するか、その ID をダイアログ ボックスに入力できることを意味します。 SSI モデルでは、これは、ローカルに保存された資格情報のリストから選択できること、または適切な資格情報を保存するために使用される適切なコンテナ (別名デジタル ウォレット) を選択できることを意味します。
FederatedモデルではいわゆるNASCAR問題を引き起こす原因でもあるのがこのDiscovery問題ですね。先日ポストしたWebfingerによるDiscoveryや学術機関で使っているDiscovery Service(DS)なんかはこの課題に対応するためのソリューションとして考えられましたが、まだ完全に解決しているとは言えない状態です。


共有される情報の制御

次に触れられているのがIdPとRPの間で共有される情報の制御に関する相違点です。
When talking about federated identity models, protocols like the Security Assertion Markup Language (SAML), OAuth, and OpenID Connect are what describe (and constrain) everything including the claims, the assertions used, the structure of the attributes shared, the way identity provider discovery is handled, and more. A great deal of control is given to both the RP and the IdP, and there is a coarse level of control for the individual (generally in the form of “you can either choose to log in or not, but you aren’t guaranteed control over what information is shared as a result”).

とあるようにやり取りされる情報の内容や構造についての制御の大半はIdPとRPが行うことになり、ユーザが制御できるのは「ログインするのか、しないのか?」程度になってしまいます。

その点、SSIのモデルではユーザによる選択(特にSD-JWTやmDLなどの選択的開示)が中心となっています。

(個人的な意見)これはどうなんだろうなぁ・・・。Federatedだからユーザに選択権がないっていうのは既存のIdPの実装の問題なんじゃないかな?とも思います。本来は属性の選択的開示をするように属性提供同意画面でオプトアウトできるようになっているべきだし、先ほどのNASCAR問題はあるものの使うクレデンシャル(あえてクレデンシャルと言いますが使うIdPのこと)も自分で選ぶことができるようにDiscoveryの設計をするのがRP側の仕事だったのでは?とも思います。これはSSIだったとしてもVerifierが何を求めるのか、Issuerが何を発行するのか、Walletがその情報をどう扱うのか、、など本当にユーザに制御権ってあるんでしょうかねぇ。。とは言え、Federatedモデルではそのあたりの実装有無をIdPやRPが握ってしまっているのは事実ではあります。

横道にそれました。

クロスデバイスのサポート

もう一つのSSIの特徴としてパスワードからの脱却の文脈を含めクロスデバイスの話が出てきます。

(たとえば) 複数のデバイスにパスワードを記憶したりコピーしたりする必要があるのではなく、1 台のモバイル デバイスに保存されている資格情報を、デスクトップやタブレットなどの別のデバイスの認証または認可プロセスで使用できます。

CIBAとかDevice Code Flowがあるじゃないか、とかパスキーでよくない?という話もありそうですが、まぁ確かに特徴の一つではあります。

一方で課題も

これ、本当に大切な問題だと思います。UXとプライバシー。

UX の課題は非常に重大です。 SSI モデルを前進させるために開発中のテクノロジーは、単なる ID をサポートするものではありません。また、支払いシステム、交通チケット、図書館カード、保険カード、ホテルのキー、車のキーなど、リストはさらに続きます。このモデルを、これらすべてのカードを物理的な財布に入れているのと似ていると比較することはできますが、カードが多すぎて、必要なときに適切なカードを見つけることができないという点が生じます

先ほどのNASCAR問題にも通じますが、これまでIdP側で発生していた問題が手元(Wallet)に移動してきただけです。

プライバシーの問題も重大です。

プライバシーへの配慮が使いやすさをさらに難しくしています。資格情報はデジタル ウォレットに保存されることが多く、そのウォレットはランダムなリクエストから資格情報を保護します。おそらく、物理的なウォレットが保持するカードと何の関係もないのと同じように、ウォレットは、保持する認証情報と何の関係も持つべきではありません。ここでの複雑さの可能性を最大限に高めるために、さまざまな認証情報を保持するウォレットが複数ある可能性があります。 

これ、本当に難しい問題でWallet提供者は、そのWalletの中にユーザが何を入れるのか?を把握できたらFederated時代のIdPによる行動把握の比較にならないくらいヤバい話になると思います。この辺りは特に政府が提供するWallet、なんて話も出ていますが十分すぎるくらいの透明性を持たせないといけないと思います。

Digital Identity Wallet(DIW)に関するPoC開発・調査について

https://trustedweb.go.jp/public-offering/2023/trusted_web2023_diw

さらに、どこまでユーザに責任を押し付けるのか、という問題もあります。

人々が正しい選択をする可能性は低いと想定し、さまざまな自由や技術革新を制限することで国民を守るパターナリスティックな国民国家に誰もが住みたいわけではない。とはいえ、その行動の影響が明らかかどうかにかかわらず、自分の行動に責任を個人に負わせる完全な自由主義的な環境での生活を誰もが望んでいるわけではありません。

この辺りは先日ポストした「自己主権型アイデンティティは本当か?情報銀行からの学びはあるのか?」にも書きましたが、本当の意味での情報銀行的な役割をWalletプロバイダが追うことになる日も来るのかもしれません。

https://idmlab.eidentity.jp/2024/03/blog-post_11.html


まとめ

結局結論なんて言うものは出ないわけですが、彼女の以下の3つの言葉が重要だっていうことです。

従来のフェデレーション ID モデルと新しい SSI アーキテクチャは相互に排他的ではありません。彼らはさまざまな問題を解決することだけに集中します。 

現在見られるテクノロジーは完全に完成したわけではなく、技術者が望むすべてを解決するにはまだ成長する必要があります。

これらのテクノロジーの開発と展開の指導に確実に貢献するために、ディスカッションに参加することです。 


これからもコントリビューションしていきましょう。

2024年3月11日月曜日

自己主権型アイデンティティは本当か?情報銀行からの学びはあるのか?

こんにちは、富士榮です。

ちょっと前に情報銀行の認定事業の最後の一つだったDataSignさんのPaspitがサービス停止をしたことで通常認定がゼロになった、というニュースが界隈で出ていました。
DataSignさんのニュースリリース

情報銀行「paspit」サービス終了のお知らせ 

https://datasign.jp/blog/paspit-announce/ 

結果、IT連盟の通常認定がゼロになっています。

https://tpdms.jp/certified/


ちなみにP認定はまだありますが、そもそもP認定は「「情報銀行」サービス開始に先立って立案した計画、運営・実行体制が認定基準に適合しているサービスであることを認定するものです。サービス開始後において運営・実行、改善を図り、『通常認定』の取得が条件となります(P認定の更新は不可)。」という定義なのでサービスが開始されていない(もしくはサービスを開始する前の検討段階)のものなので、実質サービスとして提供されているものではありません。なので本当にゼロ件です。

この分野はそれほど詳しいわけではありませんが、そもそもの情報銀行の意義は利用者が自分の情報を適切に扱ってくれるサービスに適切に渡すために情報銀行サービス事業者に情報を信託することで安心してサービスを利用できるようにしましょう、という取り組みだったはずです。つまり、前提として情報銀行サービスが情報を提供する先の審査を行い、適切に情報を扱うことが確認できている場合に情報を提供することでリテラシーのあまり高くない利用者を保護しましょう、という話です。これは正に信託銀行が利用者の代わりに株式や資産の運用を行うことで利用者個人が過剰に責任を負うことなく安全に資産運用ができるようにしましょう、という話と同様のもので、その意味で情報(信託)銀行だったわけです。
しかしながら、実態として情報銀行においては、この信託銀行や銀行の本来の価値である利用者に変わって比較的安全に運用を行いましょう、という部分が私たちの頭から抜け落ちていたように感じます。結果、単に個人情報をサービス事業者に預けると利子(ポイントなどのリワード)がつく、雑に言うと「個人情報を売っている」感覚に近くなっていき敬遠されていく、というサイクルだったのかな?と思ったりしています。

ちなみにこの話は本日のコラムのテーマでもある「自己主権」についても隣接する話題だと思っています。今日はそんな話です。

自己主権とユーザの責任

これまでも自己主権型IDの責任モデルについてあちこちでお話してきました。
(2019年ごろによく使っていたスライド)


また、主権?という話についても正直疑問に思っている、という話も何度もしてきました。
(昨年のOpenID TechNight、分散型ID勉強会の資料より)


この辺りを踏まえて少し自己主権型アイデンティティについて考えてみましょう。
簡単にまとめると、自己主権アイデンティティのモデルにはユーザの責任が重くなりすぎると言う点で以下の通り課題があると思っています。
  • 自己主権の一番の難しさは結果的にユーザに責任を押し付けることになること
  • つまり、ユーザは誰に情報を提示して良いのかを自身の責任で判断しないといけない
従来のID連携のモデルでは多くの場合RPとIdPの間で事前の信頼関係構築が前提となっていました。具体的にはIdPとRPはトラストフレームワークなどで表現されるID連携のために必要なルール(例えばRPは受け取ったID情報を適切に扱うこと、など)に基づき事前に合意している前提がありました。
そのため、IdPにアカウントを登録するユーザはIdPが連携できるRPをある程度審査していることを含めある程度納得した上でRPを使っているという建て付けになっている(利用規約とかポリシーに記載されている)わけです。

ただし、あくまでIdPがある程度担保してくれるためにはユーザが使うRPの情報などをIdPが知ることができてしまう、という点においてプライバシーリスクが指摘され、Walletを使うことでIssuer/Verifierの間にWalletが入り、ユーザ自身の意思を反映した形でID情報のやり取りが行われる=自己主権でありプライバシー上の問題がなくなる、という話になってきたわけです。

ところが、このことによりIssuerは、Verifierを事前に審査することができなくなるわけで、Verifierが適切なのかどうかを判断できず、あくまでユーザが自身の責任でVerifierに情報を提供しなければならない、ということになってきてしまいました。

果たしてユーザは責任をとれるのか

「自己責任」の一言で済ませられるのであればそれで議論は終了なわけですが、人類はそれほど賢いわけではありません。いつまで経っても秘密鍵やパスワードの管理を人類はできるようになっていないわけで、VCがWalletに入っていても正しく管理できるようになるとは思えません。
暗号資産についても結局は事業者に管理を委託しちゃってますよね。本来はあれもBitcoinのアドレスを自分で管理することもできるはずですが、結局はカストディアンに頼るのが自然な状態になっているわけです。

と言うことでどんな対応ができるのか考えてみる

結局はWalletをIssuerが管理化に置き、VCを提示できるVerifierを制限する、などが必要になるのかもしれません。しかしIssuerが管理をするモデルになると、従来のID連携モデルでIdPが利用者が使っているRPを知れてしまう、という問題の解決にならず、Walletモデルの意味がなくなってしまいます。
となると、もう選択肢になり得るのはWalletプロバイダが提示できるVerifierを制限するという形が良いのかも知れないな、と最近は思っています。
もちろん、Verifier毎に専用Walletを使う、などの対応をしないと今度はWalletプロバイダがユーザが使っているVerifierを知れてしまうという問題が出てくる可能性もあるのですが、このモデルだと結局自己責任モデルにしかなりませんし、Verifier毎にWalletが大量にインストールされているスマホを持ちたいとは思いません。(それこそカスタムURLスキーム問題で技術的にもややこしいことになりますし)

結局はユーザが安心してVerifierにID情報を提示することができる状態を作る必要があるわけなので、ユーザが誰かを信頼して委託する(つまり信託する)必要があるわけです。Walletプロバイダのモデルだと、ユーザは従来のID連携モデルでIdPを信頼したのと同様にWalletプロバイダを信頼することになります。
こうなると、Walletプロバイダに情報が集約することは諦めるしかないわけなのですが、
  • ID連携に比較してIdPへのCall home問題はなくなるのでIdPの可用性を含む全集中度合いは下げられる(別の切り口だが)
  • Walletプロバイダが本当に認定済みVerifierに対してVCを提示したかどうかはわからないようにWalletを作ることはできるはず
ということは考えられるわけで、ID連携のモデルとの差別化はできそうです。

これを実現するためには、Walletプロバイダが審査済みのVerifierのみにVCを提示可能にするなどの機能を実装し、VC提示の際に許可・不許可のリストをローカルで参照する仕組みになっていればWalletプロバイダは審査済みのVerifierのうち、実際にユーザがどこに対してVC提示を行ったかは検知できないようにはできるのではないかと思います。(本当にそんな実装になっているかどうかは信頼するしかないとは思いますが)

このことで、
  • ID連携におけるIdP万能という状態からは少し前進できている気はする
  • 多分、次のVC関連のビジネスはWalletプロバイダが本当の意味での情報銀行(提示先の審査による安心の提供)としての機能を提供することなのかも知れない(どこまで利用者からお金を取れるかは未知数だけど)
と思えます。
この辺は引き続き皆さんと意見公開をしつつモデルを考えていけるといいですね。

2019年11月30日土曜日

Hyperledger Indy, Ursa, Ariesのオンラインコースで自己主権型アイデンティティについて学習する

こんにちは、富士榮です。

先日開催されたW3C/TPAC@福岡でDID WGが正式に発足したり、DIFやSovrin Foundationが活発に活動していたり、と自己主権型アイデンティティ(Self Sovereign Identity/SSI)や分散型アイデンティティ(Decentralized Identifier/DID)のムーブメントも本格化してきましたね。

そういえば@IdentityWomanことKaliya姉さんがおそらく世界初のSSIの本「A Comprehensive Guide to Self Sovereign Identity」を出版したのも今年の4月だったのでまだ半年ちょっとしか経ってないんですよね。


そんな中、元々Evernym~Sovrin Foundationが開発してきたSSIのための分散台帳技術でLinux Foundationの進めるHyperledgerプロジェクトの一員となったHyperledger Indyや、Wallet間のPeer to peer通信のプロトコルの標準化を進めようとしているHyperledger Aries、暗号化ライブラリであるHyperledger UrsaのオンラインのトレーニングコースがedXで公開されました。
※日本語記事あり:https://crypto.watch.impress.co.jp/docs/news/1220/815/index.html

HyperledgerファミリーとIndy, Ursa, Aries(出典:Evernym)

ざっくりいうと、Indyが分散台帳技術そのものであるのに対して、UrsaはZKP(ゼロ知識証明)などに使う暗号化技術、AriesはWalletやAgent間の通信に関する技術、という整理っぽいですね。(私もまだ勉強中なので間違っていたらすみません)

IndyとAriesの関係の整理(出典:Evernym)



ということで、もう少し深く勉強してみるいい機会なのでコースを受講してみようと思います。(せっかくなので受講証明がもらえる有料コース/99USドルにしました。12/2までならクーポンコード「CYBER20」を入れると20ドルくらい割引になります)

以下、コース登録までの道のりです。(実際の内容はこれからなので、また気づきがあれば書こうと思います)

1.edXのコースサイトを開く

こちらが今回のターゲットとなるコースのURLです。
https://www.edx.org/course/identity-in-hyperledger-aries-indy-and-ursa


ここからEnrollを押してスタートしていきます。

2.会員登録を行う

メールアドレスで登録するか、Facebook、Google、Microsoftアカウントでアカウントを作成します。


作成が終わると、有料会員に誘われますw。せっかくなのでお金を払ってみようと思います。

3.有料会員登録を行う

会員登録後、誘われるがままに登録をしてみます。

どうやら有料登録をすると色々と特典があるようです。(最後のは特典なのか?)

  • Unlimited Course Access
  • Graded Assignments
  • Easily Sharable
  • Support our Mission
「Pursue the Verified Track」で迷わず購入へ進めましょう。

左の中央に「Add coupon code」があるので先ほどの「CYBER20」を登録すると20ドルくらい安くなります。(12/2までらしいですが)
クレジットカードがPayPalで支払えますが、私はPayPalで支払いました。

購入が終わると登録者の本人確認が行われます。

4.本人確認を行う(eKYC!!)

方法としてはWebカメラで顔とIDドキュメント(パスポートや免許証など。名前と顔写真が一致していることを見るっぽいので、実質日本人で使えるのはパスポートだけだと思いますが)の写真を撮り1日~2日くらい審査があるようです。


まずは顔写真を撮ります。(黒線は筆者都合w)

次にパスポートの写真を撮ります。

両方揃えてアップロードして審査待ちです。



5.コースの受講を開始する

とりあえず登録はこれで終わりなので、ゆっくりコースを受講していきます。


コース目次は以下の通りです。ゆっくり学習していこうかと。

  • Welcome!
  • Chapter 1: Something Is Missing
  • Chapter 2: Adding a Layer of Trust to the Internet
  • Chapter 3: SSI Using Indy, Aries and Ursa
  • Chapter 4: A Blockchain for Identity
  • Chapter 5: The All-Important Agent, Or Rather, Agents!
  • Chapter 6: When Things Go Wrong
  • Chapter 7: Possibilities
  • Final Exam

なかなか興味深いです。





2019年11月29日金曜日

Ignite Tour TokyoでAzure AD B2C + SSI/DIDの話をします

こんにちは、富士榮です。

あっという間に11月も終わりですね・・・

なんだか最近、月に2~3本の勢いでイベントでお話をしている気がします。おかげで色々と実験はしているもののBlogへのアウトプットが後手後手に回ってしまっていて反省です。

まぁ、その分講演の中では実験した内容を含めじっくりお話させていただいているつもりなので、是非機会があれば見に来ていただければ、ということで。

ということで、あっという間に来週の開催になってしまいましたが、12/5~6にIgnite Tour Tokyoがあり、こちらでAzure AD B2C + SSI/DIDの話をすることになっています。
基本的には前のde:codeEuropean Identity & Cloud ConferenceConsumer Identity World USAでお話してきた内容の続きではありますが、この自己主権型アイデンティティや分権型IDってキーワードが全くもってキャッチーじゃないので、地道に世界観を浸透させていくしかないのかな?と思っています。

ということでIgnite Tour Tokyoでは「分権型IDテクノロジーによる効率的な外部ユーザのID管理」というタイトルで「B2BやB2Cのシナリオにおいて外部アイデンティティの管理、特にIDの確認(KYCなど)は管理者にとって非常に頭の痛い問題です。本セッションではそれらの問題をAzure AD B2Cとブロックチェーンを使った自己主権型アイデンティティのシナリオでどのように解決するのかについて説明します。」という話をする予定です。

セッションコード:BRK30053
セッションURLはこちら)
https://tokyo.myignitetour.techcommunity.microsoft.com/sessions/87724


絶賛、過去のスライドをかき集めて準備中ですw

ベースはこの辺りなので、事前に目を通しておいていただけると理解がはやいかも。
de:codeの資料
 https://www.slideshare.net/naohiro.fujie/kyc-identity-on-blockchain
OSSコンソーシアムの資料
 https://www.slideshare.net/naohiro.fujie/kyc-153297605
didconの資料
 https://www.slideshare.net/naohiro.fujie/ssidid


では、当日お会いしましょう。