2024年7月31日水曜日

JNSAデジタルアイデンティティWGから「特権ID管理解説書」の解説動画が出ています

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

JNSAのデジタルアイデンティティWGから「特権ID管理解説書」が出ているのは以前お伝えした?通りですが、WGリーダーの宮川さんから解説書の解説動画が出ています。



特権ID管理の話のみならず、当該WGの成り立ちやこれまでの歩みにも触れられていますので、昔の状況について知りたい人にもおすすめです。(ワーキンググループはすでに設立19年!の老舗WGです。来年は20周年記念です!素晴らしい。と言うことはほぼ初期から参加している私もすでに19年以上IDやってるのか・・・)

なお、特権ID管理解説書はこちらから参照できます。


いずれにしてもおすすめなのでぜひご覧ください。

2024年7月30日火曜日

選択的開示に関するReview論文を読む(4)

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

引き続き選択的開示に関する調査論文を読んでいきます。
Selective disclosure in digital credentials: A review

今回はゼロ知識証明(ZKP)の利用に関してです。


著者が調査した論文の60%がZKPについて言及されていたようですが、本論文では選択的開示のための手法としてZKPを利用しているものを対象として扱っています。

なお、著者はZKPを利用することで選択的開示について以下のように補完することができると述べています。
  • 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で要求されているように、個人情報のプライバシーを損なうことなく証明することができます。

  •  

一方で、ZKPを使うことによるデメリットとして以下を挙げています。
  • 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が必要とされる場合とそうでない場合について、バランスを取る必要があります。

確かに、としか言いようがありませんね。どうしても難しくなりがちなので、実装ミスにも繋がりますので、この辺はバランスをとっていくことになるんだと思います。

2024年7月29日月曜日

Chrome 128ベータでDigital Credentials APIに対応

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

IIWでもGoogleとAppleの方々が発表していたDigita Credential APIがChrome 128ベータに載ってきましたね。
IIW #38 Day2クイックレビュー

