- Granular control over data sharing — necessary attributes are proven without being revealed;
- Enhanced privacy — sensitive information does not need to be revealed, which reduces the risk of data exposure and lowers the chances of identity theft and fraud since the actual information is not disclosed, just proven;
- Increased trust — allowing the user to control the revealed or proven data, the level of trust increases among users;
- Post-quantum security — certain methods are resistant to quantum attacks;
- Compliance and regulatory adherence — using ZKP compliance and identity can be proved without compromising personal data privacy, as demanded by GDPR or CCPA.
データ共有のきめ細かい管理 — 必要な属性は公開されることなく証明される。
プライバシー保護の強化 — 機密情報を公開する必要がないため、データ漏洩のリスクが軽減され、実際の情報が開示されるのではなく証明されるだけなので、個人情報の盗難や詐欺に遭う可能性も低くなります。
信頼性の向上 — 公開または証明されたデータをユーザーが管理できるため、ユーザー間の信頼度が高まります。
ポスト量子セキュリティ — 特定の方法は量子攻撃に耐性があります。
コンプライアンスと規制遵守 — ZKPコンプライアンスとIDを使用することで、GDPRやCCPAで要求されているように、個人情報のプライバシーを損なうことなく証明することができます。
- Complexity — creation and verification with ZKPs can be computationally intensive, which is a problem for systems not optimized for such operations;
- Issues of understanding — designing systems that use ZKPs correctly requires cryptographic expertise, which can be a barrier to widespread adoption;
- Scalability — since ZKPs are computationally intensive, scaling them for large scaling applications remains a challenge;
- Interoperability — integration of ZKP within existing infrastructure is often complex;
- Trusted setup and auditing — some methods require a trusted setup phase;
- Privacy vs. regulation — a balance must be achieved for when ZKP is needed and when it is not.
- 複雑性 — ZKP を用いた作成と検証には膨大な計算処理が必要となり、そのような処理に最適化されていないシステムにとっては問題となります。
- 理解の問題 — ZKPを正しく使用するシステムの設計には暗号化の専門知識が必要であり、これが普及の妨げとなる可能性がある。
- スケーラビリティ — ZKPは計算負荷が高いので、大規模なスケーリングアプリケーションへの適用は依然として課題となっています。
- 相互運用性 — 既存のインフラストラクチャに ZKP を統合することは、しばしば複雑である。
- 信頼性の高い設定と監査 — 信頼性の高い設定段階を必要とする方法もあります。
- プライバシーと規制 — ZKPが必要とされる場合とそうでない場合について、バランスを取る必要があります。
ウェブサイトは、さまざまな方法でモバイル ウォレット アプリに認証情報をリクエストできます。 カスタム URL ハンドラや QR コードのスキャンなど、新しいメカニズムを取り入れています。この 使用すると、サイトが Google Cloud 内のデジタル認証情報から ID 情報を 使用してウォレット アカウントを作成できます。Kubernetes は、 複数の認証情報形式に対応（例: ISO mDoc や W3C による検証可能な） 複数のウォレット アプリを使用できるようにします。この API には エコシステム全体でセンシティブ アイデンティティが悪用されるリスクを軽減するメカニズム 情報です。
 |
