Re: [webauthn] Non-modal registration during conditional assertion (#1929)

I finally had a chance to give the Explainer a good look. Looking at this first example in the Explainer...

```
const assertionOrRegistration = await navigator.credentials.get({
  mediation: 'conditional'
  publicKey: {
    challenge: ...,
    extensions: {
      conditionalRegistration: () => {
        challenge: ...,
        user: ...,
        rp: ...,
        authenticatorSelection: {
          residentKey: "preferred",
        },
      }
    },
  }
});
```

> Perhaps the creation options could be provided by a callback.

Is this intended to be the single conditional mediation request initiated on page load to also support use of browser autofill for users with passkeys? If so, I can't see how the shape of this first proposed API could support both auth and registration, because when would `conditionalRegistration` get executed? It has to happen **after** username and password submission, but guidance on the bootstraping of conditional mediation has been to make the conditonal `.get()` request on page load, **before** the user ever sees UI to enter a username and password. It's unclear to me right now how the initial authentication could happen for the RP to be able to then specify a valid user ID and username in the return value for `conditionalRegistration`.

> Because the website had an ongoing conditional mediation assertion with this extension set, the user agent choses to automatically create a passkey for the account.

How does this technique hold up e.g. hard page reloads for server-rendered sites? I can see how a Single-Page App would be able to maintain context of a conditional mediation request being in-flight if username + password are submitted as a `fetch` request. But if a typical server-rendered site does a typical `<form>` submission on username + password submission then that context is lost. It sounds like a lot of technical complexity for browsers to implement something to keep track of the fact that "conditional mediation w/conditional registration" was launched on **username-entry.html**, but then the user is redirected to **success.html** after submitting a valid username + password. Would the RP need to re-call `.get()` on **success.html** for the new passkey to get silently created?

> Potential alternative (Separate create call)

The more I think about all of this, the more I think I like the idea of the split APIs. Whether SPA or server-rendered, both can call conditional mediation in the usual manner, plus the new extension:

```
const registration = await navigator.credentials.get({
  mediation: 'conditional'
  publicKey: {
    ...
    extensions: {
      conditionalCreate: true,
    },
  },
});
```

Then, whether the SPA keeps the page context or the page does a hard reload, a conditional `.create()` can get called:

```
const registration = await navigator.credentials.create({
  mediation: 'conditional'
  publicKey: {
    challenge: ...,
    user: ...,
    rp: ...,
  },
});
```

I like the fact that with this model the developer would only need to add (the same) `mediation: 'conditional'` property to an otherwise typical `.create()` call. And since the user would have to properly authenticate for the RP to then make the conditional registration call, I think it's easier for an RP dev to mentally map how to specify proper values for `user.id`, `user.name`, etc... 

And from a browser maintainer perspective, it seems it might be easier to keep track of the `conditionalCreate` extension/flag being set even across hard page reloads, to then reset the flag the next time a the conditional `.create()` request is made...

I want to be clear that I think, at a high level, I like this proposal. My questions above are aiming to figure out what might be the best developer experience that'll remove as many footguns from this new capability if it gains wider support.

-- 
GitHub Notification of comment by MasterKale
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1929#issuecomment-1677743241 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 14 August 2023 17:19:26 UTC