ToppyMicroServices

RFC 9711 Quiz (JA)

Entity Attestation Token (EAT)

ENJA
0 / 0

参照（URL）

Q1: このEATのscopeを正しく説明するものはどれか

単一選択

A2A service operatorは,sandbox processのEATが運営会社のlegal identityをattestし,全deploymentで同じclaimを必須にすると説明します.

**解説:** A: RFC 9711 Section 1.1は,EAT contextのentityがpersonやorganizationを指さず,target system componentを指すとします. B: Section 1.1はindividual processをentity例に含め,entityであるためのminimum security levelはないとします. C: Sections 1.2と6はflexibilityを残します.base frameworkは全claimを一律mandatoryにせず,profileが選択を狭めます. D: Sections 1.1,1.2,6が両boundaryを支えます.componentのclaimだけではoperatorのlegal identityをattestしません. 判断軸: attested componentとprofileを明記し,component claimをoperatorへ拡張したり,base EATからuniversal token formatを推論したりしません.

Q2: final admission decisionを所有するparticipantは誰か

単一選択

attesterはEAT Evidenceをverifierへ送ります.verifierはreference valueを確認し,approved softwareが測定されたとのsigned Attestation Resultsを出します.relying partyがA2A resourceを管理します.

**解説:** A: Evidenceはtarget environmentを説明しますが,resource accessをgrantしません.attesterは全relying partyのpolicyを選べません. B: RFC 9711 Section 1.3.1は,EvidenceとAttestation Resultsの関係をverifierとそのpolicyが管理するとします.relying partyは結果を自分の判断へ使います. C: verifierはEvidenceをappraiseしますが,結果のconsequenceはrelying partyとuse caseで変わります.positive appraisalはuniversal authorizationではありません. D: claim registrationはnameとsemanticsを提供しますが,resource-owner policyやadmission decisionは提供しません. 判断軸: attestation appraisalとauthorizationは,owner,input,policyが異なる別判断です.

Q3: relying partyはTEEのdebug stateを推論できるか

単一選択

device EATのtop levelはdbgstat=disabled-fully-and-permanentlyをreportします.TEEはsubmoduleにありますがdbgstatがなく,policyはdeviceとTEEの両方でdebug disabledを要求します.

**解説:** A: RFC 9711 Section 4.2.9はsubmodule間のdebug statusにinheritanceがないと明示します. B: manufacturer identityはclaim scopeを変えません.whole-device facilityでも各submoduleが独立してreportすべきです. C: Section 4.2.9がこの結論を支えます.policyが両entityを指定する場合,missing evidenceをparent valueで置換できません. D: submoduleもdbgstatをreportできます.Section 4.2.9は独立reportがreceiverにstateを知らせる方法だと説明します. 判断軸: 各claimをreportしたentityまたはsubmoduleへ適用し,claim definitionが否定するinheritanceを作りません.

Q4: 以前validだったこのEATを今回acceptできるか

単一選択

verifierはfresh challenge N2を送ります.agentは昨日のsuccessful transactionのeat_nonce N1を含むcorrectly signed EATを返し,全measurementはreference valueに一致します.

**解説:** A: RFC 9711 Sections 4.1と9.3はfreshness mechanismを要求します.stale challengeはold tokenがcryptographically validでもreplayを許します. B: measurementはstateの問いへ答え,freshnessはevidenceが今回のinteractionでcurrentかへ答えます.一方を他方で置換できません. C: randomnessはunpredictabilityに役立ちますが,verifierはtransaction用nonceをbindしてcheckする必要があります.reuseはそのbindingを失わせます. D: Section 9.3はJSON/JWTまたはCBOR/CWT encodingに関係なく,すべてのEAT利用へfreshnessを要求します. 判断軸: authenticity,appraisal,freshnessを独立に検証します.old authentic tokenでもreplayable evidenceです.

Q5: このcross-service UEID設計をどうreviewすべきか

単一選択

agentはunauthenticated discovery endpointを含む全A2A serviceへ同じstable UEIDを送ります.各serviceのauthorization ruleはglobal device identifierを必要としません.

**解説:** A: RFC 9711 Section 8.1は,同じentityのtokenをlinkできるためUEIDは通常privacy-preservingでないとします. B: encodingやsignature formatはprivacy consequenceを除きません.Section 8はuse-case-dependentなprivacy choiceを推奨します. C: stableでglobally identicalなhashはstable correlatorのままです.disclosed identifierをcontext boundaryごとに変える必要があります. D: Sections 8と8.1は,suppression,permission,single-relying-party use,認証済み特定relying party用derived identifierを説明します. 判断軸: relying policyが必要とする場合だけidentifierを開示し,stable identifierを最小の有用contextへscopeします.

Q6: このA2A attestation boundaryで必要なcheckはどれか

単一選択

gatewayはEATとOAuth grantを検証し,session-bound proofを確認して,Attestation-Status: trustedだけをbackendへ転送します.backendはresource policyを所有し,original EATをinspectできません.

**解説:** A: RFC 9711 Sections 6,9.1,9.3はprofile choice,claim trustworthiness,freshnessを分けます.signatureだけでは他application guaranteeを立証しません. B: Sections 1.3.1と6がappraisalとprofile boundaryを定め,Sections 9.1と9.3がtrustworthinessとfreshnessを加えます.他のcheckはcomposed A2A authorization設計に属します. C: direct Evidence accessはindependent appraisalを可能にしますが,backendがdecision resultへ依存するならunprotected resultにはprovenanceがありません. D: OAuth authorizationとentity-state attestationは別の問いへ答えます.一方のtokenが他方の保証を暗黙に移しません. 判断軸: backendはgateway appraisalをtrustできますが,trust boundary,authenticated result,freshness,independent authorization inputを明示する必要があります.