ToppyMicroServices

RFC 8725 Quiz (JA)

JSON Web Token Best Current Practices

ENJA
0 / 0

参照（URL）

Q1: RFC 8725に沿うalgorithm-selection behaviorはどれか

Multiple Choice

A2A verifierのlibraryはRS256とES256をsupportします.このtoken profileが許すのはES256だけですが,incoming tokenはalg=RS256を宣言し,有効なRS256 signatureを持ちます.

**Explanation:** A: Section 3.1はlibraryがcallerにsupported setを指定させ,その外のalgorithmをoperationに使わないよう要求します. B: 正解です.Section 3.1はheader algorithm,実際のoperation,keyにassociated algorithmの一致も要求します. C: selected profile外で成功したoperationは,そのprofileに対するsuccessful validationではありません. D: Verificationにはsignatureを実際に生成したalgorithmが必要で,inputのrelabelではprofile mismatchを修復できません.

Q2: cross-JWT confusionに対処するprofile変更はどれか

Multiple Choice

一つのissuerがA2A access tokenとAgent Card attestationの両方を同じkeyでsignします.現在はaudienceもoptional claimも同じため,どちらのtokenも他方のvalidatorを通ります.

**Explanation:** A: Endpoint provenanceは失われたり混同されたりし,token classをcryptographically/semanticallyにexclusiveにはしません. B: optional discriminatorではwrong validatorにtokenをrejectさせられません. C: Section 3.11はnew JWT useにexplicit typingを推奨し,type再利用はそのdiscriminatorを失わせます. D: Section 3.12は異なるJWT kindがconfuseされ得るときmutually exclusive ruleを要求し,これらの分離方法を列挙します.

Q3: gatewayはAgent Card attestationをaccess tokenとしてacceptすべきか

Multiple Choice

attestationはtrusted issuer Iが正しくsignし,aud=gatewayでunexpiredです.access-token endpointもIをtrustします.access-token profileはtyp=a2a-access+jwtとscope=task.writeを要求しますが,attestationはtyp=a2a-card+jwtでscopeを持ちません.authorizationにはaccess-token profileが必要です.

**Explanation:** A: Sections 2.8 and 3.12がこのsubstitution riskを扱います.shared valid propertyはclass-specific ruleを消しません. B: verifierはsignature verification後にauthorization claimをinventしてissuerへ帰属できません. C: 正解です.Sections 3.11 and 3.12がexplicit typingとmutually exclusive ruleを支え,指定access-token profileが判定基準です. D: Section 3.12はvalidation ruleが確実に分離するなら,一issuerが異なるkindを発行する構成を認めます.

Q4: jku URLをdereferenceする前にsignature verificationだけで十分か

Multiple Choice

multi-issuer A2A gatewayはsigned JWTのjkuを読み,そのURLからverification keyを取得します.trusted issuerはconfiguredですが,jkuでは任意HTTPS hostを許します.security requirementはattacker-directedなinternal serviceへのrequestを禁止します.

**Explanation:** A: Section 3.10はlookupに使うclaim/headerのvalidationまたはsanitizationを要求し,injection/SSRF mitigationとしてallowlistingを挙げます. B: Key lookupはsignature authenticity確立前に起きます.attacker-controlled lookup inputはunverified signatureからtrustを継承しません. C: HTTPSは選択したserverをauthenticateしますが,そのdestinationがapplicationに許可されることは示しません. D: configured issuer-to-key-location bindingはattacker-controlled network requestより前に確認できます.

Q5: verifierはこのHS256 tokenをどう扱うべきか

Multiple Choice

A2A profileはissuer IのRSA public keyによるRS256だけをacceptします.libraryはHS256もimplementします.attackerはalg=HS256とし,公開RSA public-key bytesをHMAC secretとしてHMACを計算します.判定基準はprofileのRS256 issuer authenticationです.

**Explanation:** A: Section 2.1がこのalgorithm confusion classを説明します.public keyをattackerが利用できるsymmetric secretへ再解釈してはいけません. B: Section 3.1はcaller-selected algorithm setとkeyごとの一algorithmをcryptographic operation時に確認させます. C: libraryの全algorithmを試すと,tokenがprofile外のvalidation modeを選べます. D: Claim validationは必要ですが,selected algorithm/keyによるissuer authenticationを置き換えません.

Q6: 指定authorization criterionを満たすgateway-to-backend設計はどれか

Multiple Choice

gatewayは同一issuerのaccess JWTとsession-binding JWTをacceptします.一つのgeneric ruleでsignatureをverifyし,X-Agentにsubだけをforwardします.backendはそのheaderからtask.writeをauthorizeします.backend policyはbackend自身向けaccess tokenと,このrequestに対するindependently validなsession-binding proofを要求します.

**Explanation:** A: Subject valueはtoken class,audience,scope,session-binding evidenceを運びません. B: Section 3.11のtypingはvalidation時のconfusionを防ぎますが,unprotected downstream headerはvalidated resultを保持しません. C: Section 3.12はauthorization policyがconsumptionする前にwrong-kind JWTをmutually exclusive ruleでrejectさせます. D: Sections 3.8, 3.9, 3.11, and 3.12がJWT checkを定義します.protected downstream assertionとfinal authorization ruleはA2A trust-boundary choiceであり,RFC 8725が自動生成する保証ではありません.