| AWSの事例サイトより |
This innovation has significantly reduced processing and waiting times at various airport checkpoints, with processing times at entry gates dropping from an average of 15 seconds to approximately 5 seconds, while also improving processing times at other checkpoints. It also enhances the passenger experience by eliminating the need for manual ID and travel document checks.
搭乗ゲートで15秒とか20秒は掛かり過ぎじゃ？？と思ったり。
そして中身はCognito＋顔認証＋Aadhaarみたいです。
DYF designed and developed the Digi Yatra mobile app on Amazon Web Services (AWS), using Amazon Cognito, a secure, frictionless customer identity and access management service that scales to authenticate passengers with an access token. This feature signs in users by sending them an SMS message through Amazon Simple Notification Service (Amazon SNS) with a one-time verification code. Following this step, passengers are required to utilize their Aadhaar, a 12-digit unique identification number, for an Aadhaar ID validation process. This can be done by using either direct Aadhaar validation or the Digi Locker Aadhaar e-Know Your Customer (KYC) document. Once the e-KYC document is received, the face biometric is extracted by the Digi Yatra App and the passenger is prompted to take and upload a selfie. This selfie image is matched with the e-KYC reference face, and the ID credentials are created. The sign-in process triggers functions on AWS Lambda, a serverless, event-driven compute service that manages generation and verification of the user’s verifiable credentials. Khadakbhavi states, “The system operates as a paperless, contactless solution, where the passenger's face effectively transforms into the boarding pass. The selfie serves as the single token throughout the entire boarding journey.”
DYFは、Amazon Cognitoという、乗客の認証にアクセストークンを使用する、安全でスムーズな顧客IDおよびアクセス管理サービスを使用して、Amazon Web Services（AWS）上でDigi Yatraモバイルアプリを設計・開発しました。この機能は、Amazon Simple Notification Service（Amazon SNS）を通じてSMSメッセージにワンタイム検証コードを送信することでユーザーをサインインさせます。この手順の後、乗客は Aadhaar ID 検証プロセスに 12 桁の固有の識別番号である Aadhaar を使用する必要があります。これは、直接 Aadhaar 検証または Digi Locker Aadhaar e-Know Your Customer (KYC) 文書を使用して行うことができます。e-KYC 文書を受信すると、Digi Yatra アプリによって顔認証情報が抽出され、乗客は自撮り写真を撮影してアップロードするよう指示されます。この自撮り画像は e-KYC の参照用顔写真と照合され、ID 認証情報が作成されます。サインインプロセスは、AWS Lambda の機能を起動します。AWS Lambda は、サーバーレスでイベント駆動型のコンピューティングサービスであり、ユーザーの検証可能な認証情報の生成と検証を管理します。Khadakbhavi 氏は、「このシステムは、乗客の顔写真が搭乗券に変わる、ペーパーレスで非接触型のソリューションとして動作します。自撮り写真は、搭乗手続きのすべての行程で唯一のトークンとして機能します。
なるほど。よくあるサインアップ時にKYCしてIDドキュメントの顔写真と自撮り写真の比較、それ以降は自撮り写真をベースにサービス利用時の顔認証を行うってパターンですね。
At the airport, travelers simply open the app and scan the QR code at the airport entry e-gate. Instantly, the app retrieves their credentials, including face biometric and boarding pass data. Their live face is then captured and matched with the shared ID face, while the validation of the travel document itself occurs seamlessly in the background with the airline Departure Control System.”
空港では、旅行者はアプリを起動し、空港入口の電子ゲートでQRコードをスキャンするだけです。すると、顔認証データや搭乗券データを含む旅行者の認証情報が即座にアプリに取得されます。次に、旅行者の顔が撮影され、共有されたIDの顔と照合されます。旅行書類自体の検証は、航空会社の出発管理システムによりバックグラウンドでシームレスに行われます。
航空会社側で持っている予約情報などをアプリへ読み込む際に一緒に顔情報もサーバサイドが持っているものとその場の利用者の顔情報の照合をする感じですね。まぁ特徴点だけでしょうけど。サーバサイドに生体情報を持つことの是非は国にもよるんでしょうが便利ではあるんだろうなぁ。。
しかし、自己主権型っていうのを止めれば？くらいに集中管理型のシステムですよねw
 |
