RFC 9711 Quiz (EN)

Q1: Which statement correctly scopes this EAT?

Multiple Choice

An A2A service operator says an EAT for its sandbox process attests the legal identity of the operating company and must contain the same claims in every deployment.

A. The company is the EAT entity, because an entity always means the person or organization responsible for a service. B. The sandbox cannot be an entity unless it has certified hardware and a minimum resistance to physical attack. C. The EAT base standard mandates one universal claim set, so deployment profiles may change only the serialization. D. The sandbox can be the entity, not the company; a use-case profile selects claims and protection within the EAT framework.

**Explanation:** A: RFC 9711 Section 1.1 says entity in the EAT context never refers to a person or organization. It is the target system component. B: Section 1.1 includes an individual process as an entity and states that no minimum security level is required merely to be an entity. C: Sections 1.2 and 6 preserve flexibility: the base framework makes no claims universally mandatory, and profiles narrow the choices. D: Sections 1.1, 1.2, and 6 support both boundaries. Claims about a component do not by themselves attest its operator's legal identity. Decision rule: Name the attested component and its profile explicitly; do not extend component claims to an operator or infer a universal token format from the base EAT framework.

Q2: Which participant owns the final admission decision?

Multiple Choice

An attester sends EAT Evidence to a verifier. The verifier checks reference values and emits signed Attestation Results stating that approved software was measured. A relying party controls an A2A resource.

A. The attester, because signing Evidence also decides which relying-party resources the entity may access. B. The relying party, which evaluates authenticated Attestation Results under its local policy; the verifier owns appraisal of Evidence. C. The verifier, because a positive Attestation Result is a universal authorization command for every relying party. D. The EAT issuer registry, because registered claim names define the admission consequence of every claim.

**Explanation:** A: Evidence describes the target environment but does not grant resource access. The attester cannot choose every relying party's policy. B: RFC 9711 Section 1.3.1 says the verifier and its policy govern the relationship between Evidence and Attestation Results. The relying party consumes that result for its own decision. C: A verifier appraises Evidence, but the result's consequence depends on the relying party and use case. Positive appraisal is not universal authorization. D: Claim registration supplies names and semantics, not a resource-owner policy or admission decision. Decision rule: Attestation appraisal and authorization are separate decisions with different owners, inputs, and policies.

Q3: May the relying party infer the TEE debug state?

Multiple Choice

A device EAT reports dbgstat=disabled-fully-and-permanently at the top level. Its TEE appears as a submodule but has no dbgstat. Policy requires debug to be disabled for both device and TEE.

A. Yes, because every top-level entity claim automatically applies to all nested submodules. B. Yes, if the TEE uses the same manufacturer identifier, because common ownership creates claim inheritance. C. No; debug status has no inheritance, so the TEE needs its own applicable claim before the stated policy can pass. D. No, because EAT forbids debug-status claims in submodules and requires out-of-band inspection instead.

**Explanation:** A: RFC 9711 Section 4.2.9 explicitly says there is no inheritance for debug status across submodules. B: Manufacturer identity does not change the claim scope. Even a whole-device facility should be independently reported for each submodule. C: Section 4.2.9 supports this conclusion. Missing evidence cannot be replaced by the parent value when policy names both entities. D: Submodules can report dbgstat. In fact, Section 4.2.9 explains that independent reporting is how a receiver learns their state. Decision rule: Apply each claim to the entity or submodule that reports it; do not invent inheritance where the claim definition denies it.

Q4: Should this previously valid EAT be accepted now?

Multiple Choice

A verifier sends fresh challenge N2. The agent returns a correctly signed EAT containing eat_nonce N1 from yesterday's successful transaction, and every measurement still matches reference values.

A. Reject it for this transaction because signature and measurement validity do not establish freshness when the nonce does not match N2. B. Accept it because stable measurements make a nonce mismatch irrelevant until the software version changes. C. Accept it if N1 was random, because randomness makes a nonce valid for an unlimited number of later verifications. D. Reject it only if the EAT uses JSON, because freshness is mandatory for JWT EATs but optional for CWT EATs.

