RFC 7515 クイズ

**解説:** A: coverされるのはJWS signing inputであり任意のenclosing dataではない. B: signatureまたはMACはprotected-headerとpayloadのrepresentationに対して計算する. C: cryptographic integrityだけではapplication claimを受理してよいか決まらない.

**解説:** A: Protected Headerのbyteはsigning inputに含まれる. B: Unprotected Header parameterはintegrity protectedではない. C: outer objectはapplicationがsigned payloadへ明示的に含めない限りcoverされない.

**解説:** A: key identifierだけではownershipやtrustを確立しない. B: algorithm policyとkey identificationは別のdecisionである. C: RFC 7515はkidをhintと定義しstructureをspecifiedしない.

**解説:** A: RFC 7515はalgorithmがapplicationにacceptableであることを要求する. B: JWSはcryptographic validationとapplication acceptance checkの両方を通って初めてvalidになる. C: key hintはdisallowed algorithmをauthorizeしない.

**解説:** A: critでnamedされた全parameterを理解し処理する必要がある. B: unknown critical parameterのignoreはcritの目的を損なう. C: verifierはsigning inputを壊さずsenderのprotected headerを書換えられない.

**解説:** A: Compact SerializationにはJWS Unprotected Headerがない. B: multiple signatureはgeneral JSON serializationが提供する. C: これらはcompact formではなくJWS JSON serializationのcapabilityである.

**解説:** A: RFC 7515は少なくとも1つを要求するがapplicationは特定または複数signatureを要求できる. B: どのsignature valueをvalidate必須にするかapplicationが決めbase minimumより増やせる. C: array positionはapplicationのsigner policyを定義しない.

**解説:** A: RFC 7515はintegrity-protectedな取得とTLS server identity validationを要求する. B: hintのmatchだけではtrusted key sourceを確立しない. C: attacker-controlled key sourceならmatching keyとsignatureを提供できる.

**解説:** A: これはsuccessful validationのcore cryptographic resultである. B: Protected Header contentはsigning inputに参加する. C: authority, issuer binding, audience, freshnessにはapplication-profile ruleが必要である.

**解説:** A: 独自のinferenceは非互換でunsafeなacceptance decisionを生む. B: JWSはcryptographic containerを提供しapplication profileがacceptance semanticsを定義する. C: JWS validityはcross-resource authorizationをgrantしない.