Javascript Chrome是否忽略WebAuthentication userVerification设置""

更新

所以最初的答案是正确的，这是如何工作的，但我忘记了一部分，因为我做的大部分是CTAP而不是WebAuthn.虽然WebAuthn根本没有涵盖CredProtect，但MDMAPI实现通过扩展，更具体地说是credentialProtectionPolicy.

这将允许您手动将credProtect设置为请求的级别1，这将允许您使用该凭据来执行没有userVerification的断言.

当你用JavaScript标记了问题时，我假设你正在做这个直到navigator.credentials.create(options)，然后请求将需要包括

extensions: {
  credentialProtectionPolicy: "userVerificationOptional"
}

在选项对象内.然后，Chrome将尊重CredProtect级别并将其设置为1，同时根据通常的请求将RK设置为true.这是不可能在www.example.com上进行测试，但你可以在Auth0's test implementation上进行测试

原始应答

Chrome实现Webauthn的方式与Firefox实现Webauthn的方式有细微的差别.

{
  1 => <Buffer 34 9d 9d c8 ef 9a c9 36 b3 3c dd f9 54 aa 57 b4 b1 f0 52 dd c5 7f 86 2e 37 9e ff b4 57 f7 48 57>,
  2 => {
    id: 'webauthn.io',
    name: 'webauthn.io'
  },
  3 => {
    displayName: 'abcde',
    id: <Buffer 58 4c 54 67 73 77 4e 6a 37 34 5f 49 62 4d 75 68 67 47 74 43 5a 4c 6f 67 55 48 50 72 63 4d 49 4c 51 45 72 78 77 73 64 37 35 48 51>,
    name: 'abcde'
  },
  4 => [
    {
      alg: -7,
      type: 'public-key'
    },
    {
      alg: -257,
      type: 'public-key'
    }
  ],
  7 => {
    rk: true
  },
  8 => <Buffer c3 3b a4 9b 74 06 ae e8 76 df 66 a7 57 4e 6b 00 a9 a2 00 e4 ce 40 a4 d4 89 40 06 92 bd a2 80 10>,
  9 => 2
}

如图所示，这个请求包含了您所期望的，请求本身有rk = true个，这将在设备上创建一个可删除的凭证.请求有一个令牌，但这只会影响我们的创建，而不会影响后来的断言.

如果我在Chrome中提出同样的请求，我会得到以下请求:

{
  1 => <Buffer b9 da 62 ad 82 89 4d 87 c8 8c b2 e0 a2 2d 74 23 ef a2 af 04 a9 16 06 76 d6 c4 13 c0 08 04 fa 19>,
  2 => {
    id: 'webauthn.io',
    name: 'webauthn.io'
  },
  3 => {
    displayName: 'Testsetesrsdr',
    id: <Buffer 45 37 4b 4c 76 50 48 59 46 4d 42 7a 5a 5a 75 48 6f 6d 31 4f 65 6f 43 33 68 41 5f 70 44 68 73 57 56 53 45 48 32 41 39 57 71 79 4d>,
    name: 'Testsetesrsdr'
  },
  4 => [
    {
      alg: -7,
      type: 'public-key'
    },
    {
      alg: -257,
      type: 'public-key'
    }
  ],
  6 => {
    credProtect: 2
  },
  7 => {
    rk: true
  },
  8 => <Buffer 1d df 5a dc 36 8b 59 92 95 dd 07 32 c5 8b 1d e8 64 57 c1 e2 b0 67 54 22 b1 7b 50 24 b3 4d 3f 05>,
  9 => 2
}

几乎相同的请求，rk在这里也是真的，但有一个关键的区别.Chrome为key 6添加了一个值，即credProtect: 2.在CTAP中，CredProtection Level 2被定义为userVerificationOptionalWithCredentialIDList，这意味着密钥只能通过某种用户验证(在您的情况下，PIN)或通过将其包含在allowList中才可被解密.More info on CredProtect

我强烈怀疑这是Chrome中的一个bug，但实际上Chrome已经决定将其作为其实现的一部分.Webauthn本身几乎没有覆盖任何关于CredProtect的内容，所以这个决定也不会影响他们对规范的一致性.

如果这是正确的方式，Chrome将变得非常基于意见，并且它不一定是正确的方式，因为向请求提供allowList会带来很多隐私问题，其中许多问题都在webAuthn中涵盖，特别是第14.6.3章.

所以，除非Chrome改变，我对此表示怀疑，否则你唯一的 Select 就是维护和供应allowList或举办UserVerification仪式.然而，通过Firefox生成的密钥可能没有任何一个，因为CTAP中的CredProtect默认值是1.它可以在Chrome或Firefox上获得.