Meeting minutes
invite rrsagent
Guest: Joseph Vasterling - Best Buy
WebAuthn @ Best Buy
<wseltzer> [presentation from Joe Vasterling]
joseph: what is best buy doing around web authn
Best Buy
… will give us high level overview.
… customer authentication is key for us.
… security for customer is key, secure as possible, with a lot of challenges.
… security vs. friction
… we are customer obsessed
… more customer interaction is the goal and to drive addtional security
… we rolled out Webauthn on large screen experience
… credential selection is first step.
… ties credential to webauthn process
… user gets to recognized state and thenm prompted for credential
… works with chrome and firefox
shane: do you filter for other platforms
joseph: I don't think we are asking for attestation.
joseph: we are working on the feedback loop
… we do surveys on bestbuy.com site.
Andrew: we created UX guidelines.
… did you look at those.
joseph: it seemed confusing at times
… they seaid the spec was confusing to them
… they struggled on their own, trying to give feedback
A.Shikiar: I will send you the UX work that we have done.
joseph: I will take a look
tony: what is update?
joseph: it is light. we are trying to help customers through the authentication process
… we don't know yet what to call the button for authentication
… we would like more traffic.
Matt: how did you think about the security
joseph: we do see people in channel and account takeover , trying to help security here
… we discovered webauthn, but we are exploring all options
NickS: were you doing any testing, conformance test
joseph: I will take that back.
matt: as a consumer I was happy to see the options
joseph: as you work on this, fraud is a big issue.
… so we want good authentication.
shane: on account take over. pre-webauthn you could force multifactor to you do that
joseph: we see some success here.
… it is compulsory
joseph: we do look at payments, no looking at the flow. more about how to control the flow
bradley: you are part of the risk analysis, this is for payments
agl: have you seen passkeys
joseph: no
joseph: we have not removed the log-in; once they do the initial credential we can take away log-in
… we are using surveys and tools for feedback on WebAuthn
Andrew Shikiar: <lost audio>
… we need to iterate passkeys
… that is based on testing
getting that feedback to FIDO
… want to gather all we can
… it shows future directions
… w3c and FIDO there is overlap, we want to support the Adoption Community Group
… web authn and FIDO is a close working relationshiop
… one goald for FIDO was to enable libraries
… want to see that take place.
tony: where does PassKey going
andrew: I hear alot about it
… taking passwords out of play
… would be interesting to see how enterprise goes.
… I think the security key is the gold standard
tony: one of your principals is impacted
… we need to see how enterprise goes.
bradley: passkeys will work with Level 2 certification
… passkeys are not being standardized
Tim: we need to see it as a credential type
… it needs to be generic.
… there is not a threat here. there is not a spec called passkeys
Nick: it is coming out like it is different keys
matt: enterprise is losing the controls on the security model
shane: yes.
bradley: we should talk about multi-device creds, which is just one piece.
matt: enerprise RPs asking about passkeys.
shane: challege for platform providers, enterprise is not set to adopt this right now
… some of the model is out of sequence.
TPAC
tony: one thing to bring up is TPAC
… request to meet with anti-fraud and payments people
… TPAC is end of September
<wseltzer> [12-16 September]
wendy: 12-16 September
tnoy: so we will be there; meet with payments, privacy and anti-fraud fols,
tony: look at some PRs and some details, then go to Christiaan when he gets here.
PRs
tony: let's go to open issues.
https://
<wseltzer> https://
elundberg: adds some things we may not want to do as an RP
… I encourage review and feedback
Tim: maybe do this after the Ping presentation
DWaite: there will be Ping ID presentation. point is that FIDO does not protect against supply chain attacks
elundberg: issue with untrusted code on sub-domains.
tony: Nick has this come up with adoption group
nicK: not really
bradly: Token Binding would have made this easier...
https://
agl: no changes
tony: move forward with this one.
tony: will circle back
https://
matt: trying to figure this one out; could use a working session and push this through
agL: I want to see this defined and lander
… landed
martin: in reasonable shape, some open areas.
… another one is about structure of IDL
agl: this is not a web api.
… it does not have to follow all the IDL
matt: write as vaild IDL, but not restricted compoents
martin: should still be valid IDL
agl: there are no binding.
… tooling does not have to process.
… it is only humans will ever read this
bradly: but Mozilla has rules around this.
agl: this is mostly for developers
agl: should we delete IDL
martin: it is probably best to leave it in
elundberg: could we do this a different way in public key creation
eluncberg: you have add jason
… json
agl: martin thinks we need to have it in.
… elundberg is this fundamental in PR
elundberg: maybe we should be more rigorous, but willing to let some things go
matt: should be leave something for other browser developers
elunberg: mostly tweaks here, not so for fundamentals
matt: I will close this out.
martin: I can try to do this in a prototyple.
elunberg: I thnk of down stream we should be fine.
martin: we should look at processing
selfissue: think you will find all that in the registry
agl: work assigned to work toward closing this
<wseltzer> [break, 10 minutes]
<wseltzer> [resuming]
https://
aggl: we shold merge
tony: merge
tony: emil can you look at this one.
self-issue: I am approving now
tony: any objections?
tony: no
elundberg: mostly editorial, the rest we can approve
tony: merged
https://
<wseltzer> https://
agl: adds second key to given credential, android expects to support with when go public with passkeys
bradley: missing in CTAP a notion of attestation type
… we may want to have a certain attestation type; or Post Quantum , want to allow RP to have attestation types
… may be useful at CTAP layer to say more.
… I would like to fix is properly at CTAP level
… lets not do it as a one off
… would have to add flags to get attestations
agl: how to we express at aweb authn level
bradley: sort of already have a mapping
agl: you want attestations and types
bradley: will give us some room down the road to fill in gaps
… I would like to have RP options without blowing up things later in Post Quantum
… what do we want to do with multi-device creds.
… DPK, not multi-device cres
… Device Public Key
agl: DPK opens up some things we don't like
shane: this is going away from my question
… what is risk of not support DPK as primary credentials
agl: we don't want to make this a smooth operation
… check that, we want this to be a smooth operation
self-issue: how do we make this actionable
bradley: change proposed taking over entire cryto-gram
… there is not an issue for this yet
… only question is to do this in way that will not impact existing RPs
… there are things that may go beyond the RP.
self-issue:
… defers
agl: are we changing this out , and an unsigned output?
dirk: DPK choose to make use of this.
agL: this should not break anything.
akshay: what will the main key signed in this case.
agl: both will be signed. one normal one unsigned over the authenticator data
dirk: how does attestation work then>
agl: new fields in CTAP2, it will control attestation and normal attestation.
agl: I think the DPK stays in the extension
shane: enterprise need a way to deal with cloud ???
agl: we want to make a clear path for DPK
shane: give me a device bound cred, DPK is a hard way to express this.
bradley: difference this makes RP, can get attestation without DPK
… should authenticators return it RPs could do it.
tony: any objections of returning DPK
agl: we are not breaking it.
agl: apple is getting rid of passwords...
shane: if no attesation for the DPK, then it is nearly useless
bradely: we have to nail this down.
agl: RP won't get attestation this year
agl: I will write a PR on this.
<wseltzer> [lunch break, 13 minutes]
<wseltzer> [returning]
Demo
<wseltzer> [Christiaan shows a passkey demo]
end of demo
matt: does this use conditional UI
Christiaan: yes
<wseltzer> https://
Back to PRs
nina: I also have to send updates to HTML
… we could merge with a note that HTML updates are also needed
… I haven't yet opened an issue in HTML to avoid circular dependency
tony: Can you open an issue or PR there for tracking here?
nina: yes
… and 1576 is ready to merge from my perspective
john: Should timeouts be respected?
nina: called out recommend avoid setting timeouts
john: @@
nina: when you cancel the request, we don't resolve the promise
… so we're not signaling that user has credential but chooses not to use it
… webauthn without conditional UI can show error because it's the same error as timeout
<jfontana> Do you need me to take over
<jfontana> wendy
<jfontana> * jfontana can you take the next 10 minutes?
matthew_miller: what if you keep changing focus to and from the username field, does it prompt every time?
nina: I think it should be every time
… though it could be a more subtle indicator on subsequent focus
matthew: there could be implementation variations
tim: as there are for password
tony: so you'll update and we'll discuss at next meeting
tony: 1425, recovery extension?
elundberg: nothing new
tony: 1736
https://
elundberg: looks ready to go
tony: any objections?
… merge
tony: 1741, did we resolve?
john_bradley: related to DPK, PRs in CTAP
tony: 1740
elundberg: some editorial fixes
… I'll create the PR
tony: 1739
(returning to that one)
tony: 1738
john_bradley: how can we add flexibility, so it doesn't blow up browser
sbweeden: other examples where we deal with fingerprinting surface, compat?
… e.g. getWebauthnLevel
<wseltzer> tim: could you follow sec client hints ?
* jfontana Wendy I can take over
nina: ok upgrading to chrome.
… I am OK the caveat is this is not silver buller
… bullet
bradley: how does microsoft feel on enum issues
agl: we don't fall back to direct
… set enterprise.
Bradley: that is good point
bradley: default is better than blowing up.
… should it return a type error
matt: we do that an act accordingly and go to an alternative
agl: we have to have one rule
bradley: you can't no what it is before you get it
bradley: needs some feature detection
agl: we need ignore as a default
self-issue: who will file browser bugs?
nina: maybe we want to discover if enterprise attestation is supported or not
… I will file bugs
tony: this has to be made clear in spec
bradely: it ignores some browser options
self-issue: lets not go to versioning
agl: do RPs what attestation flag
bradley: we need dom string, ignore ??
<selfissued> https://
tony: nina you will update
nina: which way are we going
agl: don't need feature flag for attestation and we want to change the dom string
nina: I filed an issue for the attestation feature
tony: so you can finish issue
tim: #1739
tim: we can to mediated UI
<matthewmiller> https://
tony: we are through the un-triaged
tim: closed #1708
tony: RP use cases
… this is a discussion
RP Use Cases
Matt: Cisco looking at sync across devices
… this was ideal for use, being shared - less ideal
… we thought it would still be bound to user
… now we see sharing keys.
… now we have cred does not indicate specific devices or users.
… there is lack of configure with web authn and new keys
… what are RP pain points.
… if opt out, people will do that. but we need to have them
… passkeys will come out way before DPK what happens then?
shane: there is going to be awful second factors as people ignore passkeys
matt: need to hedge capability of passkey, we could sell other products, but we shouldn't have to take those extra steps
… I think we should double down on the frustrations of RPs
matt: the reason we stopped attestation was a consideration
… it will be a negative when we have that conversation,
bradley: your beef is with multi-credentials
… we need to be clear on the terminology
… matt your problem is not with multi creds.
matt: in this moment there are features we have issues with
matt: you have two things hybrid and flags
… we are not ready to support this
tim: we all get support cases
agl: does this thinking include security key for employees
… if we put this behind enterprise flag it is useless to you (microsoft)
matt: manage device policy is not going to work for us.
tim: same answers across all these areas
matt: we had security keys and now we had to adapt to cable
… these are things we need ahead of time. we would have opted out
Christiaan: this will stablize over time
… can we give people an opt-out? when everything is there it will go forward
matt: this will repeat itself with evolution and new featuers
… what if we have different mentality on roll outs
Christiaan: longer term concern. we will focus on consumer, having a key will be unsettling for them
bradley: some browsers do a better job than others. there are things we can do.
matt: not just authentication experience, we have authorization
Christiaan: we might want to spell out some things more specifically.
shane: we always needed attestation. why can't we do that
Christiaan: so you can simply not offer anything.
Shane: on issue to wait on signal. At the end, I say tough
bradley: cable does not tell you what is coming.
… user agent does not help
Christiaan: there are plenty of times you want to know the authnr is an Apple platform.
shane: but you don't get an attestation.
Matt: could we add a simple flag to registration
matt: we are working with a staggered roll out
shane: we will have windows where we will shut down WebAuthn
bradley: is there some attestation where we could offer?
tim: we mapped a user on a device and now it means nothing
Christiaan: there is still a value to passkeys
… consumer enterrpise
tim: we are evangelizing a new passkey for enrollment
… but now it is credential sharing
tony: this is a choice for people.
wendy: should we go back to security modeling.
… as the technology is out there , use cases are overlayed
matt: we were just getting used to credential sharing, and then this is coming was
John (Apple): these are looked at as better than passwords.
… it was password replacement
tim: what precedent we are trying to do.
… we say credential sharing is coming
shane: I don't want user to go through ceremony that the RP knows will not work
agl: I don't understand going back to RP
shane; It is more of having the authenticator not being able to fail as an outcome.
… get the correct credential
… I want the RP to be asked for a credential
bradley: this is more like a transport hint.
shane: capture the issue
dirk: why does this not meet the requirement on DPK?
christiaan: you can go back if you want
bradley: DPK is suppose to fail. you can't error out.
… i don;t know that all RPs will want that behavior
matt: here is my ask. if we can't have device bound cred, can we ask for a credential to be permanently bound
shane: sounds like a path to distruction
Christiaan: I see future, we allow mulitplel vendors to plug in
… put all of these passwords will have different ways to share, get back into account.
… this is why we have attestation, we can go down multiple paths.
… now we come back to meta data.
shane: mds will describe what these things are
dirk: maybe requirement is identifying a kind of passkey
dirk: maybe it is not the sharing, but the capabilities
elundberg: main argument against it is don't want a flag, don't want user to turn on better secruity.
shane: I have problem that is out of the RP's control to ask for a specific thing
elundberg: notw that we have flags it makes sense to have tihs parameter on the top level.
<jfontana> s/this parameter/
Matt: trying to preserve the device bound,
matt: I want a fail if the credential is going to fail
agl: I am listening
shane: i don't care the answer, s to make this request of the client
<jfontana> s/wants/want
tony: we have to show the implementation of the spec. in order to go to Recommendation
… you could play with features
… but it has to have implementation to have spec
bradley: RPs will have to decide what they are going to reject.
christiaan: we have to see how tis shakes out.
bradley: we have strong authentication, is it multiple factor? It is strong single factor. It could be part of an AAL 2, and be multi factor
… we are changing the underlying rules
matt: is this a message going out, you want to consider a second factor
bradley: depends on your use case.
[10 min break]
tony: would like to have a draft WD-01
… put out a draft before TPAC
self-issue: do we have the people who can use the tooling?
ACTION: wseltzer to do some repository cleanup
wendy: she can offer help from W3C
tony: any more issues to talk about?
… SPC?
C
SPC
[Christiaan describes the SPC argument for non-iframe cross-origin get of credential]
christiaan: can we allow the creation of a webauthn credential in a cross-origin iframe?
jbradley: should we take this on?
… admit that you can make a credential in a cross-origin iframe
… which will make many IDPs happy
christiaan: can you write an issue?
jbradley: yes
christiaan: we also keep hearing about generic things people want signed...
selfissued: there's an unimplemented extension
agl: do users understand who is speaking is a big concern
agl: you navigate to example.com, get a foo.com iframe that can make a foo.com credential, that can be used on example.com
jbradley: make in 3d party context iframe
agl: make in ifrme that is not same-origin with ancestors
tony: Any other issues?
sbweeden: thanks for the conversation about the needs of enterprise
matthewmiller: what we're telling RPs, DPK is coming and will eventually be able to achieve the properties that had been assumed
… no short-term mitigation
christiaan: continue to make credentials as usual in Android
matthewmiller: does apple have a mechanism for opting out?
johnp: no
tony: talk with you all in 3 weeks
… thanks Tim for hosting
[adjourned]