RFC 7638 Quiz (EN)

**Judgment point:** The RFC defines a stable way to compute a key identifier from a JWK. It does not decide who may use the key. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: Authorization is outside the thumbprint calculation and still belongs to token or application policy. - B: The deterministic digest over selected public JWK members is the core purpose of this RFC. - C: A JWK thumbprint is computed from a JWK representation, not from an X.509 certificate object.

**Judgment point:** A thumbprint must be stable across metadata changes, so only the required public members for the key type are included. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: Required public members define the key material being identified. - B: Private material and deployment metadata would make the identifier unsafe or unstable. - C: Canonical JSON is needed so different serializers hash the same byte sequence. - D: kid, use, and alg are metadata and are intentionally not part of the thumbprint input.

**Judgment point:** Without canonicalization, two equivalent JWKs could produce different hash inputs. The RFC avoids that interop failure. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: Human formatting is not a stable cryptographic input. - B: Optional metadata should not change the thumbprint for the same key. - C: Fixed selection and ordering make the hash input deterministic across implementations.

**Judgment point:** The thumbprint identifies key material in JWK form. Certificate trust and authorization remain separate decisions. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: This distinction is essential because the object being hashed is the JWK representation. - B: Certificate path validation is not performed by the JWK thumbprint algorithm. - C: A digest can identify a key, but it does not authorize a request by itself.

**Judgment point:** Thumbprint comparison is one step inside a larger proof and token validation flow. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: Syntax alone does not prove possession of the corresponding private key. - B: This compares the expected key identity with the key actually presented in the proof path. - C: A confirmation value must be matched to a valid proof, not treated as proof by itself.

**Judgment point:** Thumbprints are useful identifiers. They become security-relevant only when a profile defines how to compute, compare, and validate them. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: Access control still requires token validation and application policy. - B: Profiles need exact comparison rules so producer and verifier compute the same value. - C: kid is not included in the thumbprint input, so changing it should not change the thumbprint. - D: The thumbprint can bind a reference to a key while leaving trust and authorization to other checks.

**Judgment point:** The thumbprint is intended to represent the key, not every local metadata label attached to the key. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: The RFC does not hash every JWK member. - B: Changing optional metadata is not a reason for the key thumbprint itself to become invalid. - C: Because kid and use are outside the selected input, the thumbprint remains stable for the same public key.

**Judgment point:** Equality of thumbprints relies on collision resistance for the selected hash. It still does not replace token context checks. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: Collision resistance is the relevant cryptographic property for a digest-based identifier. - B: Issuer and audience checks protect a different boundary and must remain. - C: A thumbprint normally identifies public key material and should not be handled as a secret.

**Judgment point:** The point of the RFC is that independent implementations compute the same identifier for the same key. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: Using the same selected public members is required for a shared result. - B: Original source text may contain different whitespace or ordering, so hashing it breaks interoperability. - C: Extension members would make the identifier deployment-dependent and unstable. - D: The same serialization and byte rules make the hash input identical.

**Judgment point:** No matching thumbprint means the key identity check did not succeed. Falling back to weaker identifiers defeats the binding. **Related keywords:** - **thumbprint** : Stable digest of selected public JWK members - **canonical form** : Exact JSON form used before hashing - **jkt** : DPoP confirmation value based on a JWK thumbprint **Options:** - A: kid is weaker and unrelated to the thumbprint comparison boundary. - B: Failing the decision preserves the binding semantics. - C: A plausible payload cannot replace the cryptographic key identity check.