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

Notes, mostly for myself so that I remember things during any discussion today:

The explainer currently envisions putting the creation options inside an extension in a conditional(?) get request. That could either be done by forking the creation options (which would then have to be kept in sync and would be quite a lot of IDL) or else by referencing the existing creation options. But the existing options include their own extensions block, and [the same IDL object](https://www.w3.org/TR/webauthn-2/#dictdef-authenticationextensionsclientinputs) is used for both creation and assertion, thus that would be a recursive IDL object.

Alternatively one could imagine allowing concurrent conditional get and create requests, although that would require tweaking some other logic to allow multiple concurrent requests.

Next, creating a credential requires specifying things like the user.name, user.displayName, and user.id. But if the site has to set the creation parameters at the time of making a conditional get request, it probably doesn't know who the user is. So how can it set those values? While user.name could be taken from the password-based account that the user used, and not all systems use user.displayName, user.id seems thorny.

Lastly, signing in often navigates the page, which aborts all outstanding conditional requests. It might be a little complex for sites to sequence things so that the registration isn't truncated by the navigation and lost.

This is all making me wonder whether a conditional create shouldn't be allowed for a short time after an autofilled sign-in, as a separate request.

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


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

Received on Wednesday, 26 July 2023 13:32:50 UTC