ToppyMicroServices

RFC 7800 Quiz (JA)

JWT Proof-of-Possession Key Semantics

ENJA
0 / 0

一次資料

confirmation keyの識別と、所持証明、replay対策、token検証、resource認可を分けて扱います。Section番号はRFC 7800を指します。

Q1: cnf claimだけで確立できるものは何か？

単一選択

signed A2A task tokenがpresenterのpublic keyを含むcnf claimを持ちます. requestはtokenを運びますが, 対応するprivate keyによる別proofはありません.

A: issuerのtoken signatureはcnf claimをauthenticateしますが, request presenterがreferenced private keyをcontrolすることは示しません. B: RFC 7800 Sections 3 and 3.6はconfirmation-key semanticsを定義し, actual proof protocolは意図的にapplicationへ委ねます. C: cnfはpresentationを制約するためのもので, bearer useやresource permissionを付与しません. D: public confirmation keyはJWTを暗号化しません.

Q2: confirmation keyをJWTへどう格納できるか？

単一選択

A2A profileは, asymmetric public JWKまたはsymmetric MAC keyを, signed but unencrypted JWTのcnfへ直接入れる案を検討します.

A: signatureはintegrityとorigin authenticationを提供しますが, confidentialityは提供しません. B: RFC 7800はdirect JWKとkey-identifier representationの両方を定義します. C: RFC 7800 Sections 3.2 and 3.3はpublic asymmetric JWKと, unauthorized partyから暗号化すべきsymmetric key materialを区別します. D: short lifetimeでもactive MAC keyのdisclosureは安全になりません.

Q3: このholder proofはrequest-level sender constraintに十分か？

単一選択

presenterはcnf private keyでfixed stringへ署名します. 同じsignatureを全A2A requestへ付け, method, URI, body digest, nonce, time valueをcoverしません. profileは各requestへbindしたreplay-resistant proofを求めます.

A: reusable fixed-string signatureはkey useを示しますが, particular requestのintegrityやfreshnessを示しません. B: audienceはtoken recipientを制限しますが, 別holder proofをfreshにしません. C: RFC 7800 Section 3.6はnonceとproofの詳細をapplication protocolへ意図的に委ねます. D: profileが明記したrequest bindingとreplay resistanceの基準により、このreusable signatureは不十分です。Section 3.6はproof formatをapplicationへ委ね、Section 4はdistinct challengeやinstance-specific sub-keyをreplay対策の例として示します。一律のformatを定めてはいません。

Q4: ambiguousなcnf kidをどうresolveすべきか？

単一選択

二つのA2A tenantが異なるkeyへ同じcnf kid "signing-key-1"を使います. verifierはtrusted token issuerやtenant contextへbindする前に, single global tableでkidをlookupします.

A: RFC 7800はkidをglobally uniqueにしません. B: RFC 7800 Section 3.4はkid contentをapplication specificとし, recipientがidentified keyを取得できる場合にだけ機能するとします. profileはcross-namespace key confusionを防ぐ必要があります. C: 全keyを試すとidentifierの解釈に必要なtrusted identity contextを失います. D: identifierのdigestはkey materialではなくpossessionを示しません.

Q5: cnf tokenをbearer processingへfallbackしてよいか？

単一選択

A2A resourceがcorrect audienceとcnf claimを持つtokenを受け取ります. requestにvalidなholder proofがない場合, implementationはcnfをignoreしてbearer tokenとして処理します. profileはproof of possessionを必須にします.

A: RFC 7800 Section 4はproof of possessionとaudienceが異なるprotectionを提供すると説明します. B: token validationはclaimをauthenticateしますが, presenterが現在keyをpossessすることは示しません. C: profileの明示的acceptance criterionを適用し、他profileに一律のbearer fallback ruleを作っていません。Section 3.1が未知のconfirmation memberを無視するよう求めるのは、それを理解するapplication要件がない場合です。 D: audとcnfは共存でき, 独立したsecurity propertyを扱います.

