# DIW 欧州連合は、mDLのみを分かっているベンダーをRefernce Wallet Implementationとして選んでしまったため、mDL以外のパーツのImplementationに非常に苦労しています。日本は、もう少しバランスの取れたベンダーを採用すべき。というナラティブを入れられれば良いのでは。 FAQ #7 - 「Apple Wallet、Google Walletでも実証を行うこと」 - Apple/Googleの協力がないと不可能です。欧州のEUDIW ARFの目的の一つは市民IDのコントロールをApple/GoogleからEUに戻すことです。Trusted WebなどApple/Googleへの依存をなくすことに日本政府も目を向けていたと思いますが、これでは元も子もないのでは。（このまま林さんに送ってしまいました…） page 4 - 「欧州：EUDI WalletのPilot Projectを推進中であり、各国デジタルIDとの連携や運転免許・パスポート等のユースケースにおいて実用化を検討している」 - パスポートはEUDIWの範囲外です。パスポートはICAOで定められているので、正直、手を出しずらいです。 - ここ（ICAO Passports）、パナソニック・コネクトの強みです。 - 「国際標準に則ったDigital Identity Walletのデータフロー等の実装、技術的検証」 - 18013-7, 23220-*は、まだ国際規格ではない（p9を観るとちゃんとdraftと書いてありました） - 18013-5はInternational Standardですが、18013-7と23220-4はTechnical Standardトラックなので、厳密に言うと重みが違います。 - p8 - 「Google WalletまたはGoogleオープンソースのwalletで、mDLを近接通信でverify・属性開示できること」 - Googleがオープンソースにしているのは、APIで、Walletはそのままでは使えない、あくまでReference Implementationです。https://android-developers.googleblog.com/2020/11/privacy-preserving-features-in-mobile.html - アメリカでは、Googleが提供しているAPIを使わないベンダーも多いので、ここは、ベンダー任せでもよいのでは - 要件は、あくまでiOS/Androidで機能するWalletであること。 - 「iOS APIを利用したWalletアプリ」 - iOS APIとはなんでしょう？存在しない認識です。Appleは自分でApple　Walletに発行することにしか興味がないので。 - 「異なるnamespace」 - ISOで定められているクレームではどうして物足りなくて、日本独自のnamespaceが必要なクレームの特定・定義が必要。 p9 - VC Data Modelはそのままでは選択的開示をサポートしていないので、どのように選択的開示を