Virtual Authenticator API does not expose a way to set backup-eligible or backup-status flags about webauthn

[james-d-elliott]

It may also be advisable considering this is intended for E2E tests to be able to change the BE flag AFTER the credential is created. I think being able to test the fact a change to the BE flag results in an error in integration and that the error looks appropriate is desirable.

[nsatragno]

If we put only the option on AddCredential, then how would you test your website's behaviour on credential creation?

Here's a proposal:

• Have backup-eligibility and default-backup-state be a setting on AddVirtualAuthenticator. This lets you test what happens for various values when creating a credential.
• Add backup-eligibility and backup-state to AddCredential, which lets you test assertions.
• Add a Set Backup State method to avoid having to recreate a credential.
  I'm not a fan of the remove-and-add proposal because if we add more state to the credentials, then the developer has to make sure they update all the places where they do this if they want to get the exact same credential when they update their e2e testing browser. Or worse: if your webdriver version drifts from your browser version, it might be impossible to recreate the same credential, since the old webdriver might not know about new state.

[emlun]

I think the Add Credential API call would be the be more appropriate place for these, but I agree otherwise.

I also don't think we need to define any new operations to enable changing bs between assertions - since Add Credential includes all credential state (including the private key and signature counter), the caller can "update" bs by first calling Remove Credential and then calling Add Credential with the new bs value.

[MasterKale]

I think the Add Credential API call would be the be more appropriate place for these, but I agree otherwise.

I honestly agree with you, as be and bs are definitely credential properties vs authenticator properties. However the current means of manipulating flags in authData are centralized in the Add Virtual Authenticator API call as isUserConsenting and isUserVerified so that's why I suggested the authenticator API instead...

Actually no, now I agree 100%, the means of specifying be and bs for a credential should be on Add Credential.

...the caller can "update" bs by first calling Remove Credential and then calling Add Credential with the new bs value.

I think I can get behind this, but we do have precedent for an "update" API Set User Verified. Maybe we can add a similar "Set Backup Status" API for individual credentials.

[agl]

@nsatragno

[fwadnjar]

19871987

[fwadnjar]

1987

[fwadnjar]

[email protected]

[MasterKale]

This is still on my radar, I just couldn't get a draft up in time for tomorrow's WAWG meeting. I'll aim for next week's meeting instead.