Digital Credentials APIの仕様(Editor's draft)

Google for DevelopersのChrome 128ベータのサイト

こう記載されています。

ウェブサイトは、さまざまな方法でモバイル ウォレット アプリに認証情報をリクエストできます。 カスタム URL ハンドラや QR コードのスキャンなど、新しいメカニズムを取り入れています。この 使用すると、サイトが Google Cloud 内のデジタル認証情報から ID 情報を 使用してウォレット アカウントを作成できます。Kubernetes は、 複数の認証情報形式に対応(例: ISO mDoc や W3C による検証可能な) 複数のウォレット アプリを使用できるようにします。この API には エコシステム全体でセンシティブ アイデンティティが悪用されるリスクを軽減するメカニズム 情報です。

日本語版で表示すると「Digital Credentials APIのオリジン トライアルに登録します」
は404になるので言語を英語に切り替えて表示するのがよいと思います。
直リンクしておくとこちらになります。

試すには上記サイトからOriginの登録などを行う必要があります。



他にもChrome 128ベータではFedCM関係のUpdateなどもあります。日々進化してますね。

2024年7月28日日曜日

Digital YatraはAWS上で動いている”自己主権型ID”システムらしい

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

先日、インドの空港で使われているDigital Yatraについて書きました。

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

その後も色々と調べていたらAWSの事例になっているんですね。

AWSの事例サイトより


どうやら前回のポストで引用した15-20秒が5秒になったのは搭乗ゲートの話だったようです。
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

2024年7月27日土曜日

[Auth0/Okta CIC]ログインに使う識別子にメールアドレス・ユーザ名・電話番号を使う

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

たまにはAuth0/Okta CICを。
Auth0/Okta CICはログインする時の識別子はデフォルトでメールアドレスになっています。
これをユーザ名や電話番号を使うように設定することもできます、という話です。

ドキュメントはこちらにありますので、実際に設定する場合は注意点を含めこちらをみてください。


設定は簡単です。
ユーザ名とパスワードでの認証するコネクター「Username-Password-Authentication」の設定を開きます。

この中にAttributesというタブがあるので開きます。
するとNew Attributes ConfigurationがあるのでActivateします。(デフォルトはEmailのみってことですね)

確認されますので、Proceedを選択して進めます。


すると「Add Attribute」というボタンがアクティブ化されます。



クリックすると識別子として利用する属性を選択するポップアップが出ます。ユーザ名もしくは電話番号が選択できるようになります。

ユーザ名を選択すると関連する設定を行うことができます。
- ユーザ名を識別子として使うかどうか
- ユーザ名を使ってサインアップすることを許可するか(オプションか必須か)
- ユーザプロファイルとしてユーザ名を要求するか
- ユーザ名の文字列の長さ

また、詳細設定ではメールアドレス形式でユーザ名を許可するかの設定もできます。(現時点では電話番号形式のユーザ名は使えません。まぁ、正直どういうシナリオで使うのか不明ですが)


設定を終えるとログイン画面の入力ボックスに「ユーザー名またはメールアドレス」という形で表示が変わります。

また、サインアップ画面でもメールアドレスに加えてユーザー名も要求されるようになります。


なお、電話番号の方も似たような設定を行います。

設定が終わるとログイン画面が「電話、ユーザー名、またはメール」という表示に変わります。

サインアップ時に電話番号も入力が求められるようになります。


システムを移行する時など、複数の形式の識別子が混在するケースもありますので、そういうケースでは使えそうな機能ですね。
一方で通常はあんまり複数の形式のログインIDを有効にしておくとユーザも混乱しそうなので、割り切りも必要だと思います。

2024年7月26日金曜日

国ごとの国民IDカードのポリシーと状況

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

色々と調べていたらこんなものを見つけました。

List of national identity card policies by country 

要するに国ごとに国が発行する身分証明書(Identity Document)がどのような状態なのかをまとめたリストです。(ちなみに運転免許証などは除外されていて、いわゆる国民IDカードのみがリスト化されています)

大きく分けると、取得が義務化されているのか、それとも任意取得なのかで分かれています。
赤:義務化されている国 青:任意取得の国


こうやってみると圧倒的に義務化されている国が多いんですね。任意取得なのは日本とアメリカとヨーロッパの一部くらい。ある意味特徴が出ていて面白いです。

ちなみに取得が義務化されている国の例ですが、私の第2の故郷であるバーレーンではこんな感じです。
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年に導入され、住基カードを置き換えます。

なるほど。


こういうデータがまとまっていると色々とインサイトが得られるので面白いですね。 

 

 




2024年7月25日木曜日

OpenID Connect for Identity Assuranceの最終版がPublic Review期間に入りました

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

ついに、です。
私も(あまり働かない)共同議長をやっているOpenID FoundationのeKYC and Identity Assurance Working Groupの主要スペックである、以下の3つの仕様の最終版がPublic Review期間に入りました。
アナウンスはこちら



仕様編集者の皆さん、本当にお疲れ様でした。

この後のスケジュールですが、
  • レビュー期間:7/24 - 9/22(60日間)
  • 投票のアナウンス:9/9
  • 早期投票のオープン:9/16
  • 最終投票期間:9/23 - 9/30(7日間)

皆さんぜひ仕様を見ていただきコメントをいただければと思います。

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年7月23日火曜日

選択的開示に関するReview論文を読む(3)

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

引き続き選択的開示に関する調査論文を読んでいきます。
Selective disclosure in digital credentials: A review


今回はクレデンシャルのタイプごとに採用される選択的開示の手法の違いがあるかどうか、という話です。

リサーチの方法が結構面白くて、2007年から2022年までに発表されたタイプ別の選択的開示の方式、ゼロ知識証明の利用有無、ブロックチェーンの利用有無をまとめて傾向分析をしています。
分析結果から「2020年までは選択的開示署名ベース、ハッシュ値ベースの方式を採用したAC(Anonymous Credential)とABC(Attribute Based Credential)が中心だったのが、2020年以降はVC(Verifiable Credential)とZKP(ゼロ知識証明)を組み合わせた方法に焦点が当たってきている」と結論づけられています。もちろんリサーチベースの傾向なので実装とは別だとは思いますが、いよいよVC+ZKPが技術的にも確立されてきている、ということなのかもしれません。

こんな感じで方式ベースでクレデンシャルタイプを調査した結果が記載されています。

Table 8. Methods, credentials, ZKP and blockchain in years.

MethodPaperYearCredential typeZKPBlockchain
Hash-based[54]2007Digital credential
[55]2008Digital credential
[56]2010Digital credential
[61]2017ABC
[50]2019Digital credential
[52]2022VC
[63]2022Digital credential
[64]2023VC
[62]2023Digital credential
[57]2023SBT
Signature-based[69]2008AC
[67]2009Digital credential
[72]2015AC
[68]2019ABC
[70]2020AC
[71]2022VC
[74]2023ABC
[79]2023AC
[77]2023ABC
[75]2023AC
ZKP[82]2019ABC
[83]2021VC
ZKP & Signature-based[87]2013AC
[78]2018ABC
[88]2021PABC
[89]2022ABC
ZKP & Hash-based[85]2023VC
[86]2023AC
Signature-based & Hash-based[90]2020VC
[91]2022VC

別表では切り口が少し異なっていてクレデンシャルタイプを軸に分析しています。

Table 9. Comparison of different credential types.

TypeAlgorithmaZKPaBlockchainaExamplesMaturityEncodingCharacteristics
Digital credentialHash//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.
ACSignature/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.
ABCSignatureIdemix,
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.
PABCZKP & 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.
SBTHash//Smart contracts, token metadataLack 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.
VCAllHyperLedger AnonCreds SD-JWT,
Multiple wallets
W3C VCJSON,
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.

これらをマッピングして図示するとこんな感じになる様です。


なかなか興味深いですね。