ECDSAに対応したゼロ知識証明の論文がGoogleから出ています

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

AAMVAのモバイル運転免許証のガイドラインでも触れましたが、mdocやSD-JWTのリンク可能性へ対応するためには今後ゼロ知識証明が大切になります。

年末にGoogleの研究者が

Anonymous credentials from ECDSA

というタイトルでペーパーを出しています。

https://eprint.iacr.org/2024/2010

AIでイラスト生成すると色々とおかしなことになって面白いですねw

アブストラクトの中からポイントを抜粋すると、従来のBBS+では暗号スイートへの対応に関する要件が厳しかったのでレガシーで対応できるようにECDSAでもできるようにしたよ、ということのようですね。

Part of the difficulty arises because schemes in the literature, such as BBS+, use new cryptographic assumptions that require system-wide changes to existing issuer infrastructure.  In addition,  issuers often require digital identity credentials to be *device-bound* by incorporating the device’s secure element into the presentation flow.  As a result, schemes like BBS+ require updates to the hardware secure elements and OS on every user's device.

その難しさの一部は、BBS+などの文献に記載されているスキームが、既存の発行者インフラストラクチャにシステム全体にわたる変更を必要とする新しい暗号化前提条件を使用していることに起因しています。さらに、発行者は、デバイスのセキュアエレメントを提示フローに組み込むことで、デジタルID認証をデバイスに紐づけることを求めることがよくあります。その結果、BBS+のようなスキームでは、すべてのユーザーのデバイスのハードウェアセキュアエレメントとOSのアップデートが必要になります。

In this paper, we propose a new anonymous credential scheme for the popular and legacy-deployed Elliptic Curve Digital Signature Algorithm (ECDSA) signature scheme.  By adding efficient zk arguments for statements about SHA256 and document parsing for ISO-standardized identity formats, our anonymous credential scheme is that first one that can be deployed *without* changing any issuer processes, *without* requiring changes to mobile devices, and *without* requiring non-standard cryptographic assumptions.

本稿では、広く普及し、レガシーシステムにも導入されている楕円曲線デジタル署名アルゴリズム（ECDSA）署名スキームのための新しい匿名クレデンシャルスキームを提案する。 SHA256に関する効率的なzk引数と、ISO標準化されたIDフォーマットの文書解析を追加することで、この匿名クレデンシャルスキームは、発行者側のプロセスを変更することなく、モバイルデバイスの変更を必要とすることなく、また、非標準の暗号化前提条件を必要とすることなく実装できる初めてのスキームです。

 なかなか期待できますね。生成速度に関してもこのような記載があります。

Our proofs for ECDSA can be generated in 60ms.  When incorporated into a fully standardized identity protocol such as the ISO MDOC standard, we can generate a zero-knowledge proof for the MDOC presentation flow in 1.2 seconds on mobile devices depending on the credential size. These advantages make our scheme a promising candidate for privacy-preserving digital identity applications.

当社のECDSAの証明書は60ミリ秒で生成できます。ISO MDOC標準のような完全に標準化されたアイデンティティプロトコルに組み込まれた場合、クレデンシャルのサイズにもよりますが、モバイルデバイス上でMDOCプレゼンテーションフロー用のゼロ知識証明書を1.2秒で生成できます。これらの利点により、当社の方式はプライバシー保護型デジタルアイデンティティアプリケーションの有望な候補となっています。

mdocのプレゼンテーション時にゼロ知識証明を1.2秒で生成、このくらいなら実用性がありそうですね。

論文の本文もPDFで閲覧できるようになっているので、おいおい見ていこうと思います。

 

 

Intention Economyその後

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

年末にDoc SearlsがIntention Economyについて「The Real Intention Economy」というポストをしています。かなり重要なポストだと思うので読んでおいた方が良さそうです。

https://doc.searls.com/2024/12/30/the-real-intention-economy/

彼の著書は日本語にも翻訳されていますね。

https://amzn.to/3C2PX9n

さて、今回のDocのポストに戻ると、彼がIntention Economyの考え方を発表してからもう直ぐ20年が経とうとしている現在、生成AIの文脈も相まって、Intention Economy自体が脅威となりつつある、という話です。

Intention Economyで検索すると結構ヤバ目の結果が返ってくるようになっているとのこと。

要するにIntention Economyというキーワードが悪用されつつある、ということですね。

こんなことも書かれていると言っています。

The near future could see AI assistants that forecast and influence our decision-making at an early stage, and sell these developing “intentions” in real-time to companies that can meet the need – even before we have made up our minds.

近い将来、AI アシスタントが早い段階で私たちの意思決定を予測して影響を与え、私たちが決断を下す前であっても、その発展中の「意図」をニーズを満たすことができる企業にリアルタイムで販売するようになるかもしれません。

同じくこんな引用もされています。

The rapid proliferation of large language models (LLMs) invites the possibility of a new marketplace for behavioral and psychological data that signals intent.

大規模言語モデル (LLM) の急速な普及により、意図を示す行動および心理データの新しい市場が生まれる可能性が生まれています。

もともと顧客の関心（Attention）を商品として販売するというモデルに対するアンチテーゼの文脈としての意図（Intention）を中心とした経済としてIntention Economyだったはずですが、その意図自体を商品として販売する、という市場が形成されてきつつあるということですね。

人間の欲望は果てしないわけですが、私たちは思想の源流をきちんと見据え、意図を理解した上で社会実装を進めたいものです。 

 

