Zenn
🐡

Selective Disclosure JWTのドラフトの差分を読む

2023/02/03に公開
JWT
OAuth
tech

はじめに

以前にSlective Disclosure JWTのドラフト第1版を読んでまとめました
Selective Disclosure JWTが面白そうだったのでまとめた．

ドラフト第2版が出ていたので差分を読みたいと思います．

第1版と第2版の差分

クレーム値だけでなくクレーム名も含めてハッシュ化

第1版ではSD-JWTのクレームは以下のような形式でした．

 SD-CLAIMS = (
       CLAIM-NAME: DIGEST-DERIVATION(SALT, CLAIM-VALUE)
   )*

クレーム値はハッシュ化されますが，クレーム名は平文なのでどんな情報であるかはVerifierにわかってしまうということが第1版のプライバシー考慮事項でも言及されていました．

第2版では，以下のようなクレーム形式となり，クレーム名もハッシュ化して隠す仕様となりました．

   SD-CLAIMS = (
       HASH(SALT, CLAIM-NAME, CLAIM-VALUE)
   )*

Verifierに提示するJWTの形式変更

第1版ではVerifierに提示する形式は，ハッシュ化されたクレームが含まれるSD-JWTの後ろに開示するクレームを含むJWTを付属する以下のようなかたちでした．

<SD-JWT Header>.
<SD-JWT Payload>.
<SD-JWT Signature>.
<HSD Header>.
<HSD Payload>.
<HSD Signature?>

第2版では，つぎのようにSD-JWTの後ろに開示するクレームを個別に付与するかたちになっています．

<SD-JWT>.<Disclosure 1>~<Disclosure 2>~...<Disclosure M>~<optional Holder Binding JWT>

ここで，開示するクレームは以下のような配列形式とされています．

["ソルト", "クレーム名", "クレーム値"]

ソルトはbase64エンコードされた値が推奨されています．クレーム名は文字列である必要があります．クレーム値はJSONが許容する型（数値，文字列，ブール，配列，オブジェクト）がとれます．

また，Holder Binding JWTはオプショナルであり，以下のような形式とされています．リプレイ攻撃を防ぐnonceと開示先を明示するaudクレームが含まれています．ただし，nonce含めクレームの情報元などは本仕様のスコープ外としているようです．

{
  "nonce": "XZOUco1u_gEPknxS78sWWg",
  "aud": "https://example.com/verifier",
  "iat": 1670366430
}

エンベロープ形式

SD-JWTの提示形式を上記に記載しましたが，SD-JWTをJWTで包むエンベロープ形式が言及されています．アプリケーションや伝送プロトコルによってはこちらのほうが都合が良いとのことです．以下のような形式になります．

  {
     "iss": "https://holder.example.com",
     "sub": "did:example:123",
     "aud": "https://verifier.example.com",
     "exp": 1590000000,
     "iat": 1580000000,
     "nbf": 1580000000,
     "jti": "urn:uuid:12345678-1234-1234-1234-123456789012",
     "_sd_jwt": "eyJhbGci...emhlaUJhZzBZ~eyJhb...dYALCGg~"
   }

_sd_jwtにSD-JWTが格納されます．この形式であれば，包んでいるJWTを署名することでHolder Bindingも実現できます．

セキュリティに関する考慮事項

Disclosureの改変

HolderはIssuerから受領したDisclosureを改変してVerifierに渡す可能性があるので，Verifierは必ずDisclosureからハッシュダイジェストを計算してSD-JWTの_sdに含まれるか確認しなければなりません．

プライバシーに関する考慮事項

伝送中の機密

SD-JWTの通常の開示形式は平文で選択的開示された情報が含まれるので，TLSなどの伝送路暗号化をりようしなければなりません．もし伝送路暗号化できない場合は，例えばエンベロープ形式にした上でエンベロープ化したJWTを暗号化する（JWE）方法がとられるだろうとされています．

デコイダイジェスト

SD-JWTの選択的開示クレーム数そのものがサイドチャネル攻撃の対象となりうる場合（例えばグループメンバーのエンドユーザのみ会員番号クレームが含まれるなど），偽のダイジェストをSD-JWTに含めて防御する方法が示されています．一方で，デコイダイジェストはSD-JWTのサイズ肥大化を招くので注意が必要です．

おわりに

クレーム名もハッシュ化する点と提示形式が大きく変わりました．最近自己主権型アイデンティティも勉強中なので，そのあたりのユースケースや仕組みとリンクしながら読んでました．SD-JWTの仕様にも意識されていますが今後Verifiable CredentialsはSD-JWTの形式でユーザ自身が選択的に情報を開示するようなかたちになるのでしょうか．

Discussion