**Explanation:** A: RFC 9711 Sections 4.1 and 9.3 require a freshness mechanism. A stale challenge permits replay even when the old token remains cryptographically valid. B: Measurements answer a state question; freshness answers whether the evidence is current for this interaction. One cannot substitute for the other. C: Randomness helps unpredictability, but a verifier must bind and check the nonce for the transaction. Reuse destroys that binding. D: Section 9.3 requires freshness for all EAT use, independent of JSON/JWT or CBOR/CWT encoding. Decision rule: Verify authenticity, appraisal, and freshness independently; an old authentic token is still replayable evidence.

Q5: How should this cross-service UEID design be reviewed?

Multiple Choice

An agent sends the same stable UEID to every A2A service, including unauthenticated discovery endpoints. Those services do not need a global device identifier for their authorization rules.

A. Keep it because a globally unique UEID is privacy-preserving whenever the EAT signature is valid. B. Keep it because attestation claims are exempt from data minimization once a profile permits JWT or CWT. C. Hash the UEID without a relying-party context and send the same hash everywhere, which removes cross-service linkability. D. Suppress it where unnecessary or use a context-specific strategy, because the stable value enables correlation across relying parties.

**Explanation:** A: RFC 9711 Section 8.1 says UEID is usually not privacy-preserving precisely because tokens from one entity can be linked. B: Encoding and signature format do not remove privacy consequences. Section 8 recommends use-case-dependent privacy choices. C: A stable unsalted or globally identical hash remains a stable correlator. The context boundary must change the disclosed identifier. D: Sections 8 and 8.1 discuss suppression, permission, single-relying-party use, and derived identifiers for a specific authenticated relying party. Decision rule: Disclose an identifier only when the relying policy needs it, and scope stable identifiers to the smallest useful context.

Q6: Which checks are required at this A2A attestation boundary?

Multiple Choice

A gateway verifies an EAT and OAuth grant, checks a session-bound proof, then forwards only Attestation-Status: trusted to a backend. The backend owns the resource policy and cannot inspect the original EAT.

A. Accept the header whenever the EAT signature was valid; claim authenticity automatically establishes freshness, verifier policy, grant validity, session binding, and the backend decision. B. Define the EAT profile and freshness, verifier appraisal policy, protected provenance of the forwarded result, proof-to-session binding, grant checks, and backend authorization rule. C. Require the backend to parse the EAT but omit gateway-result protection, because direct claim access removes the need to authenticate who performed appraisal. D. Use only the OAuth grant at the backend, because a valid grant proves the EAT runtime state and makes separate session-proof and appraisal checks unnecessary.

**Explanation:** A: RFC 9711 Sections 6, 9.1, and 9.3 separate profile choices, claim trustworthiness, and freshness. A signature alone does not establish the other application guarantees. B: Sections 1.3.1 and 6 define the appraisal and profile boundaries; Sections 9.1 and 9.3 add trustworthiness and freshness. The other listed checks belong to the composed A2A authorization design. C: Direct Evidence access can support independent appraisal, but an unprotected decision result still lacks provenance if the backend relies on it. D: OAuth authorization and entity-state attestation answer different questions. Neither token transfers the other's guarantee by implication. Decision rule: The backend may trust a gateway appraisal, but the trust boundary, authenticated result, freshness, and independent authorization inputs must be explicit.

The Entity Attestation Token (EAT)

References (URLs)

Q1: Which statement correctly scopes this EAT?

Q2: Which participant owns the final admission decision?

Q3: May the relying party infer the TEE debug state?

Q4: Should this previously valid EAT be accepted now?

Q5: How should this cross-service UEID design be reviewed?

Q6: Which checks are required at this A2A attestation boundary?