The combination check added in bug 310788 (PR #62231) only validates publicKey/digital combinations. It does not correctly handle combinations involving password, federated, identity, or otp. Per https://github.com/w3c/webappsec-credential-management/pull/261, the registry defines "Types allowed in the same get() request": digital → empty (cannot mix with any other type) federated → password only identity → empty otp → empty password → federated only publicKey → empty The spec algorithm says (verbatim): "If |type1|'s types allowed in the same get() request doesn't contain |type2|, then return a promise rejected with a NotSupportedError DOMException." Current bugs: 1. { publicKey: {...}, password: true } — should NotSupportedError, but currently passes and silently ignores password. 2. { digital: {...}, password: true } — same problem. 3. { password: true, federated: {...} } — valid combo per spec, but we reject with "Missing request type" since we only look for publicKey/digital. 4. { password: true } alone — valid (if unimplemented) type, but we reject with "Missing request type". Fix: validate all combinations against the registry table. For unimplemented types (password, federated, identity, otp), return null rather than "Missing request type".