366/366 !!!

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

ついにこの日が来ました。

去年の正月休みに某猫とのチキンレースが始まってしまったので収まりがつかなくなって惰性で描き続けていましたが気がついたら本当に1年経ってしまいました。

↓某猫のポスト

ふじえさん、やっぱりやっとるな！
毎日記事を書く366チャレンジや！
これ絶対やっとるぞ！

— 👹秋田の猫🐱 (@ritou) January 4, 2024

最初のうちは割と実装してみよう！的なポストが多かったのですが、中盤〜後半は忙しくなりすぎたこともあり読んでみようシリーズが大半を占めてしまったのは反省です。

ということで振り返ってみましょう。

1月のポストはこんな感じです。

この頃は結構作ってますね。まぁ、冬休みが暇だったので実装し始めたのがきっかけだったので。

あとは1月はOpenID Summit Tokyoもありましたね。2024年の後半にかけて現在も活動が続いているSIDI Hubを日本で開催する調整も実はこの時期から始まっていました。

次に2月です。この辺りでそういえば今年は366日やん、と思って他の年よりも1日不利！！！ということに気がついた感じです。

まだ実装は続けていますね。OpenID Providerが一段落したのでパスキーに手を出し始めています。やっぱり手を動かさないとわからないことも多いなぁ、と実感した時期でもありました。

3月です。

まだ実装も続けいますが、色々とニュースも紹介し始めているのと、普段考えていることなんかもポストし始めていますね。結果、ポストを読んでくれた人たちと議論することもできたので非常に勉強になりました。

4月です。

2月ごろにデジタル庁の認証アプリについても色々と調べたり考えたりしていましたが、結果メディアの方々からもインタビューいただいたりもして、各種社会実装について深く考えた時期でもありました。個人的には新年度も重なったことで結構忙しかった記憶しかありません・・・

5月です。

4月〜6月はイベントも多かったので感想を書いていたのと、ちょうどNIST SP800-63-3の同期可能クレデンシャルに関する追補版が出た時期でしたね。

色々と読むものが多かった気がします。

6月です。

EICがあったので参加していましたね。来年もいかないと。。。

他にも色々なドキュメントが公開されたので読み込む系のポストが増えてきていますね。

7月です。

折り返し地点です。

そういえばこの時期にDIF Japanのキックオフがあったんですね。他にもDID/VCに関する論文を公開したりもしました。色々と暑い時期でした。

8月です。

パスキーに関する議論が色々とあった時期なので日本語にした公開したりしましたね。パスキー、まだまだ完全に普及した、という状態ではないので引き続き様子は見ていきたいと思います。

この時期はトラスト、とか本人確認や身元確認へのデジタルクレデンシャルの利用について割と真剣に考え始めている時期だったのでそういうニュアンスのポストもしていますね。まだまだ適当な実装が多いこの世の中なので、みんな真剣に考えていけるといいですね。

9月です。

SIDI HubワシントンDC会合もありましたし、ベルリンやケープタウンのレポートが公開された時期でもあったのでSIDI Hub三昧でした。他にもついにパンドラの箱を開けたAuthZEN WGが本格的に活動を始めた時期だったのでAuthorization APIもウォッチし始めた時期ですね。

10月です。

10月末に東京でSIDI Hub Summitを開催したので、その準備でかなり忙しかった時期です。月末〜月初はIIW〜IETFもありましたし。

国際イベントのハンドリングや準備は何度やっても良い経験になりますね。しんどいけど。

11月です。

リンク可能性の話はまだ解けていない課題の中でも議論がつきない話です。IIWでも何年も話題になっていますし、IETFのメーリングリストでも議論が何度も行われています。

12月です。ついに終わります。

台湾政府に呼ばれてWalletの話をしに行ったりもしましたし、今まさに読んでいるAAMVAのガイドラインが11月末に更新されたことを受け、読んでいきました。

ということであっという間に1年が経ってしまいました。

で、来年はどうするの？という話ですが、まぁ習慣化してしまったところなので今後も無理しない程度に書いていこうとは思いますが、適度に休む必要性も同時に感じているので毎日は描かないかなぁ、と思います。クォリティも落ちますしね。

ということでみなさん、良いお年を！

AAMVAのMobile Drivers License Implementation Guidelinesを読む⑧

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

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

まだまだプライバシーの章が続きます。

4.5. DELETING MDL INFORMATION FROM A DEVICE

An mDL holder must have the capability to delete the mDL holder’s mDL from the mDL holder’s device. Such deletion:

1. Must delete all mDL information, log information, and any metadata (e.g. settings) that could impart information about the deleted mDL or its use. 
2. Must not require approval by the Issuing Authority.
3. Must be an option available to an mDL holder on the mDL device
4. Must be possible when the mDL device is offline.
5. Should be available to an mDL holder via a request to the Issuing Authority (see below).

mDL保持者は、mDL保持者のデバイスからmDL保持者のmDLを削除する機能を持たなければならない。

