ToppyMicroServices

RFC 7519 Quiz (JA)

JSON Web Token (JWT)

ENJA
0 / 0

一次資料

JWTの構文・暗号検証と、claim要件、key trust、replay対策、application authorizationを分けて判断する問題です。節番号はRFC 7519を指します。

Q1: RFC 7519がすべてのJWTへ必須とするclaimはどれか

単一選択

A2A profileは全task tokenへiss, sub, aud, exp, jtiを含めたいと考えています. authorはRFC 7519自身がこのclaim setを必須にすると説明しています.

**解説:** A: claimのregistrationは全registered claimをmandatoryにはしません. B: RFC 7519 Section 4は, required claimがcontext dependentでbase specificationの一律要件ではないとします. profileは選択したclaimを必須にしてoperational meaningを定義できます. C: issとexpもRFC 7519で一律mandatoryとはされていません. D: base specificationがapplicationへ選択を委ねることと, profileが要件を課せないことは別です.

Q2: A2A recipientはaudをどうvalidateすべきか

単一選択

JWTのaudは["task-gateway", "billing-agent"]です. billing-agentがtokenを処理し, 無関係なinventory-agentがcopyされたrequestを受け取ります.

**解説:** A: recipientはaudience valueの中で自身を識別する必要があり, non-empty arrayだけでは不十分です. B: issuerとkey validationはrecipient restrictionの代わりになりません. C: RFC 7519 Section 4.1.3はstringまたはarrayを許し, processorがaud内で自身を識別できなければrejectするよう求めます. aud通過だけでoverall acceptanceが決まるわけではありません. D: array順序によって最初のaudienceだけへ制限されません.

Q3: unverifiedなiss claimにverification keyを選ばせてよいか

単一選択

A2A serviceはJWTをverifyする前にissを読み, その値だけから構成したURLでkeyを取得し, 取得keyでsignatureがverifyできればacceptします. issuer-to-keyのconfigured trust relationshipはありません.

**解説:** A: attackerがissuerを名乗り, それをvalidateするkeyも供給できるcircular trustになります. B: HTTPSは選択endpointへのtransportを保護しますが, そのendpointをclaimed JWT issuerとしてauthorizeしません. C: configured trustで制約すればissuer-aware key selectionは安全に構成できます. RFC 7519は禁止していません. D: RFC 7519 Sections 7.2 and 11.1は, 必要なtrust context内でのcryptographic validationを求めます. issuer-to-key associationとacceptable algorithmはapplicationまたはprofile policyです.

Q4: このtokenは現在のtime window内か

単一選択

verifier timeが12:00:30Zの時, tokenのnbfは12:01:00Z, expは12:10:00Zです. profileが許すclock-skew leewayは最大10秒です.

**解説:** A: RFC 7519 Section 4.1.5は, 許容leewayを除きcurrent timeがnbfより前でないことを求めます. B: stated acceptance window外です. Sections 4.1.4 and 4.1.5がexpとnbfを定義し, skewにsmall leewayを使えます. そのboundはprofileが選びます. C: leewayはboundaryを限定的に調整するもので, claim checkを削除しません. D: 両claimを併用してvalidity intervalを限定できます.

Q5: jtiだけでtoken replayを防げるか

単一選択

すべてのA2A task tokenはuniqueなjtiとvalidなsignatureを持ちます. verifierはreplay stateを保持せず, expまで同じtokenを何度でもacceptします. profileはjtiを含めるだけでone-time useになると主張します.

**解説:** A: claimが存在するだけでJWT processingがreplay stateを作ることはありません. B: expはacceptance intervalを制限しますが, その中でのreuseを防ぎません. C: RFC 7519 Section 4.1.7はjtiをreplay防止へ利用できるとします. 実際のdetection protocol, storage, scope, retentionはprofileまたはdeploymentが選びます. D: RFC 7519は一律のpermanent storageを要求しません.

Q6: gatewayだけをaudienceとするJWTをどう扱うべきか

単一選択

signed task JWTのaudは"task-gateway"だけです. gatewayがvalidateした後, resourceを所有するbilling backendを呼びます. profile次第で, backendはoriginal JWTを処理するかgateway assertionを信頼します.

**解説:** A: RFC 7519 Section 4.1.3はJWT recipientへaud内で自身を識別するよう求めます. protected gateway assertionは別のtrust modelであり, gateway, context, downstream requestをauthenticateする必要があります. resource ownerはauthorizationを別に判断します. B: deployment topologyはsigned audience claimを書き換えません. C: claimのcopyはoriginal signature protectionを失います. new carrierを独立に保護しgateway assertionとして解釈する必要があります. D: token validationとresource authorizationは別のdecisionです.

Q7: 複数componentが重複claimから別々の値を選んでよいか？

単一選択 · L3

JWT Claims Setにroleが2回あり、最初はviewer、次はadminです。upstream parserは最初の値を保持し、resource serverは最後の値を保持してadministratorとしてauthorizeします。

**解説:** A: applicationがclaimの意味を定義できても、Claims Setのparse規則は上書きできません。 B: より強いpermissionを選ぶ規則はRFCになく、曖昧さをprivilege escalationへ変えてしまいます。 C: Section 4はclaim名をuniqueとし、parserに重複のrejectまたは字句上最後の値だけを返す動作を求めます。profileはsecurity-relevantな全componentが、許された一貫した動作を使うようにします。最初の値を採るupstreamの動作は、そのどちらでもありません。 D: RFC 7519が許すのはrejectまたは最後の値であり、最初の値を残す規則ではありません。

Q8: RFCがUnsecured JWTを扱えるなら、この入力も受理できるか？

単一選択 · L3

A2A profileは、設定済みissuerが署名したtask JWTだけを受理します。外部requestから、algがnone、signature valueが空で、もっともらしいaudとexpを持つwell-formedなUnsecured JWTが届きました。

**解説:** A: Section 6はUnsecured JWTの形式を明示的に定義しているため、一律にmalformedではありません。 B: 提示されたprofileは設定済みissuerによるauthenticationを要求します。Sections 7.2と11.1は、algorithmの受理と必要なtrust contextをapplicationへ委ねており、構文上validであることをtrustへ変えません。そのため、この入力は表現可能でもprofileの受理条件を満たしません。 C: 必要なissuer protectionがなければ、audienceとtime claimも信頼できないassertionです。 D: JOSE Headerの変更はprotected inputを変えるため、validな署名を新たに作ることはできません。