Tim Cappalli

> Alternatively an RP could simply detect `be:0` and naively make another call to `.create()` with the same user ID and check `be` flag in the registration response. That wouldn't...

Please use [email protected] (register here: https://groups.google.com/a/fidoalliance.org/g/fido-dev) for implementation discussions. This repo is for the WebAuthn specification itself.

I like this pattern. It would also allow for future use of WebAuthn credentials for ephemeral session binding across devices (cross-device wallet use cases).

2022-06-09 - during F2F, general consensus that allowing this at the spec level is a good idea.

@emlun the device key is more of a signal to the RP. For example, some RPs may require another factor when a synced key is used for the first time...

@emlun, correct. The goal is to have a hardware bound "signal" that the synced key is being asserted from a new device/context. An RP may or may not take different...

@equalsJeffH, there may be situations in the future where it is important to differentiate between `app` and `browser` and even additional contexts like `wallet`. It is much easier to add...

@dwaite regarding # 3: today, when a platform authenticator is registered as a "trusted device" for step up or subsequent sign ins, it is ultimately a trusted app/browser, not trusted...

Please use [email protected] (register here: https://groups.google.com/a/fidoalliance.org/g/fido-dev) for implementation discussions. This repo is for the WebAuthn specification itself.

@kevvurs this sounds like an implementation discussion so I would discuss this issue on the FIDO-DEV list or in the WebAuthn Community Adoption Group. There are no current plans to...