Q6: gatewayはverified cnf resultをどうdelegateすべきか？

単一選択

gatewayがincoming requestのcnf tokenとholder proofをvalidateし, 別connection上のbackendへX-Proof-Valid: trueだけをforwardします. backendはresourceを所有しますがoriginal proofを確認できません.

A: RFC 7800 Sections 3.6 and 4はproof transportとreplay controlをapplicationへ委ねます。したがって、これはsystem design上の結論です。どちらの案もverifierとtrust boundaryを明示し、request contextを保ちます。resource ownerはauthorizationを別に判断します。 B: 通常のbooleanはcryptographic evidenceではなく, requestへbindされていません. C: public keyは何をproveすべきかを識別しますが, possessionがverifyされたかは示しません. D: proof of possessionとresource authorizationは独立しています.

Q7: recipientはこのcnf objectをどう処理すべきか？

単一選択

issuerはrollover対応として、1つのcnf objectへjwkとjkuの両方を入れた。jkuはbackup keyを指し、kidも付いている。recipientは複数confirmation keyを定義する拡張なしでRFC 7800を実装している。

A: RFC 7800はjwkとjkuの優先順位を定義しません。 B: 両方を試すと、token formatが定義していないsemanticsを暗黙に作ります。 C: Section 3.1は、cnfが1つのproof-of-possession keyだけを表すことをMUSTとし、jwk、jwe、jkuのうち最大1つだけを許します。複数keyが必要なapplicationは別claimまたは拡張を定義します。 D: Section 3.5のkidはreferenced set内のkey選択に使えますが、cnf内の2つ目のkey表現を許可しません。

Q8: recipientはこのjkuから取得したkeyをacceptしてよいか？

単一選択

cnfのjkuはhttp URLである。取得したJWK Setには3つのkeyがあるが、cnfにkidはない。recipientは以前のresponseで1つのkeyを見たことがある。

A: cache上の既知性は、今回の取得と選択に対する要件を満たしません。 B: Section 3.5はintegrity protectionを求め、HTTP GETはTLSを使いserver identityを検証しなければなりません。setに複数keyがある場合、cnfと選択対象JWKは同じkidを持たなければなりません。 C: trial verificationは規定されたkey-selection条件を迂回します。 D: jkuは明示的に定義されています。問題はremote取得自体ではなく、保護されないURLとselectorの欠落です。

Q9: この実装はA2A profileへ適合するといえるか？

単一選択

A2A profileはagent_proofという登録済みcnf memberを必須にする。JWT libraryはこのmemberを理解せず、無視したまま通常のJWT validation後にtokenをacceptする。

A: Section 3.1のMUST-ignore ruleは、そのmemberを処理する要件がない場合に限られます。 B: JWT validationはclaim setを保護しますが、application-specificなconfirmation methodを実装しません。 C: RFC 7800はextension memberを許し、一律のrejectを求めません。 D: Section 3.1は、特定のconfirmation memberを必須にするapplicationに、実装がそれを理解・処理することの確保を求めます。ここでのacceptは、未知member一般の規則ではなく、明示されたprofileに違反します。

Q10: privacy reviewとして適切な結論はどれか？

単一選択

agentは、互いに無関係なrecipientへ送るJWTで1つのlong-lived confirmation keyを再利用する。各recipientはkey identifierをlogへ残し、後にlogが統合される。protocolはpossession自体を正しくverifyしている。

A: Section 5はproof-of-possession keyがcorrelation handleになり得ると警告します。一律のlifetimeは定めないため、key scopeとrotationはapplicationのprivacy判断です。 B: observerはprivate valueを知らなくても、stableなpublic keyまたはidentifierをcorrelateできます。 C: RFC 7800はprivacy riskを示しますが、per-request keyを必須にしません。 D: audience restrictionは別の境界を保護し、削除してもstable identifierは消えません。