Meeting minutes
Discussing https://
Email waiting for Tim to respond
Discussing https://
(scribing of remaining open PRs lost due to tech issues)
(scribing picking back up with hopefully technical issues resolved)
https://
nsteele: Any updates?
Shane_Weeden: No; intention was to try and close differences in autofill behavior between Chrome and Safari, in the spec
agl: Chrome and Safari have now harmonized?
Shane_Weeden: Yes, but we need to spec that for future implementors
agl: Will mention it to Nina
https://
matthewmiller: Still valid, will get it to it at some point
https://
agl: Still open, not sure we'll get it to it anytime soon
https://
https://
(1745 is now closed)
https://
John_Bradley: Could browsers just not throw TypeErrors?
agl: Even if we did, enterprise value would get mapped from unknown to none (if browser doesnt recognize it)
… adding yet another static method to detect this apriori is welcome, someone can send a PR
… we'd probably land the change if someone cared enough to write the PR
John_Pascoe: Wouldn't oppose it.
elundberg: Can we reflect on enums at the JS layer? Is the WebIDL type exposed?
<nsteele> It was
agl: Not sure, worth checking.
elundberg: I will check.
https://
agl: Isn't this done?
Shane_Weeden: Yes
(issue is closed out)
https://
matthewmiller: In summary, setting residentKey=preferred leads to scenario where discoverable credentials will be created on devices with limited storage where you may not want to. There's no good value for an RP to set if they don't want to consume limited DC slots, because discouraged will not activate Passkeys on platform authenticators
… so if you want Passkeys but also want to be mindful of limited storage, cannot do that as an RP
John_Bradley: Most acute problem is that CTAP2 doesn't give users a way to remove credentials. CTAP2.1pre does.
… in CTAP2.1 added GetInfo data about how many resident key slots are still available
… not sure if RPs should do anything more
agl: Agreed
John_Bradley: Platform needs to be smarter about when to map preferred to 'create a DC'
… on Windows, will try to make a DC and if it fails will try again with non-DC
… is that what Chrome does?
agl: Not sure. However I think that maybe we should pre-emptively switch to non-DC if < 8 slots available (with CTAP2.1)
matthewmiller: Can we make security keys opt-in by requiring (scribe, missed this)
… make it so that you only get DCs on everything if you choose "required", not "preferred"
John_Bradley: with CTAP2.1, platform can make that decision
matthewmiller: But then RP has to keep track of changes in that logic
John_Bradley: No, preferred means I'm ok to accept a non-DC, thats not changing
Shane_Weeden: Don't like that the platform is in control, user should be able to choose. Could have two users with two identical security keys, but one gets DC and one not.
Tim_Cappalli: But users don't understand it anyway; what do they do?
matthewmiller: So we should remove it from user control and give RP controls instead. RP can explain it to users./
agl: wrt Shane's scenario, that is true today already? Making the number 8 instead of 0 doesn't make it worse?
Shane_Weeden: Reasonable, but I'd just never use preferred then
Tim_Cappalli: Can show adaptive UI after registration?
Shane_Weeden: Only if credprops is supported by the client, not all clients do
matthewmiller: Also, with Android as-is, RPs have to platform detection. Can't always send same options. Need to send discouraged for security key, but not on Android.
… preferred leads to DC creation on security keys
John_Bradley: agl and I are saying we should move in the direction of security keys *don't* make DC for 'preferred' unless there are lots of slots (CTAP >= 2.1)
agl: Not sure I can necessarily align with that... we're closer to "almost always make DC"
… would probably always make them on 2.0 no matter what
Mike_Jones: Why save the last 8?
John_Bradley: Want to reserve slots for some future sites that use residentKey="required"
Shane_Weeden: But that is relying on RPs to only use residentKey="required" if they NEED it
Tim_Cappalli: I expect vast majority will use rk='required'
John_Bradley: Then this is a pointless discussion
… because there will be no space
Tim_Cappalli: Ultimately its a limited resource, but users don't understand it (unlike say file system size)
matthewmiller: Another scenario - some RPs may be aiming only for passwordless don't have DC as a requirement, so maybe want to set discouraged
… but then you get passkeys on everything but Android, which is weird
Tim_Cappalli: In my opinion no new RP should ever want to NOT create a passkey
John_Bradley: We have heard cases where they need an attestation, and the only way to do that (on Android?) was to create a non-DC
matthewmiller: WebAuthn is not passkeys. We should enable flows that don't necessarily want DCs
agl: I think rk=preferred is still a good option
… its unfortunate that on CTAP2.0 you will fill the security key
… but over time, market will fix this - if you need lots of credentials, market will sell keys with huge storage
Shane_Weeden: How should RP handle that if credProp isn't supported then?
agl: I am assuming RP is collecting username + sending down list of credentials
Shane_Weeden: Isn't that an anti-pattern?
agl: Roughly agree, but many RPs are telling us that they will do this in the medium term
John_Bradley: We've said that this is bad because it leaks whether a site has an account with a given username (because attacker can sniff for returned credential IDs), but maybe that's just fine
elundberg: Yes, if your sign-up form already rejects already-signed-up emails, then this is essentially moot
(a general discussion occurs about how the spec can/might guide RP UX, and that the answer is it cannot)
Tim_Cappalli: We're trying to build a dictionary in passkeys.dev which will tell people "if you pass these options on [browser] on [OS], you get [this UX sequence] for your users"
… We welcome help!