1. すべてのmDL情報、ログ情報、および削除されたmDLまたはその使用に関する情報を与える可能性のあるメタデータ（設定など）を削除すること
2. 発行機関の承認を必要としないこと。
3. mDLデバイス上でmDL保持者が利用可能なオプションであること。
4. mDLデバイスがオフラインのときに可能であること。
5. 発行機関（下記参照）へのリクエストにより、mDL保持者が利用可能であること。

 デバイスからmDL情報を削除する際の話です。基本的に利用者が自身で削除をすることができること（その際に発行者の承認や接続が不要であること）が求められています。難しいところですね。この章の中で発行したmDL関連情報が適切に扱われていること発行機関が責任をもって確認することが求められる一方で利用者の権利も守らないといけないわけです。まぁ、最低限ウォレット開発者が悪意を持って利用者のデータを扱えないように、というところまでは守りましょう、ってところですね。

Should an mDL device (i.e. a device containing an mDL) be lost or get stolen, it could be beneficial for the mDL holder to have the mDL remotely deleted (or temporarily suspended) by the Issuing Authority. Besides the obvious advantage to the mDL holder, other considerations apply too:

1. The mDL holder’s request must be authenticated. It must not be possible for someone other than the mDL holder or the Issuing Authority to delete (or suspend) an mDL.
2. A “push” capability (from the Issuing Authority to the mDL device) is needed for immediate deletion (or suspension) (see section 6).
3. Successful deletion (or suspension) depends on network connectivity to the mDL device
4. The mDL will automatically become unusable (although potentially not inaccessible) when the MSO expires (see section 6). 

mDLデバイス（mDLを含むデバイス）が紛失または盗難に遭った場合、発行機関によってmDLがリモートで削除（または一時的に停止）されることは、mDL保有者にとって有益です。mDL保有者にとっての明らかな利点の他に、他の考慮事項も適用されます：

1. mDL保有者の要求は認証されなければならない。mDL保持者の要求は認証されなければならない。mDL保持者または発行機関以外の者がmDLを削除（または一時停止）することはできない。
2. 即時削除（または一時停止）には、（発行局からmDLデバイスへの）「プッシュ」機能が必要である（セクション6参照）
3. 削除（または一時停止）の成功は、mDLデバイスへのネットワーク接続に依存します。
4. MSOの有効期限が切れると、mDLは自動的に使用できなくなる（アクセスできなくなる可能性はないが）（セクション6参照）。

やはりスマートフォンベースの話なので当然紛失や盗難に関する考慮は十分に必要です。

mDLを利用するときはちゃんと認証するのは当たり前として、発行者から発行済みのクレデンシャルをプッシュ等を使って削除できるようにする、また有効期限切れたらウォレット側で自動的に使えなくする、などもちゃんと気を使う必要があります。

In addition, mDL deletion may be needed when an mDL holder wants to transfer an mDL to a new device, when a person moves to another jurisdiction, or when a person dies. 

Issuing Authorities should weigh the benefits and challenges associated with a remote delete (or suspension) capability when considering its implementation (see Appendix A).

An mDL holder must have the capability to delete activity log information (as defined in section 4.4) the mDL holder may previously have elected to maintain. It is recommended that this capability allows selective deletion (i.e. specific log entries, rather than only an “all or nothing” option).

さらに、mDLの削除は、mDL保持者が新しいデバイスにmDLを移したい場合、別の管轄区域に移動する場合、またはmDL保持者が死亡した場合に必要となる可能性がある。

発行局は、リモート削除（または一時停止）機能の導入を検討する際、その利点と課題を比較検討する必要がある（付録A参照）。

mDL保持者は、mDL保持者が以前に保持することを選択した活動ログ情報（第4.4項に定義）を削除する機能を持たなければならない。この機能により、選択的な削除（すなわち、「全削除」オプションのみではなく、特定のログエントリーの削除）を可能にすることが推奨される。

mDLを含めデジタルデータを持ち主だけが制御できるようにするのは大切な一方で死亡した場合などの考慮は非常に重要です。マイナンバーカードと保険証の統合をした結果、意識のない救急患者の保険者資格の確認ができない、なんて話も聞きますが、この辺りは例外処理も含めてちゃんとプロセス設計をしておくのが大切です。

また、ログの削除に関しても選択的に削除することができるようにすべきである、などかなり細かくガイドされている感じがあります。

4.6. NO TRACKING

“Tracking” is the act of compiling information about an mDL holder and/or an mDL holder’s activity. Any stakeholder (including Issuing Authorities, technology providers, service providers and mDL verifiers) must not track mDL holders or the usage of any mDL except as required by law (e.g. when a drug store dispenses products containing ephedrine). 

「トラッキング」とは、mDL保持者および/またはmDL保持者の活動に関する情報を収集する行為を指します。いかなるステークホルダー（発行局、テクノロジープロバイダー、サービスプロバイダー、mDLベリファイアーを含む）も、法律で義務付けられている場合（ドラッグストアがエフェドリンを含む製品を調剤する場合など）を除き、mDL保持者やmDLの使用状況を追跡してはなりません。

トラッキングの禁止に関する条項ですね。法的根拠なくトラッキングしてはならない、と。 

Tracking by an mDL verifier can be performed as soon as two different mDL transactions can be linked to each other. This can be countered by designing the solution to maximize anonymity (“characteristic of information that does not permit a personally identifiable information principal to be identified directly or indirectly”, from ISO/IEC 29100) and to maximize unlinkability. Anonymity can be hampered by metadata that may be associated with multiple mDL transactions, e.g. hardware or network addresses, long-term public keys, or session tokens. Consequently, Issuing Authorities must minimize the sharing of static or long-lived metadata. 

