ToppyMicroServices

RFC 8414 Quiz (JA)

OAuth 2.0 Authorization Server Metadata

ENJA
0 / 0

一次資料

metadata syntax、issuer binding、signer trust、advertised capability、resource authorizationを分けて扱います。Section番号はRFC 8414を指します。

Q1: authorization server metadataは何を解決するか？

Multiple Choice
RFC 8414 Section 2は,clientがauthorization serverとの接続方法を学べるよう,その設定を記述するmetadataを定義します.documentを読んでもgrantやtokenは発行されず,resourceがtrustすべきissuerも決まりません.token validationとresourceのauthorization判断は,この設定機構とは別です.

Q2: reviewerが指摘すべき2つの欠陥はどれか？

Multi-Select

metadata documentはissuerをhttps://as.example?tenant=1とし、signed_metadataを含む。grant_types_supportedはあるが、response_types_supportedは省略されている。

RFC 8414 Section 2は,queryとfragmentのないHTTPS `issuer`と,JSON arrayの`response_types_supported`をrequiredとします.signed metadataもissuer syntaxを緩和せず,別のcapability fieldもrequired fieldを置き換えません.consumerはdiscovery anchorと,optionalなcapability descriptionやfield固有defaultを区別する必要があります.

Q3: default suffixを使うissuer https://as.example/tenant-a のmetadata取得先はどれか？

Multiple Choice
RFC 8414 Section 3.1はauthorityとissuer pathの間へ`/.well-known/oauth-authorization-server`を挿入するため,取得先は`https://as.example/.well-known/oauth-authorization-server/tenant-a`です.tenant pathの後ろへsuffixを足したり,pathをsuffixの一部にしたりするとregistered constructionが変わります.1 hostで複数issuerを扱う場合は,pathの保持が特に重要です.

Q4: 取得documentのissuer値が,URL構成に使ったissuerと異なる.clientはどうすべきか？

Multiple Choice
RFC 8414 Section 3.3は,返された`issuer`とmetadata URL構成に使ったissuerのexact equalityを要求し,不一致responseの使用を禁止します.document内部の置換値へ従えば,response自身にtrust targetをredirectさせることになります.registrable-domainの近さは指定比較ではなく,endpointやkey-location claimを含むmetadata全体をrejectします.

Q5: 対応clientがplain metadataとsigned metadataで矛盾する値を受信した.どちらが優先されるか？

Multiple Choice
RFC 8414 Section 2.1は,処理する`signed_metadata`へsignatureまたはMACと`iss`を要求し,検証後は対応するplain claimより優先させます.非対応consumerはmemberを無視できますが,処理を選んだconsumerがconflictを第3の値へmergeしたり,TLSでsignatureやtrust checkを代替したりはできません.support,暗号検証,signer trust,precedenceは別々のstepです.

Q6: clientが適用できる2つのdefaultはどれか？

Multi-Select

legacy serverはgrant_types_supported、token_endpoint_auth_methods_supported、scopes_supported、jwks_uriを省略している。clientはRFC 8414が省略時の規則を定義する項目だけ設定する。

RFC 8414 Section 2は,`grant_types_supported`省略時を`authorization_code`と`implicit`,token endpoint authentication method省略時を`client_secret_basic`と定義します.一方,recommendedな`scopes_supported`がないことはsupport scopeなしを意味せず,optionalな`jwks_uri`がないこともlocation推測を許しません.defaultはfield definitionが明記した場合だけ適用し,それ以外はunknownまたは別の指定済み設定経路として扱います.

Q7: このclientはdiscoveryしたserverをA2A resourceに対してauthorizedとみなせるか？

Multiple Choice

userがissuerとしてhttps://login.attacker.exampleを入力する.TLS validationに成功し,返されたissuerも完全一致し,metadataはsyntax上正しい.しかしclientには,そのissuerを要求A2A resourceへ関連付けるpolicyがない.

