Spec text should define how to match against tt-keyword.

[otherdaniel]

Context: This issue raised against Chrome.

This spec defines the CSP keyword 'allow-duplicates'. The issue referenced above argues that this should be matched case-insensitively, because it's defined in an ABNF grammar, and CSP normatively references RFC 5234 which indeed says keywords should be parsed case-insensitively. I think the report is correct. This is how most other CSP keywords are treated in Chrome, and e.g. WebKit's Trusted Types implementation also parses it that way.

This spec, in , § 4.3.5. Should Trusted Type policy creation be blocked by Content Security Policy?, step 2.5, says:

If createdPolicyNames contains policyName and directive’s value does not contain a tt-keyword which is a match for a value 'allow-duplicates', set createViolation to true.

I initially read "match" as being a string-comparison, thus case-sensitive, thus 'allow-duplicates' != 'ALLOW_DUPLICATES' . But since it references tt-keyword, which is part of an RFC 5234-style grammar, it could also be read as being a case-insensitive comparision, thus 'allow-duplicates' == 'ALLOW_DUPLICATES'. I think the latter was actually meant, but it's actually under-specified. The easiest solution would probably be to link-ify "match" to point to an appropriate string comparison algorithm.

[annevk]

https://infra.spec.whatwg.org/#ascii-case-insensitive (or lowercase during parsing, that's generally nicer).