Comments (9)
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.
from webauthn.
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
anddefault-backup-state
be a setting onAddVirtualAuthenticator
. This lets you test what happens for various values when creating a credential. - Add
backup-eligibility
andbackup-state
toAddCredential
, 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.
from webauthn.
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.
from webauthn.
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.
from webauthn.
from webauthn.
19871987
from webauthn.
1987
from webauthn.
from webauthn.
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.
from webauthn.
Related Issues (20)
- Support NoCredentialsError and UserCancelledError codes HOT 13
- Authenticator data flags reserved bits must be 0 or the figures would ideally be changed HOT 5
- ยง6.1. Steps to generate authenticator data should include BE and BS flags HOT 3
- Make AuthenticatorAttestationResponseJSON.publicKeyAlgorithm a long HOT 2
- Make PublicKeyCredentialRequestOptions.rpId a DOMString HOT 3
- Provide a mechanism to indicate backend registration success or failure HOT 8
- Empty strings are not valid RFC 8266 Nicknames HOT 2
- Remove the UVM extension from WebAuthn L3 (potentially) HOT 5
- Resident key removal HOT 1
- Support for WebDriver BiDi HOT 2
- supplementalPubKeys attestation incompatible with most verification procedures
- Does WebAuthn supports User-Verifying Roaming Authenticators HOT 4
- How does First-factor roaming authenticator registration happens with RP (involving client) HOT 2
- CredentialCreationOptions/mediation not yet defined in CredMan HOT 1
- Authenticator Attestation Response's [[transports]] should be an attribute rather than an internal slot. HOT 4
- Align the order of fields in PublicKeyCredentialDescriptorJSON with PublicKeyCredentialDescriptor HOT 3
- Dictionary members should be ordered lexicographically per Web IDL Standard HOT 3
- Allow conditional mediation flow without username or password field, I.E. from button press HOT 4
- Add support for hinting at verbiage other than "sign in" during authentication HOT 5
- Add support for IDNs and display domain names in Unicode for a more user friendly UX HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webauthn.