| 赤：義務化されている国 青：任意取得の国 |
Central Population Register (CPR) is a nine digit (all numeric) identification number which is also called as personal number issued for all the residents living in Bahrain. In order to use basic or any services, carry out financial transactions one must have CPR.
中央人口登録（CPR）は、バーレーン在住のすべての住民に発行される9桁（すべて数字）の識別番号で、個人番号とも呼ばれます。基本的なサービスやその他のサービスを利用したり、金融取引を行うには、CPRが必要です。
一方で任意取得にカテゴライズされている日本はこんな感じです。
An Individual Number Card is issued to citizens of Japan as well as legal residents. It was introduced in 2016 and replaces the Juki-Card.
マイナンバーカードは、日本国民および永住権保持者に発行されます。2016年に導入され、住基カードを置き換えます。
なるほど。
こういうデータがまとまっていると色々とインサイトが得られるので面白いですね。
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による自己主権型アイデンティティのソリューションである、と書いています。
どうしてもTravel Passというとe-Passport系の話に頭が入ってしまいますが、空港での顧客体験の向上、というキーワードでも色々と適用できそうな場面はありそうですね。
Table 8. Methods, credentials, ZKP and blockchain in years.
| Method | Paper | Year | Credential type | ZKP | Blockchain |
|---|---|---|---|---|---|
| Hash-based | [54] | 2007 | Digital credential | ||
| [55] | 2008 | Digital credential | |||
| [56] | 2010 | Digital credential | ✓ | ||
| [61] | 2017 | ABC | |||
| [50] | 2019 | Digital credential | ✓ | ||
| [52] | 2022 | VC | ✓ | ||
| [63] | 2022 | Digital credential | ✓ | ✓ | |
| [64] | 2023 | VC | ✓ | ||
| [62] | 2023 | Digital credential | ✓ | ||
| [57] | 2023 | SBT | ✓ | ||
| Signature-based | [69] | 2008 | AC | ✓ | |
| [67] | 2009 | Digital credential | |||
| [72] | 2015 | AC | ✓ | ||
| [68] | 2019 | ABC | ✓ | ||
| [70] | 2020 | AC | ✓ | ||
| [71] | 2022 | VC | ✓ | ✓ | |
| [74] | 2023 | ABC | ✓ | ||
| [79] | 2023 | AC | ✓ | ||
| [77] | 2023 | ABC | ✓ | ✓ | |
| [75] | 2023 | AC | ✓ | ||
| ZKP | [82] | 2019 | ABC | ✓ | ✓ |
| [83] | 2021 | VC | ✓ | ✓ | |
| ZKP & Signature-based | [87] | 2013 | AC | ✓ | |
| [78] | 2018 | ABC | ✓ | ✓ | |
| [88] | 2021 | PABC | ✓ | ||
| [89] | 2022 | ABC | ✓ | ||
| ZKP & Hash-based | [85] | 2023 | VC | ✓ | ✓ |
| [86] | 2023 | AC | ✓ | ✓ | |
| Signature-based & Hash-based | [90] | 2020 | VC | ✓ | |
| [91] | 2022 | VC | ✓ |
Table 9. Comparison of different credential types.
| Type | Algorithma | ZKPa | Blockchaina | Examples | Maturity | Encoding | Characteristics |
|---|---|---|---|---|---|---|---|
| Digital credential | Hash | / | / | XML, JSON, PDF, blockchain-based formats, cryptographic tokens, smart contracts | Electronic versions of paper credentials. Any form of digital certification. Easily shareable, verifiable online and can improve administrative efficiency. Focused on transparency and traceability. More general and not inherently designed for privacy enhancement, unless otherwise specified. | ||
| AC | Signature | ✓ | / | JSON, XML, cryptographic tokens | Designed for anonymity of user. Enhances privacy and security by preventing user tracking and profiling. Complex in implementation. Misuse in avoiding accountability possible. ZKP enhancements and signatures can be computationally intensive. Extended versions more commonly used in practice. | ||
| ABC | Signature | ✓ | Idemix, U-prove | IBM, Microsoft, ABC4Trust, PrimeLife | JSON, XML, cryptographic tokens | Extension of ACs focused on attributes. Offers fine granularity over attributes disclosed. Increases user control and enhances privacy. Can be less efficient in terms of computation and storage. Flexibility requires strict policy enforcement mechanisms. Implemented and standardized through extensive work on it. | |
| PABC | ZKP & Signature | ✓ | / | / | JSON, cryptographic proofs | Privacy enhancement of ABCs through the use of ZKPs. Maximizes privacy by ensuring minimal data exposure. Increases complexity and computational costs are higher. Lack of standardizations and practical usage. | |
| SBT | Hash | ✓ | / | / | Smart contracts, token metadata | Lack of standardization and practical usage. Reliable and immutable proof of attributes. Depends on blockchain which can cause scalability issues. Non-transferability enhances security but causes lack of flexibility and is restrictive. | |
| VC | All | ✓ | ✓ | HyperLedger AnonCreds SD-JWT, Multiple wallets | W3C VC | JSON, JSON-LD, JWT, JWP | Standardized format. Credentials can be independently verified (without direct access to the issuer). Highly interoperable and secure. Enhances trust and reduces fraud. Complex in implementation. Needs widespread adoption of the standard. |
投稿
すべてのコメント
