2021-05-18 xID打ち合わせ
アプリ利用者のパターン
Section titled “アプリ利用者のパターン”PHR連携する場合
Section titled “PHR連携する場合”- xID
- QRコード
PHR連携しない場合
Section titled “PHR連携しない場合”- xID一択（窓口に行かない場合xIDでしか遠隔でレベル２を担保できない）
PHR連携しない場合の導線
Section titled “PHR連携しない場合の導線”- QRコードが初回表示されると導線としてわかりづらい
- QRコードをお持ちでない場合はこちらのようなリンクからxID認証ボタンを用意
- 役所に行ってQRコードを持ってきてくれと言う説明とそのメリットの説明を設けるイメージ
代理人が窓口に来た場合
Section titled “代理人が窓口に来た場合”- 画面上に「xIDオンリーフラグ」を設けてQRコードのJWTペイロード部に含めて印刷する
- xIDを使わない人は結局窓口に来る必要があるので、身元確認フラグを更新するのではなく、窓口来庁時にxIDオンリーフラグを外したQRを印刷する運用
代理人にxIDオンリーが付いていないQRコードを渡すケース
Section titled “代理人にxIDオンリーが付いていないQRコードを渡すケース”- 窓口での確実な確認ができれば練馬区の判断で渡しても良い
- あくまでもガイドラインなので法的拘束力は無く現場に裁量はある
- 代理人の場合は渡す、渡さない、シンプルに運用は整理しておいた方がよいのでどちらかに決めるのが望ましい
JWT技術仕様
Section titled “JWT技術仕様”- OIDCに則るならJWTの発行時刻（iat）、IDトークンの有効期限（exp）は合っても良い
- OAuthに則るならクレームはある程度定義されているが、別に何入れてもい
JWTの署名検証
Section titled “JWTの署名検証”- 署名パート(VERIFY SIGNATURE)をアプリ側で検証する
- HEADERに直接公開鍵情報を入れるか、公開リポジトリのURLを入れるか
- 受け取ったアプリ側で公開鍵を使って署名検証
JWTに入れる公開鍵のキーローテーション
Section titled “JWTに入れる公開鍵のキーローテーション”- 非対称鍵は通常一定期間でキーローテションするが、古い鍵で署名されたものを無効化することになってしまう
- 今回はトークンがＱＲコードと時間軸的に長く使う性質のもんなのでキーローテが単純化できない
JWTを端末に保持する場合
Section titled “JWTを端末に保持する場合”- 端末のプロテクション領域に保持されるので機種変更時に鍵を持ち出すことはできない
- 再QRコード発行が必要になる
- FIDO認証で実現する場合、端末ごとの初回登録時にFIDOを有効化する手前の認証はあり、初回はQR＋メールで認証完了したらFIDO有効化し、二台目以降はEmail、パスワードで認証取れたらFIDO発行する流れは考えられる
- ただしそれだとレベル１になろ。そこに物件が必要になる
紛失時の仕組み
Section titled “紛失時の仕組み”- 中央集権的にブラックリスティングする方法として、OCSPレスポンダにシリアルを問い合わせてリボークする方法もある
- PAYLOADにランダムなUUIDをJWT発行ごとに管理することで個別にリボーキングできる
第三者権限付与
Section titled “第三者権限付与”- 両親やパートナーに権限付与するだけなのでxIDは必須
- xID使えない場合は窓口での本人確認が必要になる
- 利用者のアプリ内にQRコードを表示する。中身は「利用者アカウントID、付与する相手の生年月日（画面で入力）」
その他（署名検証の話）
Section titled “その他（署名検証の話）”公開鍵をJWTのヘッダーに入れるかどうか、というのは、単に検証用の公開鍵までJWTに含めておくか、公開鍵番号みたいなもののみをJWTに入れて、その番号に対応する公開鍵を別で参照する（これがJWS）か、という話です。ただし、秘密鍵・公開鍵のペアをQRコード毎に変えるのであれば、JWTに含めるほうが良いかもしれません。
署名用の鍵をAES（共通鍵方式）にすると、署名検証にも同じ鍵が必要になるのですが、署名の発行も検証も同じサーバーで行うのであれば、わざわざ鍵をQR等にふくめて外部に出す必要がないので、こういうやり方もありますね、という話でした。一般的に、非対称鍵（RSA等）よりも、共通鍵（AES）による実装のほうが、実装が簡単でシンプルになるので、AESで十分ならばそれでも良いかもしれません。
- 第三者権限付与、紛失時のフロー
次回以降の検討事項
Section titled “次回以降の検討事項”- テーブル定義の検討