mDL検証者による追跡は、2つの異なるmDLトランザクションが互いにリンクされるとすぐに実行できる。これは、匿名性（「個人を特定できる情報主体が直接的または間接的に特定されない情報の特性」、ISO/IEC 29100より）を最大化し、リンク不能性を最大化するようにソリューションを設計することで対抗できる。匿名性は、複数のmDLトランザクションに関連するメタデータ（ハードウェアやネットワークアドレス、長期公開鍵、セッショントークンなど）によって妨げられる可能性がある。そのため、発行局は静的または長期的なメタデータの共有を最小限に抑える必要がある。

これはSD-JWT-VCでも同じ議論がなされていますが、Verifierの結託によるリンク可能性の話ですね。mdocにおける選択的開示については基本的にSD-JWTと類似の考え方なので単体ではリンク可能性に対する対応はできなかったはずです。そのため匿名性を担保するソリューションを別途検討することが必要とされています。 

Although pre-matched transactions hold the promise of maximizing anonymity at a user data level, anonymity in post-matched transactions is limited since the portrait image is always shared. For these transactions it is recommended that Issuing Authorities pursue regulatory protection against tracking by mDL verifiers.

事前照合取引は、ユーザー・データ・レベルでの匿名性を最大化することが期待できるが、事 後照合取引では肖像画像が常に共有されるため、匿名性は制限される。このような取引の場合、発行機関はmDL検証者による追跡を防ぐため、規制による保護を追求することが推奨されます。

Solutions using the server retrieval method also pose challenges in preventing tracking. As per design, the Issuing Authority is involved in real time each time an mDL is used by the mDL holder. The Issuing Authority would technically be able to keep track of when an mDL holder uses his/her mDL and keep track of what data is shared. Based on IP address analysis the Issuing Authority would also be able to track an mDL holder’s physical location to some extent. This can be mitigated by placing regulatory limitations on the Issuing Authority11, and will be of value to the extent an mDL holder trusts the Issuing Authority’s adherence to the regulatory limitations. Consequently, Issuing Authorities considering a server retrieval solution should carefully weigh the advantages of this approach against its privacy implications. 

サーバーリトリーバルを使用するソリューションは、追跡を防ぐという課題もある。設計の通り、発行局はmDL保有者がmDLを使用するたびにリアルタイムで関与します。発行局は技術的に、mDL保有者がいつmDLを使用し、どのようなデータが共有されたかを追跡することができます。IPアドレスの分析に基づき、発行局はmDL保持者の物理的な所在地をある程度追跡することもできます。この問題は、発行局に規制上の制限を設けることで緩和することができます11 。そのため、発行局はサーバー検索ソリューションを検討する際、このアプローチの利点とプライバシーへの影響を慎重に比較検討する必要があります。

サーバーリトリーバルは基本的に従来のフェデレーションモデルと同様に発行者への問い合わせが発生するため、トラッキング耐性は低いとされます。この辺りはエコシステムのサイズや参加しているエンティティの関係性などを踏まえて設計していかないといけないポイントですね。 

Since the activity log (see section 4.4) contains a full record of when and potentially where an mDL was used, it is reiterated that access to the activity log must not be possible by anyone other than the mDL holder. 

アクティビティログ（4.4項参照）には、mDLがいつ、どこで使用されたかについての完全な記録が含まれるため、mDL保持者以外の者がアクティビティログにアクセスできないようにする必要があります。

 

今日もこの辺りにしておきましょう。

AAMVAのMobile Drivers License Implementation Guidelinesを読む⑦

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

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

引き続き4章のプライバシーの部分を読んでいきます。

4.3. PROTECTING DATA

It is up to Issuing Authorities to ensure that all mDL data stored on the mDL holder’s device is adequately protected. As standards in this respect are still under development, each Issuing Authority should take great care to ensure that the design of its solution supports this requirement. At minimum, Issuing Authorities must adhere to the following:

発行局は、mDL保持者のデバイスに保存されたすべてのmDLデータが適切に保護されていることを確認する必要があります。この点に関する標準はまだ開発中であるため、各発行局はソリューションの設計がこの要件を確実にサポートするよう、細心の注意を払う必要があります。発行局は、最低限以下の事項を遵守しなければなりません：

 原文でも太字で強調されているとおり、mDL App（ウォレット）に保持されているmDLデータが保護されていることを発行者が確認することが求められています。この責任分解の考え方は非常に重要ですね。欧州でもそうですが発行者となる国が認定したウォレットが必要になるのはこのような背景からきていると思います。しかしこうなるとApple WalletやGoogle Walletに格納されたクレデンシャルが適切に管理されていることをどこまで国は確認できるんだろうか、、、と気になってきますね。

具体的な要件が続きます。

