Enum values that ignore naming conventions in Web Authentication: An API for accessing Public Key Credentials - Level 3

[dontcallmedom-bot]

While crawling Web Authentication: An API for accessing Public Key Credentials - Level 3, the following enum values were found to ignore naming conventions (lower case, hyphen separated words):

• The value "conditionalGet" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)
• The value "signalAllAcceptedCredentials" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)
• The value "hybridTransport" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)
• The value "passkeyPlatformAuthenticator" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)
• The value "conditionalCreate" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)
• The value "userVerifyingPlatformAuthenticator" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)
• The value "relatedOrigins" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)
• The value "signalUnknownCredential" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)
• The value "signalCurrentUserDetails" of the enum ClientCapability does not match the expected conventions (lower case, hyphen separated words)

See Use casing rules consistent with existing APIs in Web Platform Design Principles document for guidance.

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

[emlun]

These enum values use a different naming convention because they are used as keys in the record returned by getClientCapabilities(). These names enable using them as bare identifiers (capabilities.conditionalCreate or { conditionalCreate: true }) instead of having to use index notation (capabilities["conditional-create"]) or quoted keys ({ "conditional-create": true }).

The proposed naming convention was used at earlier points in #1923 but were later changed to improve developer ergonomics.

[MasterKale]

Closing out as we have well-reasoned justification for ignoring kebab-casing in capabilities.