Implement appid extension in WebAuthn?

[ikimonogakari]

Are we able to support the appid extension which is defined in WebAuthn?

To transfer from old U2F api to WebAuthn, we face the issue that both old appid and rpid exist. Is it possible to support this extension?

[dainnilsson]

This extension is already supported, see the U2FFido2Server class for reference: https://github.com/Yubico/python-fido2/blob/main/fido2/server.py#L387

[ikimonogakari]

Thank you for your reply.

AFAICT, that is the implementation on the server side, to help verify both U2F and FIDO2 signatures.
I am asking whether it is possible to support it on the client side?

In browsers, we normally make a single assertion call like this with WebAuthn to assert both rpid and originally registered appid.

await navigator.credentials.get({
  publicKey: {
    challenge: randomUint8ArrayFromServer,
    rpid: "example.com"
    allowCredentials: [{
      id: Uint8Array(credentialId),
      type: 'public-key',
      transports: ['usb'],
    }],
    timeout: 60000,
    extensions: {
      appid: "https://login.example.com/appid.json",
    }
  }
});

To achieve the same result using python-fido2, we need to call the get_assertion API twice, to ensure that both rpid and appid are asserted.

Is this your suggested approach to achieve this behavior described by WebAuthn?
Or do you think it will be better that python-fido2 can support this extension natively? If so, I am very happy to help implement that.

[dainnilsson]

Ah, sorry I misunderstood. You're correct, this extension is only implemented for the server-side. It's a little trickier to implement cleanly on the client as it is quite different from the other extensions in that it changes the logic of the command quite a bit. One reason we didn't implement this was also that we didn't see an immediate use case for it: Our assumption being that if you have existing U2F-credentials these are very likely to come from a browser-based client, and would likely only be used in a browser setting. Maybe this assumption doesn't hold up. Can you share a bit more about your use case and why you need the appId extension support on the client?

[ikimonogakari]

The issue is:

1. We have users with mixed registered key handles with both appid and rpid.
2. We want to log existing users in through command line applications with FIDO protected.
   We want to keep their registered security keys working without re-register them with rpid.

After I looked at the code, I do agree that it can be hard to implement this cleanly.