• mDL information must be stored in encrypted form
• Private key material must be protected in a security module designed for the safekeeping of key material.
• The mDL holder must be authenticated when any mDL data is accessed or released, at a point in time that is sufficiently close (as determined by the Issuing Authority) to the time of the access or release. Issuing Authorities that want to leverage device unlocking to protect mDL data must include measures to ensure that this feature has not been disabled by the mDL holder (also see section 7).
• Example: If an app authenticates the mDL holder when the mDL app is accessed, an Issuing Authority should set a time limit after which authentication of the mDL holder is again required before the release of mDL data. 
• mDL data must be released to an mDL verifier only via the following:
• an ISO/IEC 18013-5 compliant interface.
• an ISO/IEC 18013-7 compliant interface.
• As an alternative to ISO/IEC 18013-7, an over-the-Internet interface as envisioned in Appendix C that:
• Complies with Appendix C items 2.b and 2.f, and 
• Has been approved by the AAMVA Identity Management Committee.
• For sharing mDL data between apps on a phone via an interface other than those listed above, an interface compliant with Appendix C items 2.b and 2.f and that has been approved by the AAMVA Identity Management Committee 
• mDL情報は暗号化された形で保存されなければならない。
• 秘密鍵は、鍵の保管のために設計されたセキュリティ・モジュールで保護されなければならない。
• mDL データがアクセスまたは公開される際には、アクセスまたは公開の時点に（発行局が決定する）十分 に近い時点で、mDL 所持者が認証されなければならない。デバイスのロック解除を活用してmDLデータを保護したい発行局は、この機能がmDL保持者によって無効化されていないことを保証する手段を含める必要があります（セクション7も参照）。
• 例 アプリがmDLアプリにアクセスしたときにmDLの所有者を認証する場合、発行局は、mDLデータの公開前にmDLの所有者の認証が再度必要となる制限時間を設定する必要があります。
• mDLデータは、以下を経由してのみmDL検証者に公開されなければならない：
• ISO/IEC 18013-5に準拠したインターフェース。
• ISO/IEC 18013-7準拠のインターフェース。
• ISO/IEC 18013-7 に代わるものとして、付録 C で想定されているインターネット上のインター フェース：
• 付録Cの項目2.bおよび2.fに準拠し、かつ
• AAMVA アイデンティティ管理委員会によって承認されている。
• 上記以外のインタフェースを介して携帯電話のアプリ間で mDL データを共有する場合は、付 録 C 項目 2.b および 2.f に準拠し、AAMVA アイデンティティ管理委員会によって承 認されたインタフェース。

かなり細かく要件が決まってますね。EUでも鍵をどこに置くかは色々と議論がありましたが、AAMVAではセキュリティ・モジュールになってますね。クラウドベースのHSMとかは選択肢に入らないのかな？あと、Holderのプレゼンスや認証のタイミング、ウォレットのアンロックが無効化されていないことの確認など色々とガイドがありますがどうやって確認するんだ？？って気もしますが。こうなってきるとやはり専用ウォレットみたいな話になってきそうですねぇ。。

Note 1: This requirement prohibits the sharing of mDL data using the mDL as a “flash pass” (i.e. by showing an image of a credential to a verifier); also see section 8.

注 1：この要件は、mDL を「フラッシュ・パス」（すなわち、検証者にクレデンシャルの画像を見せること）として使用して mDLデータを共有することを禁止している。

これも重要ですね。以前紹介したパートにも書いてありましたが基本的にmDLは目視で確認するためのものではない、ということですね。

4.4. ACTIVITY LOG

The mDL app must be capable of maintaining an activity log. The mDL app must allow the mDL holder to decide if an activity log must be maintained or not. It is recommended that the mDL app requires the mDL holder to explicitly choose for or against keeping an activity log upon setup (i.e. no defaults, and in addition to being able to change this subsequently). The activity log and related settings must be accessible only to the mDL holder (also see section 4.6). The activity log must allow for the recording of all mDL transactions. In this context, an mDL transaction is the sharing of information by an mDL holder with an mDL verifier, as well as any provisioning, update, or communication action between the mDL and the Issuing Authority. At minimum, the following must be recordable for any transaction: Transaction timestamp; type of transaction (e.g. update or data sharing); in case of a data sharing transaction the data that was shared, and to the extent that it can be gathered, information about the identity of the mDL verifier. It is recommended that the mDL app provides the mDL holder the capability to select what types of activities are recorded in the activity log (i.e. rather than only an “all or nothing” option). It is also recommended that the mDL app includes functionality to help the mDL holder monitor and manage the size of the activity log within the capabilities of the mDL holder’s device. The mDL app must provide an option to the mDL holder to export the activity log.

mDLアプリは、アクティビティログを維持できなければならない。mDLアプリは、アクティビティログを保持するかどうかをmDL保持者が決定できなければならない。mDLアプリは、セットアップ時に、mDL保有者がアクティビティログの保持の可否を明示的に選択することを推奨します（すなわち、デフォルトではなく、さらにその後変更できるようにします）。アクティビティログおよび関連する設定は、mDL保持者のみがアクセス可能でなければなりません（4.6項も参照）。アクティビティログは、すべてのmDLトランザクションの記録を可能にしなければならない。ここでいう mDL トランザクションとは、mDL 保持者が mDL 検証者と情報を共有すること、および mDL と発行局との間でプロビジョニング、更新、または通信を行うことである。どのようなトランザクションでも、最低限、以下の情報は記録可能でなければならない： トランザクションのタイムスタンプ、トランザクションのタイプ（更新またはデータ共有など）、データ 共有トランザクションの場合は共有されたデータ、および収集可能な範囲で mDL 検証者の身元に関する情報。mDLアプリは、活動ログに記録される活動の種類を選択する機能をmDL保持者に提供することが推奨される（すなわち、「all or nothing」オプションのみではなく）。また、mDLアプリには、mDL保持者がmDL保持者のデバイスの能力の範囲内でアクティビティログのサイズを監視および管理するのに役立つ機能が含まれることが推奨されます。mDLアプリは、mDL保持者がアクティビティログをエクスポートできるオプションを提供する必要があります。

