IIW 39 Day3クィックレビュー

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

いよいよIIWも最終日です。

かなり疲れてきたので頭が回らず英語が聞き取れなくなってきました。（来週いっぱいまで英語生活なので週末はゆっくりしないと・・・）

ということで今日も楽しい話題がいっぱいでした。

Credential Status Comparison Mechanisms - Paul

以前も書いたStatusList周りを含むクレデンシャルの取り消しに関する話題です。

確かに色々な方法があるんですよねぇ。古き良きOCSPとか。。。

そもそもクレデンシャルの取り消しをしたくなるトリガーとしては、こんなことが挙げられます。

• Credentialデータセットが無効（例えばover18になった）
• 発行システムの侵害
• アルゴリズムの危殆化（量子コンピューターの発展など）
• ウォレットや鍵の侵害

ドイツ政府はイタリアやフランスと協力してシナリオと方法論の比較検討を進めているみたいです。考えているシナリオはこんなところだそうです。

• ユーザが死んだ
• ユーザが自らRevokeしたい（スマホなくした）
• キーストレージが脆弱性にさらされた

この辺りをスケーラビリティとプライバシー（Linkability）を考えつつ解くのは難しい問題ですよねぇ。。

こんなクライテリアで比較しているそうです。

• Credential format（対応している種類）
• Technology readiness level（成熟度）
• Status tracking by verifier（トラッキング）
• Holder tracking by issuer（トラッキング）
• Unlinkability（紐付け可能度合い）
• Complexity(0が高い）
• Scalability(0が高い）
• Offline/caching（オフラインシナリオへの対応）

色々と考慮点はあって、例えばBitStringでStatusListを作るとある程度サイズ圧縮は効くもののの上限はあるので、一定期間でガベージコレクションをしたり、クレデンシャルのバッチ発行をすることでリンク可能性に対策できるかどうか考えたり、、と。

しかし、こう言う比較検討の段階でIIWのようなプロフェッショナルが集う場所へ投げ込んでブラッシュアップするって方法、本当にいいと思うんですよね。プレゼンする方も「こう思うんだけどどう？」って投げかけてちゃんとその場で議論になる。これを政府や金融機関の中の人たちがちゃんとオープンな場でやっている、ってなかなか日本では考えられないことだと思います。日本政府もこう言う場に来ればいいのに（チラッ）

Digital Credentials API - Tim

次はDigital Credentials APIの話です。

カスタムURLスキームでウォレットが起動されるのではなくFIDOと同じようにCredentials APIで起動できるようにしましょう、って話です。

そもそもカスタムURLスキームで何が問題だったか、というと

• 安全ではないコンテキストでアプリを起動
• デバイス上でのフィッシング（悪意のあるアプリを選択）
• リクエスターオリジン、アイデンティティがない

ということなので、この辺りはパスキーから学ぼうよ、という話です。この辺りが学びとしてあげられていました。

• 呼び出し元のコンテキストがキーとなっている
• クロスデバイス認証はセキュア・簡単・フィッシング耐性があることが必要

こんな構造です。

FIDOにおけるCTAPとWebAuthnとよく似てますね。

こんな感じで動くようです。

APIも割とシンプルです。

Presentation

let digiCred = await navigator.credentials.get({

signal: controller.signal,

digital: {

requests: [{

protocol: "openid4vp",

data: "{request json}"

}]

}

});

Issuance

let digiCred = await navigator.credentials.create({

signal: controller.signal,

digital: {

requests: [{

protocol: "openid4vci",

data: "{request json}"

}]

}

});

この辺りでdemoが見れますよ。

https://digital-credentials.dev/

OID4VCI Browser API Issuance Profiles - Joseph, Kristina, Paul

色々なシナリオを網羅的に考えていかないと社会基盤としては使えないということでかなり色々なユースケースを考えていますね。

https://bmi.usercontent.opencode.de/eudi-wallet/eidas-2.0-architekturkonzept/flows/Presentation-During-Issuance/

こちらにあるようなPresentationの結果を受けてIssuanceを行う、というシナリオもその一つです。

例として、学校でDegreeを発行してもらう際にmDLを提示して本人確認をする、みたいなシナリオが挙げられていました。

Presentationの結果を受けてPre-authorization用のコードを発行〜そのままOID4VCIを走らせるってことですね。

これもプレゼンテーションを行うクレデンシャルが入っていたWalletとIssuanceを行う先のWalletが異なるケースにどうやって対応するのか？みたいな話で議論が盛り上がりました。

OIDC4VCI Credential Versions / Purpose on presentation - Oliver, Daniel

こちらが最後のセッションでしたが、またマニアックな話題でした。

前半パートはOliverがクレデンシャルにバージョンをつけるとするとどうなるのか？という話をしていました。（何をもってそのバージョンが最新であるか、を証明することも含め）

まぁ、バージョンと言っても色々な解釈があるのでその辺りの整理をして議論をするところまで、となりましたが。

1. 同じクレームとバリューを含んでいるが、別デバイスの鍵とバインドされていたり、別で発行された
2. クレームは一緒でも値が異なる。値が変わった場合、Frequent Flyer Statusが変わった場合など
3. クレームは一緒でも値が異なる場合。なぜなら別の人やものに関するもの
4. クレームも値も異なる。全然別のクレデンシャルなので

誰がトリガーで発行し直すのか、Shared Signalで通知するのが良いのか、、などなど。。

後半はDanielがPresentation requestの中のクエリ言語（PEやDCQL）に指定するpurposeについての話題。（これもコアだな）

現状はクレデンシャルの単位でpurposeを指定するので、クレデンシャルセット全体に関するpurposeってないよね、とか多言語対応させるにはどうするべきなのか？みたいな話題で盛り上がりました。こちらも時間切れ。

ということであっという間の3日間でした。

とりあえず次はIETFということでこれからドイツ経由のダブリンへ移動します。。。