WebAuthn requestUserInfo -- easier account creation

[nsatragno]

The Chrome team proposes a set of additions to the WebAuthn API that will enable streamlining the account creation process. Developers who integrate the API will obtain a user identifier (like an email address), optionally a username, and a passkey. The design should be such that it can be readily extended to support verified emails.

In particular, we propose introducing a requestUserInfo set of options that can be used to request user identifiers to be returned alongside the passkey. The initial list would be an identifier (email or phone) and optionally, a name.

See the explainer for the design proposal.

[nsatragno]

Nina to

• split this proposal into two
• make it clear the autofilled attributes come from the UA and not the authenticator

[MasterKale]

This is an interesting proposal for me because there are aspects of it that can make usernameless into a really slick new account creation flow.

The current problem with usernameless is that user.name and user.displayName are required values when calling .create(), but if you don't know those because it's a new user you haven't collected that information from then you have to use a generated value for those and then, now, use signalCurrentUserDetails() afterwards to hopefully update the credential. Lots of opportunities for things to go wrong when orchestrating this flow. But if the value for user.name and user.displayName can be provided by the new user up front then that second step can be skipped entirely. This could hypothetically get new account creation down to two clicks and passkey account protections are taken care of.

That said, based on the explainer there's a lot of complexity that'd come with the proposed changes:

Handling existing accounts

Relying parties should try to avoid a situation where they call this API when the user already has an account, e.g. by using immediate mediation on page load. There is unfortunately no way around the fact they will need to handle the case where a user already has an account, and the browser just created a passkey for them.

Relying parties can detect this situation by comparing the user's identifier (email or phone number) with their user database on response. To remediate the situation, one option is to use the signal API to delete the passkey that was just created with signalUnknownCredential, then prompt the user to sign in with their preferred method.

Opting into this new behavior would also require opting into immediate mediation and use of signal APIs? That's a lot of implementation complexity for RPs and opportunities for abuse if an RP doesn't get every step implemented correctly.

The proposed changes to PublicKeyCredentialCreationOptions also represent new combinations of WebAuthn options that RP's need to make sure they're calling correctly. What should user.name and user.displayName be set to when requirePlatformBackupEligibleCredential is present? What if residentKey: "required" isn't also set? These are new potential footguns that make the already complex WebAuthn into something even trickier to make sense of. Not that I don't think these are worth discussing...

The one aspect I might push back on the most is the proposed addition of requirePlatformBackupEligibleCredential, in particular because it represents a stronger guarantee of the attributes of the credential:

Setting this field will give relying parties a guarantee that they can rely on just having the passkey for authentication.

We as a WG have seen many attempts in the past to add stricter authenticator selection rules for the sake of RPs wanting to pre-select authenticators with desired capabilities (device-bound-only, synced-only, etc...) for more predictable browser-side UX. Over time we've designed things like Hints that are suggestions more than requirements because we've seemingly collectively agreed that WebAuthn should continue it's "bring your authenticator" user-centric model of operation. A new entry in authenticatorSelection with a guaranteed outcome like what's described in the explainer would require re-litigating those past discussions and likely come to the same outcome (i.e. it would get shot down.)

To reiterate, I think this proposal is worth further discussion. I do support breaking this up into two proposals, though, so that the fate one of part of the proposal won't necessarily determine the fate of the other.

[MasterKale]

I want to also toss out the idea that WebAuthn extensions are pretty flexible, and might offer some alternative paths towards requesting name and email collection without major changes to overall options that get passed into .create() 🤔

[nsatragno]

I've split my proposal into two:

• https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-requestUserInfo (this issue)
• https://github.com/w3c/webauthn/wiki/Explainer:requirePlatformBackupEligibleCredential (WebAuthn requirePlatformBackupEligibleCredential #2342)

I tried addressing the comments on the explainer. Unfortunately, GitHub issues don't lend themselves very well for proposal discussion, so I'll also try to comment here:

The current problem with usernameless is that user.name and user.displayName are required values when calling .create()

user.name and user.displayName will be filled in by the browser from the identifier the uses chooses. They don't need to be supplied by the relying party, I agree that would be absurd.

Opting into this new behavior would also require opting into immediate mediation and use of signal APIs?

Immediate mediation would not be required, but it would pair nicely. Like a tira de asado and malbec. The signal API is really simple to implement, and relying parties should be doing that regardless of whether they implement this API or not. I don't think in the grand scheme of things this is that complicated, but I may be biased.

What if residentKey: "required" isn't also set? T

Same as residentKey not set for platform authenticators. It's considered "required", except on Android where we do something very unintuitive and already have a footgun. I don't think this proposal introduces any footguns, but let me know if you spot one.

We as a WG have seen many attempts in the past to add stricter authenticator selection rules for the sake of RPs wanting to pre-select authenticators with desired capabilities...

I think on the surface this seems similar to previous attempts to restrict authenticator selection to those that produce device-bound credentials. However, the fact we're going the other way completely changes the trade-offs: it's the same direction authenticators are moving. I wrote some of my thoughts on the explainer.

[emlun]

From the explainer:

Attributes will be returned as an object with a mandatory value field. In the future, these can be augmented with verification signals.

userInfo: {
  identifier: {
    type: "email",
    value: "marisa@gmail.com",
  },
  attributes: {
    name: {
      value: "Marisa Kirisame",
    },
  }
},

It might be appropriate to include some language and/or direction fields for some of these. I could certainly see at least direction being relevant for name values that may be written in different scripts:

attributes: {
  name: {
    value: "هذا المثال باللغة العربية",
    dir: "rtl"
  },
}

[nsatragno]

Agreed, let's add language & direction to name. Probably not for email or phone number since those seem non localizable.

Added to the explainer.

[nsatragno]

Thank you all for the feedback. I've updated my proposal to remove the requirement to sync, opening this to all authenticators.

Looking forward to further discussing in person at TPAC.