Emil Lundberg

A WebAuthn parameter for RPs to signal whether syncing keys is permissible was previously discussed in #969. That was closed with the note: >we believe this has been superseded by...

I think that @MeydanOzeri's proposal could be made phishing resistant if combined with ideas from our [recovery extension](https://github.com/w3c/webauthn/pull/1425). What's currently missing is that the user's private key be tied to...

Well, yeah, we're discussing possible technical solutions. Packaging for end users is important, yes, but premature at this point. But know that we do keep in mind that it needs...

Related: #1064

So if I understand this correctly, a `packed` format `AttObjForDevicePublicKey` would be constructed like this? ``` AttObjForDevicePublicKey = { sig: bstr, ; result of sign((clientDataHash || userCredentialId), devicePrivateKey) aaguid: bstr,...

Unrelated to my previous comment: I can't really see what's the benefit of the new device key. It is authorized on first use by a signature chain from an already-registered,...

But isn't that additional factor (the device-bound key) dependent on the initial factor (the synced key)? The RP cannot begin to trust the device-bound key without already trusting the synced...

@timcappalli @agl Ah, I see, thanks for explaining. So what I missed is that `dpk` is not dependent on `synced cred` alone, but on `synced cred + context` - and...

> ...(I'm also inclined to rename it, say, "cntx"). [...] Though, one could also argue that "scope" better reflects the connotations here: I think `ctx` is a pretty well established...

The point of this extension is not to signal that a credential is multi-device, it's to "extend" a multi-device credential with one or more hardware-bound keys that don't migrate to...