次はログの話題です。アクティビティログはプライバシーの観点からも非常に重要なものですので、Holderが完全に制御できるものである必要があることが強調されています。この辺りもウォレットソフトウェアを開発する際は留意したいポイントですね。

If an Issuing Authority allows an mDL holder to hold the same mDL on more than one device, the activity log settings on each device should be independent of each other. It is recommended that there be no synchronization of the activity log or activity log settings between the two devices. Any synchronization features that are provided must adhere to the following:

1. Synchronization must be an option that can be enabled or disabled by the mDL holder. The process to enable synchronization must require the mDL holder to prove access to both devices. 
2. Synchronization must occur directly between the devices in question. A synchronization action must not give visibility of any of the following to anyone other than the mDL holder, or to anyone other than entities that already know that the mDL holder has an mDL on more than one device:

• Activity log information.
• Activity log settings.
• The fact that a synchronization action/selection took place
• Any information that may convey that the mDL holder has an mDL on more than one device. 

発行局がmDL保持者に複数のデバイスで同じmDLを保持することを許可する場合、各デバイスのアクティビティログ設定は互いに独立しているべきである。2つのデバイス間でアクティビティログまたはアクティビティログ設定の同期は行わないことが推奨される。提供される同期機能は、以下に従わなければならない：

1. 同期は、mDL保持者が有効または無効にできるオプションでなければならない。同期を有効にするプロセスでは、mDL保持者が両方のデバイスへのアクセスを証明する必要があること。
2. 同期化は、当該デバイス間で直接行われなければならない。同期化アクションは、mDL保持者以外、またはmDL保持者が複数のデバイスにmDLを持つことを既に知っているエンティティ以外の者に、以下のいずれかを可視化してはならない：

• アクティビティログ情報。
• アクティビティログの設定。
• 同期アクション/選択が行われた事実。
• mDL保持者が複数のデバイスでmDLを使用していることを伝える可能性のあるあらゆる情報。

 複数デバイスをHolderが使っている場合のログの同期の話です。これもせっかくコンテキストによってデバイスを分けているにも関わらずログが同期されてしまうとコンテキスト違反が起きてしまうことになるのでちゃんと分けましょう、という話ですね。

今日はこのあたりで。

 

 

 

 

 

 

 

 

AAMVAのMobile Drivers License Implementation Guidelinesを読む⑥

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

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

ようやく4章の「PRIVACY AND SECURITY」に入ります。4章も結構長いんですよね。。。ただ、結構重要な章なので細かくみていきたいと思います。

4.1. INTRODUCTION

The privacy of an mDL holder has been paramount in the mDL design process from the start. Care was and is being taken in all the work to ensure that methods and means are available to protect mDL holder privacy. The subsections that follow elaborate in more detail on different aspects of privacy protection and security.

mDLの設計プロセスでは、当初からmDL保持者のプライバシーが最優先されてきました。すべての作業において、mDL保持者のプライバシーを保護する方法と手段が利用できるよう、細心の注意が払われています。以下のサブセクションでは、プライバシー保護とセキュリティのさまざまな側面について詳しく説明します。

4.2. DATA MINIMIZATION AND SELECTIVE DATA RELEASE

A primary component of privacy involves the ability of an mDL holder to only share some information. This is achieved by two related but distinct measures:

1. Data minimization: A decision by an Issuing Authority to record fractional information about an attribute in an mDL, thus empowering an mDL holder to share less information than would otherwise have been the case. For example, an Issuing Authority can decide to include9 the optional age_birth_year field in an mDL in addition to the (mandatory) date of birth. This will allow the mDL holder to share only a birth year as opposed to a date of birth. Another example would be to include the resident city in addition to a full address. 
2. Selective data release: Allowing an mDL holder to decide which of the data fields requested by an mDL verifier will be released to the Verifier.

As noted in section 2, it is important for Issuing Authorities to understand that ISO/IEC 18013-5 primarily specifies interfaces. The interfaces support both data minimization and selective data release. It is recommended that Issuing Authorities implement and provision as many of the optional minimized data elements, defined in ISO/IEC 18013-5 and in this document, as possible.

プライバシーの主要な構成要素は、mDL保持者が一部の情報のみを共有する能力である。これは、2つの関連するが異なる手段によって達成される：

1. データの最小化：データの最小化：発行局が、mDLに属性情報の一部を記録することを決定すること。例えば、発行局はmDLに、（必須である）生年月日に加え、オプションのage_birth_yearフィールドを含める9 ことができます。これにより、mDLの所持者は、生年月日ではなく、生年のみを共有することができます。他の例としては、完全な住所に加えて、居住地の市町村を含めることができる。
2. 選択的データ公開：mDL保有者が、mDLベリファイアから要求されたデータフィールドのうち、どのフィールドをベリファイアに開示するかを決定できるようにすること。

セクション2で述べたように、発行局はISO/IEC 18013-5が主にインタフェースを規定していることを理解することが重要である。インターフェースはデータの最小化と選択的なデータ公開の両方をサポートする。発行局は、ISO/IEC 18013-5 および本文書で定義されているオプションの最小化データエレメントを可能な限り実装し、提供することが推奨される。

Privacy by designということです。ISO/IEC 18013-5ではデータの最小化と選択的情報開示の両方をサポートしているので、本書の原則を踏まえてちゃんと実装しなさいよ、と。

 