RFC 8414 Section 3.3と6.2は,入力として選んだissuerに対するdiscovery substitutionを防ぎますが,そのissuerが特定A2A resourceに適切かは決めません.Section 6.4はauthorization-server-to-resource associationの安全な決定をscope外かつapplication dependentとします.completeでvalidなmetadataが証明するのは選んだissuerの設定なので,clientにはtarget resourceがそのissuerをtrustする別の根拠が必要です.

Q8: このsigned_metadata objectをclientはどう処理すべきか？

Multiple Choice

metadataのsigned_metadataは暗号的にvalidなJWSで,issはclientに未知である.unsigned JSON claimは既知token endpointを示すが,signed claimは未知hostへ置き換える.

RFC 8414 Section 2.1はsigned representationとprecedenceを定義しますが,objectと`iss`の検証後にだけ適用できます.未知keyによる数学的にvalidなsignatureは,そのsignerがissuer endpointを定義するauthorityを持つことまで証明しません.validation失敗時に別endpointを合成する規則もないため,applicationは値を使う前にsigner-to-issuer trustを確立します.

Q9: このmulti-tenant discovery flowに必要な修正はどれか.2つ選べ.

Multi-Select

issuer https://as.example/t1 に対し,clientはhttps://as.example/t1/.well-known/oauth-authorization-serverを取得する.双方が同じTLS certificateを使うため,issuerがhttps://as.example/t2のdocumentも受理する.

RFC 8414 Section 3.1はtenant pathをwell-known suffixの後ろへ保持し,Section 3.3は返されたissuerとURL構成に使った値のexact equalityを別に要求します.shared TLS certificateはhost connectionを認証しても,`/tenant-a`と`/tenant-b`を同一issuerにはしません.cross-tenant confusionを防ぐには,path-preserving constructionとexact comparisonの両方が必要です.

Q10: discovery,token proof,backend authorizationを正しく合成した評価はどれか？

Multiple Choice

RFC 9728 resource metadataがauthorization serverを列挙する.A2A clientはそのRFC 8414 metadataを検証し,grantを取得してsession-bound proofをgatewayへ提示する.gatewayは両方を検証し,resource policyを持つbackendへunsigned identity headerだけを転送する.

RFC 8414 Section 3.3と6.2はintended issuerに対するmetadataを認証し,Section 6.4はissuer-to-resource associationをapplicationへ残します.discovery,grant validation,session-bound proof,backend authorizationはそれぞれverifierとscopeが異なり,一段の成功はunsigned internal headerを保護せず,ほかの段を遡ってvalidにもしません.trusted issuer inputと各検証結果を,最終resource判断を持つcomponentまで明示的に保護する必要があります.

Q11: 受信したextension nameは登録名と一致するか？

単一選択

A2A profileはmetadata name agent-rôleのôへprecomposed U+00F4を使う。documentは見た目が同じ名前を、U+006FとU+0302で表す。JSON parserはすでにJSON escapingを除去している。

A: Section 4はUnicode normalizationを適用してはならないと明記します。B: rendering上の同一性は指定されたequality testではありません。C: JSON escapingの除去後、Unicode code pointを1つずつ比較するため、この2列は異なります。D: RFC 8414はadditional metadata parameterを許し、ここで主張するASCII限定規則は設けていません。profileが独自に文字を制限することは別のprofile requirementです。

Q12: clientはこのadvertised methodのalgorithmを推測できるか？

単一選択

metadataはtoken_endpoint_auth_methods_supportedでprivate_key_jwtをadvertiseするが、token_endpoint_auth_signing_alg_values_supportedを省略している。implementerはRS256を仮定しようとしている。

A: Section 2はserverがRS256をsupportすべきとしますが、field省略時のimplicit algorithmは定義しません。B: private_key_jwtまたはclient_secret_jwtをadvertiseする場合、token_endpoint_auth_signing_alg_values_supportedは必須です。clientがalgorithmを作って補ってはいけません。C: authentication-method nameは単一JWS algを選択しません。D: RFC 8414はprivate_key_jwtのadvertiseを明示的に扱います。欠陥はdependent metadataの欠落です。