初めに

こんにちは、グローバル開発グループでID Platformを開発しているリョウです。2024/01/19に渋谷ストリームホールでOpenID Summitに参加しましたので、感想と自分が見つけた面白かったポイントを共有する為に本記事を執筆いたします。
コロナ禍でOpenID Summit Tokyo 2020から４年ぶりに開催されたので、当日はOpenIDに興味ある方々が大勢会場に集まり、非常に盛り上がっていました。
今回のトピックとしては、コロナを挟んだ４年間でデジタルIDがどんな変化をもたらしたか、そして将来的にデジタルアイデンティティが世の中でどんな発展を遂げそうか、といった内容でした。

プログラムの流れ

参加感想

OpenIDといえば、他の汎用性の高い技術領域と比べて知名度はあまりなく、聞いたことも無い方々が沢山いらっしゃると思いますが、今回のサミット会場に着いた際、多くの企業からOpenIDに関心のある方が集まっていたので、若干驚きました。
今回初めて参加する方もいるので、午前中は今までOpenIDが発展してきた歴史、OpenIDのデジタルアイデンティティと電子マネー面における今後の発展や展望、OpenIDファウンデーション・ジャパンワーキンググループにて行われている資料の翻訳や人材育成活動の詳細を中心にご紹介いただきました。
午前中発表された内容から、今後のOpenIDが発展していく方向は認証認可領域から身分証明(デジタルアイデンティティ)と電子マネー運用への変化だと深く感じました。

午後のTopicはOpenIDを実際導入運用の段階遭った問題や全体的なソリューション・対策に関して各会社から説明をいただきました。
ただ、午後のプログラムは２会場での開催だったため、NARUTOのような多重分身術を持たない私は、同時に２会場に参加出来なく非常に残念です。

印象深い発表

OpenID Connect活用時のなりすまし攻撃対策の検討

発表者：湯浅 潤樹 — 奈良先端科学技術大学 サイバーレジリエンス構成学研究室
紹介いただいた事例はなかなかレアですが、修士課程２年でOpenIDの運用実験をここまで深掘りされていることに驚きました。OpenIDの認証モードはいくつかありますが、使用例によっては安全性が低い場合もありますので、この発表のような特定ケースでリスクがある部分を今後の展開で注意しながら進めていくべきだと思いました。

メルカリアプリのアクセストークン

発表者：グエン・ザー — 株式会社メルカリ IDプラットフォームチーム ソフトウェアエンジニア
メルカリアプリは日本で非常に人気のある中古品販売プラットフォームとして有名です。そのIDプラットフォームエンジニアの方が、メルカリIDの運用上、古い手法でどんな困難があったのか、そしてユーザーがモバイルアプリやブラウザ上でスムーズにサービスを利用できるようになるまでの努力について説明いただきました。その中でも、ブラウザCookieの活用において多くの目標を達成してきたけれど、Chromeブラウザだけは特別な仕様で、Cookie有効期間が400日であることを知りました。我々もIDプラットフォームを立ち上げてからUI・UXに関しては様々なチャレンジや努力をしてきましたが、Cookie有効期間は400日といったことは初めて知りました。

JWTについて

JWT(JSON Web Token)という名前はよく耳にするかと思いますが、認証・認可にあまり触れあわない方だとJWTの役割や、よく同時に出るJWK, JWS, JWE間の相互関係について触れる機会が無いかもしれないので、あらかじめ簡単に説明しましょう：

1. JWTはネットワーク上で情報交換する際に、交換情報の信頼度を確保出来る規範となります。そのうち、JWSとJWEはJWTの規範の実現例となります。
2. JWS(JSON Web Signature)は下記図のように「.」に区切られて３つのパートとなります：Header(認証方法記載),Payload(実際の情報),Signature(改竄されない保証)。
   
   JWSをbase64でエンコードされましたので、デコード出来たPayloadはすべての情報が開示されてます。
3. JWK(Json Web Key)は、JWTの説明と合わせてすると、JWTのHeaderに記載して方法でPayloadの内容のハッシュを暗号化してSignatureを生成する暗号化鍵となります。
4. JWE(JSON Web Encryption)は上記のJWSとクレべて、安全性と完全性を当時に守れるJWTの実現となります。そのため「.」で５つパートに分割されました、二番目はPayload専用の暗号が復号化鍵となります。暗号化鍵の所有者以外Payloadの内容を復号化は出来ません。
   
   画像引用元

SD-JWT

今回のOpenIDサミットにてイタリアの電子マネー導入運用の実績を紹介いただきました。そこでSD-JWTという新概念について説明がありました。私自身初耳だったので、サミットが終了してから自分でも検索してみました。ここからがいよいよ本記事の主題です。私が検索したSD-JWTについて簡単に説明したいと思います。
Selective Disclosure JWT(SD-JWT)は名前の通り、選択的に開示するJWTというものです。JWSとJWEがすでに世の中に存在しているのに、どんな経緯でSD-JWTが設計されたのかを最初に説明します。
Payloadの内容開示については、現在以下の二つが存在します:

• 全部開示　：JWSをbase64で解析して、Payloadにあるすべての内容を誰でも見ることができます。
• 全部非開示：JWEの場合は復号化キーを持っている所有者以外、JWEのPayloadの内容を見れません。

