– DRAFT –
(MEETING TITLE)

<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

<Kristina> https://openid.bitbucket.io/connect/openid-connect-self-issued-v2-1_0.html

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

<Kristina> caBLE

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 public-payments-wg@w3.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://github.com/w3c/webpayments/wiki/QR_2020]

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://github.com/MicrosoftEdge/MSEdgeExplainers

<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

<weiler> public-web-security@w3.org

<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

<Kristina> https://bitbucket.org/openid/connect/issues/1269/add-security-considerations-for-cross

<Kristina> https://bitbucket.org/openid/connect/issues/1273/mitigating-security-risk-by-using-webauthn

<weiler> https://lists.w3.org/Archives/Public/public-web-security/

[The Web Security IG is closed but apparently the list lives on => https://www.w3.org/Security/wiki/IG ]