exchangeの構文とauthorization policy、actorの履歴とaccess-controlの入力、委任されたauthorityとtoken・channel bindingを区別します。Section番号はRFC 8693を指します。
subject_tokenをrequestの対象となるparty、つまり「誰のために」tokenを要求するかを表すtokenとして定義するため、Bが正しい。actor_tokenは任意のacting partyを表し、requested_token_typeはprincipalではなく希望する出力形式を表す。gatewayはmTLSでtoken endpointへclient authenticationした。form bodyには有効なsubject_tokenとそのtype、さらにactor_tokenがあるが、actor_token_typeを省略している。
actor_tokenがある場合にactor_token_typeをREQUIREDとし、ない場合の送信を禁止する。Section 2.2.2は不正なrequestにinvalid_requestを要求するため、Cが正しい。client authenticationはtoken typeを補わず、actorを黙って捨てると意味が変わり、invalid_targetはresourceやaudienceに関するerrorである。gatewayはresource Aでread、resource Bでwriteを必要とするが、Aでwriteを許可してはならない。一つのexchange requestへ二つのresourceとscope=read writeを入れる案がある。
writeを要求せずに済む。Aは存在しない順序規則を作り、Cはtarget集合を分割せず拡大し、Dは必要な権限を表さずservice policy任せにする。要求されたbackend audienceはpolicy上許可されているが、提供されたsubject_tokenのsignature validationに失敗した。
subject_tokenやactor_tokenにOAuthのinvalid_requestをMUSTで要求するため、Aが正しい。invalid_targetはresourceまたはaudienceを受理できない場合に使う。validation failureは一時的failureでも、空tokenを返す成功responseでもない。responseはSAML 2.0 assertionをaccess_tokenに格納し、issued_token_typeをSAML 2.0のtoken-type URI、token_typeをN_Aとした。このassertionはOAuth access tokenとしては使えない。
access_token fieldで任意の発行security tokenを運ぶ。issued_token_typeは表現形式を、token_typeはOAuth access tokenとしての利用方法を示し、その考え方が該当しない場合はN_Aを使う。したがってCが正しい。AとBは二種類のtypeを混同し、Dはclientに必要な表現形式を捨ててしまう。clientはscope=read writeを要求した。policyはreadだけのJWTを発行したが、clientがJWTをdecodeできるという理由で、JSON token responseからtop-levelのscopeを省略した。
scopeをOPTIONALとし、それ以外ではREQUIREDとするため、Bが正しい。tokenを読めることはresponse要件を消さず、scope縮小こそ報告が必要な場合であり、refresh tokenの有無は関係しない。gatewayがinput tokenをbackend tokenへ交換する。設計者は、exchangeがinput tokenを消費し、後のinput renewalがbackend tokenの期限を延長し、input revocationがbackend tokenへ自動伝播すると仮定している。これらを定めるprofileやdeployment mechanismはない。
盗まれたsubject JWTにmay_act.sub=gateway-7がある。unauthenticated callerはgateway-7を名乗るactor tokenも提示する。authorization serverはunidentified clientを許可し、二つの名前が一致したことだけで承認する予定である。
may_actをactorになれるかの判断材料にできるが、authorization serverは提供tokenを検証し、authorization policyを適用する必要がある。unidentified clientを許可するかはdeployment判断であり、Section 2.1はcompromised tokenを誰でもSTSで利用できる危険を警告する。Bが不足するcontrolを示す。Aはclaimをcaller proofと混同し、CはRFCを逆に読み、Dはexchangeをauthenticateもauthorizeもしない。gatewayがAliceのsubject tokenと自分のactor tokenを交換する。発行tokenにはsub=alice、act.sub=gateway-7、backend向けaudience、縮小されたscopeがある。backend policyは、誰が誰に代わってcallしたかを保持する必要がある。
actを現在のactorとし、過去のactorを入れ子で表せる。Cはこの区別とtokenの宛先制約を保持する。AとDは現在のactor contextを失い、Bは限定されたdelegationをより広いimpersonationへ変えてしまう。clientがgrantとsession-bound proofをgatewayへ送る。gatewayは両方を検証し、grantをaudience-restrictedなbearer access tokenへ交換して、自分のact claimを入れる。その後、別のTLS connectionでbackendを呼ぶ。backendは元のproof、exporter値、client sessionとの他のbindingを受け取らない。
act claimの規則に適合するaccess-controlとauditの扱いはどれ？tokenのtop-levelはsub=alice、current actorはact.sub=service-16、nested prior actorはact.act.sub=service-77である。resource serverはtokenを検証し、三つのidentityを利用したい。
actのcurrent actorだけを考慮するよう要求する。nested prior actorは情報用途の履歴で、access controlに使ってはならないため、Bが正しい。AとCは過去の履歴を規範的に使い、Dは明示的に判断対象となるcurrent actorまで捨てている。authorization serverはTLS経由でgateway clientへtokenを発行する。各tokenにはAliceのemail、employee number、完全なactor historyが入る。backendが必要なのはpseudonymous subjectとcurrent actorだけであり、policy上gatewayは直接識別子を知ってはならない。