RFC 7800 Quiz (EN)

**Judgment point:** Separate the role of JWT confirmation key from nearby security functions and policy decisions. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: turning every JWT into a non-transferable token without a separate proof step is not the central purpose of RFC 7800. It can be nearby work, but it is not the decision this RFC primarily supports. - B: expressing that a JWT is intended to be used by a party that can prove possession of a specific key is the reason this RFC belongs in the review path. It drives checks on inputs, validation, and boundaries. - C: deciding what resource action the holder is allowed to perform is outside the RFC boundary. Higher-layer policy and adjacent protocol responsibilities still need separate text.

**Judgment point:** JWT confirmation key is a building block. Acceptance conditions, authorization, and deployment exceptions must still be explicit. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: which proof mechanism, key distribution method, and authorization policy are acceptable is not decided by the RFC alone. The relying application must say what success means. - B: Skipping local acceptance policy can accept a valid object in the wrong context. That crosses the RFC boundary. - C: verify the JWT and then verify a holder proof that matches the key identified by cnf is a boundary the implementation review must preserve. Source and scope mistakes cause false acceptance. - D: An RFC citation can be necessary, but deployment configuration, keys, trust, and failure handling are not automatic.

**Judgment point:** A profile is the contract that makes use of JWT confirmation key consistent across implementations. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: If input bytes and context are free-form, implementations verify different values. - B: Human-readable text is useful for explanation, but it is unstable as a validation input. Locale and wording changes break it. - C: include a confirmation claim that unambiguously identifies the proof-of-possession key is required. Clear producer rules let verifiers evaluate the same object under the same assumptions.

**Judgment point:** Interoperability failures appear when the same wire data receives different processing meanings. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: validating the token signature but never checking that the presenter controls the cnf key shifts the validation target or meaning. Implementations can then disagree about success. - B: Limiting BCP 14 words to real requirements reduces ambiguity rather than creating it. - C: Documenting unsupported-extension behavior reduces implementation divergence.

**Judgment point:** JWT confirmation key needs validation against its defined inputs and scope, not just its delivery path. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: HTTPS protects transport, but it does not replace validation of JWT confirmation key. - B: verify the JWT and then verify a holder proof that matches the key identified by cnf is the central step. It separates well-formed input from acceptable input. - C: A filename or path can be a routing hint, but it is not enough as identity or security proof.

**Judgment point:** A specification can define processing rules while still leaving acceptance policy outside the mechanism. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: the cnf claim and confirmation methods that identify a holder key is part of the mechanism RFC 7800 addresses directly. It is not the policy layer. - B: which proof mechanism, key distribution method, and authorization policy are acceptable is an application or deployment acceptance condition. - C: Well-formed syntax and algorithm processing belong to the RFC-defined side. The meaning of success still needs policy. - D: how the holder proof is transported with the protected request is local policy. It should be written for the deployment and threat model.

**Judgment point:** A security review looks for false-acceptance paths, not just whether the mechanism is present. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: Performance can matter, but caching does not replace a security property. - B: A recent library helps, but local policy, inputs, and threat model still need review. - C: treating a cnf claim as useful while still accepting the token as a bearer token is the central failure mode. Attackers exploit this kind of context or trust shift.

**Judgment point:** Adjacent specifications are usually safer to read as layered responsibilities, not automatic replacements. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: RFC 9449 applies proof of possession to OAuth DPoP requests, while RFC 7800 defines JWT confirmation key semantics preserves the responsibility split. - B: Obsoletion is explicit in RFC metadata and text. Nearby concepts do not automatically replace one another. - C: JWT confirmation key matters in protocol composition reviews. Treating it as unrelated hides boundaries.

**Judgment point:** Review questions should show whether implementers can reproduce the same success and failure boundary. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: Naming inputs, context, validation rules, and rejection behavior directly reduces implementation differences. - B: An RFC number does not define local semantics by itself. A profile or policy must fill the gap. - C: Treating unknown values as success can accept extensions or attacker input incorrectly. - D: when a token must be sender-constrained instead of usable by whoever copies it is a real review setting. Fixing success conditions there reduces misuse.

**Judgment point:** Validation failure is a signal to stop using that input as evidence for the decision. **Related keywords:** - **cnf**: Confirmation claim - **holder key**: Key controlled by the presenter - **PoP**: Proof of possession **Options:** - A: Downgrading to a warning creates fail-open behavior. Attacker-controlled input can enter the success path. - B: Treating the result as unusable for that decision is safe. If fallback exists, it needs explicit policy. - C: Authorization is important, but it does not automatically repair broken validation input.