Shane Weeden

I'll try articulate in my own words the requirement I raised in the F2F: As an enterprise RP, I would like a way to signal to the browser during a...

> Wouldn't DPK support (PR#1663) be sufficient? Essentially not preventing the multi-device key, but ensuring an additional single-device key being established *per device*. I think so however it would have...

> The debate (or at least a significant part of it) is whether this is a power we want to give to RPs. Yes please. > The TAG recommends that...

In the June 29 meeting the question was asked as to why the current DPK proposal is insufficient and why RPs are requesting the ability to indicate more stringent requirements...

From an RP consumability perspective I think this is an excellent idea. Minor nits: - In the createOpts example, user.id should be shown as a B64URL input example data rather...

> They can, however, request a second device-specific, hardware bound key and ignore the passkey, if they have a use case that requires this (and results in a degradation of...

> @sbweeden But nothing can be truly asserted or trusted from the initial makeCred, you can only trust things that are signed in the response from the attestation. So it's...

@ChadKillingsworth Can you please clarify what the ask is (if any) from your perspective? I noticed you said that you want to favour selection by attachment, which is available today...

I would have thought you could indicate this with: ``` navigator.credentials.create({ publicKey: { challenge: new Uint8Array([/* bytes sent from the server */]), authenticatorSelection: { "authenticatorAttachment": "platform" "userVerification": "required" /* or...

Ok - you are looking at assertion options. This github issue started on the topic of attestation options (credential creation), which uses [PublicKeyCredentialCreationOptions](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptions).