<Ian> (Noting for the record that there is not a desire to record)
timcappalli: [shows a screen with linking devices via QR code]
… cross-device flow
… user has a phone and a laptop/desktop
… try to access desktop resource, are presented with a QR code
… TLS cert validation has succeeded for origin in their browser
… User opens phone (camera or wallet)
… thinking generically of "wallet"
<Ian> [Payment apps are another instance of wallet]
timcappalli: bucket of credentials
… QR could contain request or point the device to a request object elsewhere
<Kristina> SIOP stands for self-issued openid provider
timcappalli: could be like OIDC
timcappalli: wallet needs to get user consent: "do you want to respond to this request?"
… today, browser posts back, without binding
… that's where the security model has a gap
KristinaYasuda: mitigations we've been discussing with different communitieis
… OpenID foundation, Mobile Driving License (MDL), OAuth flows
… First mitigation: when user is asked for consent, show user from where request comes, where it goes
… if bad acto phishes the request, won't match. Up to the user to note the mismatch
… Next consideration: use proximity to check
… make sure QR code and scanning device are close enoug
<dwaite> +1 Ian - I'd say WebAuthn, payments, mDL, OIDC/WebID2020, OAuth Device flow. Payments, authn, and derivatives (authz, attributes)
KristinaYasuda: IP addresses aren't necessarily useful
… enterprise could say "both devices on trusted network"
… limitation, e.g., if onboarding new device; on public network
… user cooperating with attacker, in proximity
… using WebAuthn, assuring user has control of private key,
<dwaite> WebID2020 -> Federated Credential Management API (forgot the name there for a moment)
KristinaYasuda: Another, something shared, PIN or OTP
… user sees something on screen, types it on mobile
… biometrics, where device displaying QR captures biometric
… locally, device compares for match
… Just some ideas for sharing, want to open for discussion
weiler: can you restate problem statement?
Kristina: User tries to log in to device with QR code. Attacker could screenshot the QR code
… log in to website, using laptop
dwaite: I'm on a device; the credentials or payment are released by another device
… there's no channel (yet)
… so if the user doesn't verify htey're interatcting with the right site
… the credentials/payment could be sent to the wrong site
… in FIDO-land, caBLE
… trying to understand commonalities, for single solution
tim: New TC at OASIS looking at QR code phishing
Rolf: authenticate a session with a separate device
… need migration
… roaming authenticators in FIDO-land
… out-of-band authentication, many of the proposed solutions are phishable
<dwaite> CaBLE - cable-equivalent security for talking to CTAP 2 authenticators over BLE. The idea being then you have the same phishing resistance of WebAuthn when interacting with detached hardware
Rolf: you can't make QR codes unphishable for session authentication
… in payment situation, you typically see the transaction text
… caBLE tries to build communication channel back to browser
tim: another complicating dimension is there's no existing relationship between devices
reillyg: is caBLE the obvious solution?
tim: we think it is, want to hear the use cases
… caBLE v2 isn't yet a public spec
… talk about MDL, passports
Kristina: if you think caBLE v2 is the solution, let us know
<weiler> [Where are the problem statement and use cases documented?]
Rolf: how many of the PCs these days support Bluetooth practically, enabled?
tim: don't know offhand
… fragmentation in hardware and stack
kris_chapman_: seen Salesforce clients with this situation,
… e.g. using QR codes for service appointments, to check-in
… Companies using for employee attendance or badges
tim: the reverse, taking the artifact with you?
kris_chapman_: the QR code will go to the client, they scan their own code at the appointment
weiler: where's the problem statement and use cases documented?
<Ian> +1 to a use cases discussion
weiler: that would help us to know as community
tim: we'll take that as one of the outcomes of this call
Kristina: where's a good place to host such a document?
tim: could be a github document
reillyg: or MSedge explainers
<Ian> [No GitHub pref]
weiler: when you have something, you can poke the public-web-security mailing list
<Ian> [Also send notice to firstname.lastname@example.org for awareness of payments use cases]
dwaite: think about what makes it easy for people to contribute
dwaite: +1 to weiler re documenting use cases
<Ian> [Payments folks have also had intermittent discussion of QR codes, see => https://
dwaite: I'd be happy to help contribute
… is this payments, establish relationships, single transaction?
… e.g. MDL presentation, is brand new set of prompts every time
… payments, authentication, delegated authz, VC,
… trust relationship between devices, sometimes transactional
… could be possiblity of other use cases like info-sharing across sessions
bmay: in lots of groups using github
Rolf: use cases: for me it's transactional things, e.g. sharing health data with hospital X
… description that user can undersatnd, bound to the approval
… different from session identifier
<reillyg> The MSEdgeExplainers repository is a GitHub repository: https://
<Jemma> +1 for using w3c github
Rolf: security considerations different
wbaker: IPR protection aspect is the value
… are we covered in what will happen eventually
… value in making sure IPR is traceable
wendell: GH is great. tying it to w3c IPR is the value.
wbaker: tying to W3C IPR policy is valuable
<Jemma> +1 to wbaker
wendell: don't talk about it here and then move it elsewhere, where coverage is ambiguous.
tim: any precedent for a use case doc?
<weiler> wendy: fine use case for.a CG.
<wbaker> Wendy stewards ADBG with is full of use case documents!
<weiler> wendy: that has CLA and IPR tracking, and can go to other w3c groups or elsewhere.
<weiler> tim: I fear mtg fatigue and spinning up CGs. We can do a CG w/o mtgs?
<weiler> wendy: yes
<weiler> tim: others like CGs?
<weiler> [resounding yes]
<Jemma> good question, Ian.
<wseltzer> Ian: where can we learn more about caBLE v2, when would it become public?
<wseltzer> tim: it's in private development, woudl come to FIDO Alliance
<wseltzer> Ian: we have Web Payments Security IG, not publicly minuted. If you'd like a payments-focused audience, I invite you to share there
Ian: Ping me for WPSIG review of a use cases doc
<wseltzer> tim: will communicate on public-web-security
<wseltzer> Kristina: next step, to compile use cases document
<wseltzer> bmay: is there a link for more background?
<wseltzer> tim: not concisely
<wseltzer> ... caBLE v1 is in WebAuthn GH issue
<wseltzer> dwaite: caBLE is about channel, not CTAP specific
[The Web Security IG is closed but apparently the list lives on => https://