Q1: JWK Thumbprintとは何か？
Multiple ChoiceRFC 7638 Section 2と3は,JWK Thumbprintを厳密に構成したJWK表現のdigestと定義します.この計算が識別するのはkey materialであり,certificate path,key possession,ownerの承認,authorizationを証明しません.identifierにそれらの意味を与えるのは,thumbprintを利用する後続protocolです.
一次資料
決定的な鍵識別と、鍵の出所、所持証明、鍵属性、認可を分けて扱います。Section番号はRFC 7638を指します。
Q2: この実装をRFC 7638の計算へ合わせる2つの変更はどれか？
Multi-Select2つのagentが、member順、whitespace、optional metadataの異なる、意味的には等価なJWKを受信する。現在の実装は受信JSONをそのままhashするため、同じkeyに異なるidentifierを生成している。
RFC 7638 Section 3はrequired memberだけのJSON objectを構成し,nameを辞書順に並べ,whitespaceなしでUTF-8 encodeしたoctetをhashします.Section 3.2.2はoptional memberを意図的に除外し,Section 3.3と4もUnicode normalizationを追加しません.interoperabilityには,hash前のmember,character,順序,octetがすべて一致する必要があります.
Q3: verifierがRSA thumbprint inputへ入れるmember setはどれか？
Multiple Choiceverifierはalg、e、kid、kty、n、use、x5cを含むRSA public JWKを受信した。peerが使うRFC 7638 thumbprintを再計算する必要がある。
RFC 7638 Section 3.2は,RSA public-key thumbprintへ`e`,`kty`,`n`をこの辞書順で使います.`alg`,`kid`,`use`,`x5c`はoptional metadataであり,Section 3.2.2が意図的に除外します.hash inputは到着した全memberではなく,key typeに必要な表現から決めます.
Q4: JWKのkid,use,algが変わり,required key memberは同一である.thumbprintはどうなるか？
Multiple ChoiceRFC 7638 Section 3.2.2は,同じkeyの等価な表現から同じthumbprintを得るためoptional memberを除外します.`kid`,`use`,`alg`はJWKに残せますが,hash inputにはcopyされません.そのためthumbprintはmetadata変更に対して安定する一方,それらの値をkeyへbindしません.
Q5: 両componentが共有key-pair identifierへ使う計算はどれか？
Multiple Choicesigning serviceはprivate RSA JWKを保持し、verifierは対応するpublic JWKだけを保持する。private parameterを公開せず、双方が同じRFC 7638 identifierを独立に導出する必要がある。
RFC 7638 Section 3.2.1は,private keyのthumbprintを対応するpublic keyのthumbprintとして定義します.これにより,private parameterや無関係なencryption metadataをhashせず,双方のholderが同じkey pairを参照できます.identifierはpublic表現を通じてpairを指すため,publicかprivateかはapplication contextで区別します.
Q6: opaque lookupと再計算を正しく分けるreview結論はどれか.2つ選べ.
Multi-SelectProfile Pはagent間でthumbprintを独立に再計算する。Profile Qはproducerが作ったthumbprintをopaqueなkid lookup値として運ぶだけである。どちらもhash functionを明記していない。
RFC 7638 Section 3.4はhash選択をapplicationへ任せ,thumbprintを再計算するparty間で同じfunctionを使うよう求めます.SHA-256は発行時点のよいdefaultであって永続的な一律要件ではなく,長さからalgorithmを推定する規則もありません.`kid`値をopaqueなlookupとして使うconsumerは再計算不要ですが,計算結果を比較するprofileはalgorithmを特定する必要があります.
Q7: interoperableなthumbprintを生成する実装はどちらか？
Multiple ChoiceLibrary AはJSON.stringify(receivedJwk)をhashし,入力順序とalgを保持する.Library Bはrequired memberだけの新しいobjectを作り,member nameをUnicode code point順に並べ,whitespaceなしでUTF-8 byteをhashする.
RFC 7638 Section 3と3.3はrequired memberだけを選び,nameを辞書順にし,whitespaceなしのUTF-8 octetをhashするよう求めます.Section 3.2.2はoptionalな`alg`を除外し,Section 4はgenericなJSON.stringifyがsortを保証しないと警告します.semanticに等価なJSONでもbyte列は異なり得るため,digestより先に構成octetを確認します.
Q8: このthumbprint一致からrelying partyが結論できるのはどれか？
Multiple ChoiceAgent Cardはpublic keyのthumbprint Tを記録する.後で得たJWKもprofile合意済みSHA-256規則によりTとなったが,card自体はuntrusted directoryから取得した.
RFC 7638 Section 3と3.2.2は,thumbprintをrequired key materialのidentifierとし,関連属性を除外します.一致から分かるのは,計算規則の下で2つの表現が同じkeyを指すことです.source provenance,除外metadata,fresh possession,authorizationは認証できないため,それぞれ別のprotocol checkが必要です.
Q9: Section 7の下で、このsecurity利用を正当化できなくする2つのfindingはどれか？
Multi-Selectserviceはlow-entropy symmetric keyのSHA-256 thumbprintをlogで公開する.さらにnon-canonicalなRSA encodingを受理し,thumbprint不一致をbanned keyのblacklistとして使う.
RFC 7638 Section 7は、application contextとhashが漏えいに対して十分な保護を与える場合を除き、symmetric-key thumbprintを通常は隠すべきだと述べます。これは条件付きの推奨であり、公開を一律に禁じる要件ではありません。同Sectionはthumbprint比較をkey blacklistとして信頼できないとし、uniquenessを検証済みで曖昧でないJWK表現に依存させます。この例では、明示された低entropyが公開の正当化を崩し、non-canonical encodingの受理がblacklistの前提を崩します。
Q10: thumbprint,proof,backend判断を正しく合成した評価はどれか？
Multiple ChoiceOAuth tokenはJWK Thumbprint Tを示す.A2A gatewayはTになるJWKで作られたfresh proofを検証し,X-Key-Thumbprint: Tだけをauthorization担当backendへ転送する.このheaderはほかのinternal callerから改変可能である.
RFC 7638 Section 3と3.2.2が与えるのは,Section 7のrepresentation limitを伴うstableなkey識別です.thumbprintにはnonce,request,channel bindingがないためfresh possessionを代替できず,再hashしてもsignatureは再現しません.OAuth claim trust,hop間で派生assertionを守るintegrity,backendの最終authorizationは,別々のverifierを持つ独立した保証です.