RFC 7517 Quiz (EN)

**Judgment point:** A JWK carries key material and key-related metadata, but acceptance still depends on how the key was obtained and what policy allows. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: Authorization policy is decided by OAuth, application rules, or local trust policy, not by the JWK format alone. - B: JWK is the JSON representation used by JOSE-family protocols, so it is the correct center of this RFC. - C: A kid value helps select a candidate key, but it is not a trust decision and is not globally unique.

**Judgment point:** A JWKS is useful only after the deployment defines where it came from, who controls it, and which keys are acceptable for the current use. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: Source and issuer checks are required because a JSON key set by itself does not prove who is allowed to sign. - B: Blindly trusting every key in a JWKS can let a wrong issuer or wrong use case pass validation. - C: Public JWKS documents should not expose private or symmetric key material because that changes a verifier aid into a secret leak. - D: The alg member can be a constraint or hint, but the verifier still needs an allow-list and profile rules.

**Judgment point:** The kty member selects the key type. It tells an implementation which key-specific members must be parsed before cryptographic use. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: User identity is usually carried by certificates, claims, or deployment policy, not by kty. - B: OAuth scope is token policy and is not determined by the key type field. - C: kty selects the key family, so it controls which members such as RSA modulus/exponent or EC curve coordinates are required.

**Judgment point:** Key selection and key trust are separate steps. A matching key identifier narrows the candidate set, then policy and cryptographic checks decide acceptance. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: This keeps kid in its proper role as a lookup hint and preserves the later validation steps. - B: Overriding issuer validation turns a convenience identifier into an authorization mechanism. - C: The RFC does not make kid globally unique, so collisions or reuse across issuers must be handled.

**Judgment point:** A sound verifier does not let the key set decide the entire acceptance result. It combines trusted discovery, candidate selection, cryptographic validation, and application policy. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: The first key is arbitrary and trying algorithms broadly creates algorithm-confusion risk. - B: This path separates discovery, selection, signature verification, and policy checks, which is the safe use of JWKS. - C: Well-formed key material is not proof that the right issuer or key owner was involved.

**Judgment point:** Key metadata helps avoid misuse, but only a profile or verifier policy can say how strictly each member is enforced. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: Key metadata is not a resource authorization grant and cannot replace policy. - B: Profiles should say whether use, key_ops, and alg are mandatory constraints or advisory fields. - C: Local algorithm policy must not be bypassed by an attacker-controlled or issuer-provided header. - D: Inconsistency needs a deterministic handling rule so implementations do not accept different objects.

**Judgment point:** A JWK can represent public, private, or symmetric material. The JSON format does not reduce the sensitivity of the contained key. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: Putting secret key members in a public JWKS exposes the material needed to impersonate or decrypt. - B: JSON is only an encoding, so it does not make secret material safe. - C: Secret material remains secret even when encoded as JWK and must be protected accordingly.

**Judgment point:** Certificate-related JWK members can connect a key to certificate material, but the verifier still has to validate the certificate path and intended use. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: This is the careful path because it treats x5c as input to validation rather than a shortcut. - B: Automatic trust would skip path validation, name constraints, and usage policy. - C: Matching the certificate public key to the JWK is a necessary consistency check, not something to avoid.

**Judgment point:** Key rotation is normal, but it must not make verifiers accept unknown keys or ambiguous identifiers. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: An overlap window lets existing tokens validate while new tokens move to the new key. - B: Reusing kid for unrelated keys makes selection ambiguous and can select the wrong material. - C: A backup algorithm fallback can turn rotation into an algorithm or key-confusion bug. - D: Failing closed preserves security when the verifier cannot find a trustworthy candidate key.

**Judgment point:** The absence of an acceptable key is a validation failure for the current path. Claims are not trustworthy until the protection is validated. **Related keywords:** - **JWK** : JSON representation of a cryptographic key - **JWKS** : JSON set used to publish multiple keys - **kid** : Key identifier used only as a selection hint **Options:** - A: Reachability of a JWKS endpoint is not equivalent to a valid signature or trusted issuer. - B: Rejecting preserves fail-closed behavior and leaves room only for an explicitly defined alternate path. - C: Payload claims are attacker-controlled until the signature and policy checks succeed.