In addition, Issuing Authorities must ensure that mDL apps to which they provision data support at least the following: 

• In case the request was received electronically, the mDL app must clearly convey what data was requested, and whether the mDL verifier intends to retain the information. If the request is presented in summarized form in the user interface (e.g. “Identity and driving privilege data” as opposed to “First Name, Last Name, DOB, Driving privileges”), means must be available to give the mDL holder visibility of the details of such a summarized form, both before and during a transaction.
• The mDL app must provide the mDL holder full control over which data elements to share with the mDL verifier. 
• ISO/IEC 18013-5 requires the portrait image to be shared if the portrait was requested and if any other data element is released (to enable the mDL verifier to tie the mDL information to the person presenting the information). The app must support a graceful and informed exit from the request if the holder opts not to share the portrait image when requested.
• If blanket sharing options are used, measures must be implemented to ensure that the mDL holder remains aware of what is being released when such an option is in effect. An mDL holder must also be able to opt out of or cancel any blanket sharing function.

Issuing Authorities (and their app providers) are encouraged to devise solutions that will minimize transaction friction without compromising the above requirements.

さらに、発行局はデータを提供するmDLアプリが少なくとも以下をサポートしていることを確認する必要があります：

• 要求が電子的に受信された場合、mDLアプリは、どのようなデータが要求されたのか、またmDLベリファイアがその情報を保持する意図があるかどうかを明確に伝えなければならない。要求がユーザーインターフェースに要約された形で提示される場合（例えば、「姓名、DOB、運転権限」ではなく「身分証明書および運転権限データ」）、取引の前および取引中の両方において、mDL保有者がそのような要約された形の詳細を可視化できる手段を利用できなければなりません。
• mDLアプリは、どのデータ要素をmDLベリファイアと共有するかについて、mDL保持者に完全なコントロールを提供しなければならない。
• ISO/IEC 18013-5では、肖像画が要求された場合、およびその他のデータ要素が公開された場合、肖像画を共有することが要求されています（mDLベリファイアがmDL情報を提示者に紐付けることを可能にするため）。アプリは、所持者が要求されたときに肖像画を共有しないことを選択した場合、その要求から 潔く、かつ通知された形で抜けることをサポートしなければならない。
• 包括的共有オプションが使用される場合、そのようなオプションが有効であるとき に、mDL保有者が何が公表されるかを確実に認識し続けるための措置が講じられなけれ ばならない。また、mDLの保有者は、包括的共有機能をオプトアウトまたはキャンセルできなければならない。

発行局（およびそのアプリプロバイダ）は、上記の要件を損なうことなく、取引の摩擦を最小化するソリューショ ンを考案することが推奨される。 

データを要求・共有する目的・意図を明確に伝える、そして提供しないことをユーザが選択できるようにする、オプトアウトできるようにもする、と。どれも基本的なことではありますが実装者にとってはどのようなUXを提供するかが腕の見せ所になると重要なポイントの一つでもあります。この辺りは日本でもウォレット開発をする方々も参考にすべき点だと思います。

細かくみていこうと思うので少し細切れにしていきます。

ということで今日はここまで。

 

 

 

 

AAMVAのMobile Drivers License Implementation Guidelinesを読む⑤

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

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

まだ３章が続きますが今回で３章は終わりです。

3.6. IACA ROOT CERTIFICATE

In Table B.1 of ISO/IEC 18013-5, on the table row for the “ISSUER” certificate component, replace:

stateOrProvinceName is optional. If this element is present, the element shall also be present in the end-entity certificates and hold the same value. 

with the following:

stateOrProvinceName is mandatory. The element shall also be present in the end-entity certificates and hold the same value.  

ISO/IEC 18013-5 の Table B.1 の 「ISSUER 」証明書コンポーネントの表行で、以下を置き換える：

stateOrProvinceName はオプションである。この要素が存在する場合、この要素はエンドエンティティ証明書にも存在し、同じ値を保持するものとする。

を以下のように置き換える：

stateOrProvinceName は必須である。この要素は、エンド・エンティ ティティの証明書にも存在し、同じ値を保持するものとする。

やはりモバイル運転免許証にISO/IEC 18013-5を当てはめるとき、ちょいちょい書き換えするところがありますね。

3.7. VERSIONING

The data structure for the 2D barcode in the AAMVA Card Design Specification contains a version number. This enables readers to always know which version of the data structure is present on a credential since the full data string is always read. This is not true for an mDL. An mDL reader has to explicitly request individual data elements, and does not know in advance which data elements are present or what version of a data set is supported.

AAMVA カード設計仕様の 2D バーコードのデータ構造には、バージョン番号が含まれている。これにより、完全なデータ文字列が常に読み取られるため、読み手はデータ構造のどのバージョンがクレデンシャルに存在するかを常に知ることができる。これは mDL には当てはまらない。mDL リーダは個々のデータ要素を明示的に要求する必要があり、どのデータ要素が存在する か、またはデータ・セットのどのバージョンがサポートされているかを事前に知ることはできない。

One approach to address this is to add a “version” data element to the AAMVA namespace. To be useful an mDL reader would have to obtain this data element before making a subsequent request for additional data. Allowing the release of this data element without mDL holder approval is possible; requiring approval may confuse an mDL holder and increase transaction friction. Regardless, the 2-step process would add complexity (an mDL reader would still have to allow for not receiving a response to such a request) and add time to the transaction. Such an approach would also be unique to mDL in North America.

