Q1: token exchangeが誰のためにrequestされたかをidentifyするinputはどれ?単一選択 A. requested_token_type B. subject_tokenとsubject_token_type C. issued_token_type **解説:** A: これはdesired output token typeを示しsubject principalではない. B: subject tokenはrequested tokenのsubjectとなるpartyを表す. C: これはresponseでissued token typeをidentifyする.
Q2: token exchange requestでvalidなoptional credentialとtype parameterのpairはどれ?単一選択 A. subject_tokenとactor_token_type B. requested_token_typeとactor_token_type C. actor_tokenとactor_token_type **解説:** A: subject credentialにはsubject_token_typeを使う. B: requested output typeとactor-token typingは独立している. C: authorization serverがoptional credentialを解釈するためactor tokenのtypeが必要である.
Q3: resource parameterとaudience parameterが表すものはどれ?単一選択 A. requested tokenのtarget service B. original grantをapproveしたhuman user C. output tokenのcryptographic algorithm **解説:** A: clientがintended resource serverまたはlogical audienceをidentifyできる. B: subjectはsubject tokenとclaimがidentifyしresourceやaudience parameterではない. C: これらのtarget parameterはtoken algorithm selectionのためではない.
Q4: requestedされたaudienceとresourceの組合せがpolicy上広すぎる. appropriateなerrorはどれ?単一選択 A. 全targetはgrantなのでinvalid_grant B. invalid_target C. tokenがlargeなのでtemporarily_unavailable **解説:** A: 問題はinput grantとは限らずrequested target setである. B: このerrorはrequested resourceまたはaudienceの組合せがinvalidまたはunacceptableであることを示す. C: targetのpolicy rejectionはtemporary availability failureではない.
Q5: issued_token_type response parameterはclientに何を伝える?単一選択 A. 現在どのactorがtokenを使うか B. resource serverがtokenをacceptしたか C. issueされたtokenのtype identifier **解説:** A: actor identityはissued_token_typeではなくactなどのclaimで表す. B: token exchange responseは後のresource-server acceptanceより前である. C: responseはrequested typeと異なる場合もissued token typeを明示する.
Q6: act claimを持つJWTでtop-levelのact memberは何を表す?単一選択 A. subjectのためにactingするcurrent actor B. target resource server C. original authorization serverだけ **解説:** A: top-level act claimはdelegation chainのpresent actorをidentifyする. B: targetはactor claimではなくaudienceまたはresource情報に入る. C: act claimはacting partyをmodelしissuer-only fieldではない.
Q7: delegation chainが伸びたときearlier actorをどう表す?単一選択 A. 全previous actorをnewest actorでreplaceする B. prior act claimをnew act claim内へnestする C. actorをscope stringへcopyする **解説:** A: historyをdropするとpolicyとauditに必要なdelegation pathを失う. B: nested act objectでcurrent actorとprior actorの順を表す. C: scopeはrequested privilegeを表しactor-chain structureではない.
Q8: RFC 8693は全token exchangeをpermitted delegationにする?単一選択 A. はい, 任意subject tokenのpossessionで十分 B. はい, actor_tokenが自動的にimpersonationをgrantする C. いいえ, delegationまたはimpersonationはauthorization-policy decisionである **解説:** A: authorization serverはtokenをvalidateしrequested exchangeをauthorizeする必要がある. B: actor tokenはactorをidentifyするがexchange policyをbypassしない. C: RFC 8693はexchange frameworkを提供するが全requested authority transitionをgrantしない.
Q9: successfulなtoken exchange responseはrefresh tokenを含む必要がある?単一選択 A. いいえ, refresh_tokenはoptional B. はい, 全exchanged tokenはrenewableである必要がある C. はい, actor_tokenがabsentの場合だけ **解説:** A: authorization serverはissueできるがsuccessful exchangeに必須ではない. B: RFC 8693は全exchangeにrenewal rightを要求しない. C: actor-token presenceはmandatoryなrefresh-token responseを作らない.
Q10: agentがuser tokenをdownstream service tokenへexchangeする. essentialなprofile checkはどれ?単一選択 A. downstream audienceを評価せず全upstream scopeをcopyする B. subjectとactor chainをvalidateしaudienceとscopeをconstrainしてexchange policyを適用する C. new tokenをdownstream action成功のproofとして扱う **解説:** A: blindなscope propagationはtarget serviceに不適切なprivilegeをgrantしうる. B: これらのcheckでtoken transformationによるsilentなauthority拡大やaccountability喪失を防ぐ. C: tokenはaccess contextを表すがoperation完了のevidenceではない.