ただ、一部の情報しか公開したくない場合には対応する案がありません。そのため、SD-JWTが世に生まれました。
例えば、電子ウォレットの所有者が10万円の商品を購入する際、商品の販売者が購入者の認証に使う一般的な属性情報（誕生日、住所、電話番号など）を見る必要がなく、購入者の電子ウォレット残高だけを見たい場合。購入者としても、すべての個人情報を全部公開せずに、残高やIDなどの必須情報だけを開示すれば購入できます。
これだけでは足りないかもしれませんが、JWSから所有者の必要な情報だけを事業者へ開示することで、ある程度は個人情報漏えい防止にも有効になります。

SD-JWT実現方法

従来のID token生成手順から着手します。
まずは、あるユーザーAさんの個人情報を以下のようにJSON形式で表示します。

{
  "sub": "cd48414c-381a-4b50-a935-858c1012daf0",
  "given_name": "jun",
  "family_name": "liang",
  "email": "jun.liang@example.com",
  "phone_number": "+81-080-123-4567",
  "address": {
    "street_address": "123-456",
    "locality": "shibuya",
    "region": "Tokyo",
    "country": "JP"
  },
  "birthdate": "1989-01-01"
}

そして、発行者はそれぞれの属性情報に対してSD-JWT Salt(ランダム値)を付与します。

{
  "sd_release": {
    "sub": "[\"2GLC42sKQveCfGfryNRN9c\", \"cd48414c-381a-4b50-a935-858c1012daf0\"]",
    "given_name": "[\"eluV5Og3gSNII8EYnsxC_B\", \"jun\"]",
    "family_name": "[\"6Ij7tM-a5iVPGboS5tmvEA\", \"liang\"]",
    "email": "[\"eI8ZWm9QnKPpNPeNen3dhQ\", \"jun.liang@example.com\"]",
    "phone_number": "[\"Qg_O64zqAxe412a108iroA\", \"+81-080-123-4567\"]",
    "address": "[\"AJx-095VPrpTtM4QMOqROA\", {\"street_address\": \"123-456\", \"locality\": \"shibuya\", \"region\": \"Tokyo\", \"country\": \"JP\"}]",
    "birthdate": "[\"Pc33CK2LchcU_lHggv_ufQ\", \"1989-01-01\"]"
  }
}

「_sd_alg」に記載されたハッシュ関数で「sd_release」のそれぞれの属性情報を計算して下記の「_sd」へ格納し、かつ発行者の署名鍵(cnf)、有効期間(ext)、発行時間(iat)を加えて新しいPayloadを作成できます。
Payloadに基づいて最新のTokenを発行すると、SD-JWTが作成できました。

{
  "kid": "tLD9eT6t2cvfFbpgL0o5j/OooTotmvRIw9kGXREjC7U=",
  "alg": "RS256"
}.
{
  "_sd": [
    "5nXy0Z3QiEba1V1lJzeKhAOGQXFlKLIWCLlhf_O-cmo",
    "9gZhHAhV7LZnOFZq_q7Fh8rzdqrrNM-hRWsVOlW3nuw",
    "S-JPBSkvqliFv1__thuXt3IzX5B_ZXm4W2qs4BoNFrA",
    "bviw7pWAkbzI078ZNVa_eMZvk0tdPa5w2o9R3Zycjo4",
    "o-LBCDrFF6tC9ew1vAlUmw6Y30CHZF5jOUFhpx5mogI",
    "pzkHIM9sv7oZH6YKDsRqNgFGLpEKIj3c5G6UKaTsAjQ",
    "rnAzCT6DTy4TsX9QCDv2wwAE4Ze20uRigtVNQkA52X0"
  ],
  "iss": "https://example.com/issuer",
  "iat": 1706075413,
  "exp": 1735689661,
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "SVqB4JcUD6lsfvqMr-OKUNUphdNn64Eay60978ZlL74",
      "y": "lf0u0pMj4lGAzZix5u4Cm5CMQIgMNpkwy163wtKYVKI",
      "d": "0g5vAEKzugrXaRbgKG0Tj2qJ5lMP4Bezds1_sTybkfk"
    }
  }
}.
{
  シグネチャー
  発行者は公開鍵でPayloadのシグネチャーを計算してここに置く、Payloadの内容を改竄されない事が保証できる
}

「sd_release」と「_sd」それぞれの属性とハッシュ値の順番は守らなくても大丈夫です。

SD-JWT利用方法

発行者はSD-JWTと「sd_release」を一緒に所有者へ送ります。
所有者は使う場面によって、開示したい属性情報とSD-JWTを同時に提出すると、安全性と完全性を守る前提で認証ができます。

  "email": "[\"eI8ZWm9QnKPpNPeNen3dhQ\", \"jun.liang@example.com\"]",

メールアドレスだけを開示したいのであれば、上記の部分とSD-JWTを一緒に提出することになります。
検証者は以下の２点を確認することでメールの正確性が確認できます

• emailの部分をハッシュ関数で計算する結果と「＿sd」一覧にある "5nXy0Z3QiEba1V1lJzeKhAOGQXFlKLIWCLlhf_O-cmo" が一致すること
• PayloadのSignature再計算結果とSD-JWTに有るSignatureが一致すること（Payloadが改ざんされていない）

まとめ

今回のサミットへ参加することによってOpenIDが発展してきた歴史や、今後の展開について理解できました。また、これまで我々IDチームが使っていたJWTと違う形式であるSD-JWTについても知ることができました。
面白い話がたくさんありましたので、普段はID分野に携わっていない方々へもぜひご参加をおすすめします。
今後、KINTOテクノロジーズとしても登壇できるようになることを心待ちにしています。

レファレンス

OpenID Summit Tokyo 2024