これに対処する1つの方法は、AAMVA名前空間に「バージョン」データ要素を追加することである。mDLの読者は、追加データを要求する前にこのデータ要素を取得しなければならない。mDL保持者の承認なしにこのデータ要素の公開を許可することは可能です。承認を必要とすると、mDL保持者を混乱させ、取引の摩擦を増大させる可能性があります。いずれにせよ、2段階のプロセスは複雑さを増し（mDLリーダーは、そのような要求に対する返答を受け取らないことを許容しなければならない）、取引に時間を要する。また、このようなアプローチは北米のmDLに特有のものである。

Instead, versioning of the AAMVA mDL data element set is achieved as follows:

1. If needed, create a new identifier. This applies if there is a change to an existing data element, or if a completely new data element is added. Set a date by which mDL apps and mDL readers must support the new identifier (Dayx in Figure 2). “Support” as used here means that an mDL app must allow an Issuing Authority to provision the identifier into the app, and that an mDL reader must be able to read the new identifier. 
2. For the old identifier, set a date by which mDL apps and mDL readers do not need to support the old identifier anymore (Dayy in Figure 2). This is also the date by which Issuing Authorities must be provisioning the new identifier.

代わりに、AAMVA mDLデータ要素セットのバージョニングは、以下のように行われる：

1. 必要に応じて、新しい識別子を作成する。これは、既存のデータ要素に変更がある場合、またはまったく新しいデータ要素が追加される場合に適用されます。mDLアプリとmDLリーダーが新しい識別子をサポートしなければならない期日を設定します（図2のDay x）。ここでいう「サポート」とは、mDLアプリが発行機関に識別子をアプリにプロビジョニングできるようにすること、およびmDLリーダーが新しい識別子を読み取れるようにすることを意味します。
2. 旧識別子については、mDLアプリとmDLリーダーが旧識別子をサポートする必要がなくなる日付を設定します（図2のDay y）。これは、発行局が新しい識別子をプロビジョニングする期日でもあります。 

Figure 2 also reflects other requirements on both the mDL reader and the mDL app. The main advantage of the approach illustrated in Figure 2 is that, in case of changing an existing identifier, the Issuing Authority will have the time between the two dates to provision the new identifier (and deprecate the old identifier) to all its mDLs with the knowledge that mDL readers should be able to accommodate either identifier (the highlighted option in Figure 2). In the case where a new identifier is added (i.e. when there is no change to an existing identifier), the two dates may be on the same day.

図2には、mDLリーダーとmDLアプリの両方に対するその他の要件も反映されています。図2に示されたアプローチの主な利点は、既存の識別子を変更する場合、発行局は2つの日付の間に、mDLリーダーがどちらの識別子にも対応できることを前提に、すべてのmDLに新しい識別子を提供する（古い識別子を廃止する）時間を持つことができることです（図2のハイライトされたオプション）。新しい識別子が追加される場合（既存の識別子に変更がない場合）、2つの日付は同じ日になる可能性があります。

Ideally mDL readers would ask for the old identifier up to Dayy and for the new identifier thereafter. However, it is likely that readers would, at least around the change date, ask for both. It is also likely that an mDL would, especially around Dayy, include both identifiers. How the request is presented to the mDL holder, and how approval to share is administered, is left to implementers. Nevertheless, a simple approach could be for the mDL to present only one request, for the new identifier, to the mDL holder.

理想的には、mDLの読者はDay yまでは旧識別子を、それ以降は新識別子を要求するだろう。しかし、少なくとも変更日前後には、読者は両方の識別子を要求すると思われる。また、mDLは、特にDayyの前後には、両方の識別子を含むと思われる。どのようにリクエストをmDL保持者に提示し、どのように共有の承認を行うかは、実装者に委ねられている。とはいえ、単純なアプローチとしては、mDLがmDL保持者に提示する要求は、新しい識別子のための1つのみである。

バージョニングに関するコンセプトがちゃんとしていますね。リードタイムをうまく作ってスムーズに移行できる様にすることができる様にしています。

3.8. ISSUING AUTHORITY SPECIFIC DATA

ISO/IEC 18013-5 allows for the creation of additional namespaces, in like manner as the AAMVA namespace defined in this document (see clause 7.2.8 in ISO/IEC 18013-5). Issuing Authorities can use this mechanism to add additional fields to an mDL. The Issuing Authority would be responsible for communicating such an additional namespace to mDL verifiers that need to be able to read the Issuing Authority-specific data.

Note: ISO/IEC 18013-5 also lends itself to being adopted for the issuing of credentials separate from an mDL, for example fishing licenses, health credentials, or watercraft licenses. 

ISO/IEC 18013-5では、本文書で定義されているAAMVA名前空間と同様に、追加の名前空間を 作成することができる（ISO/IEC 18013-5の7.2.8項参照）。発行局はこのメカニズムを使用して、mDLにフィールドを追加できる。発行局は、発行局固有のデータを読み取る必要のあるmDL検証者に、このような追加名前空間を伝達する責任を負う。

注：ISO/IEC 18013-5 は、漁業免許証、健康証明書、水上バイク免許証など、mDL とは別のクレデンシャルの発行にも採用できる。

今回はここまでです。次は４章です。