NickTR: We have sent the transition request to return PR API 1.0 to CR en route to Recommendation.
<nicktr> ian: there is now Github templating for moving to Candidate Recommendation
<nicktr> ...See our rough timeline
<nicktr> ...If all goes well, we should reach Recommendation in March 2021.
<nicktr> ... we need to have interoperable implementations (see our Less than 2 report for the latest, although it's out of date) by the end of CR.
Ian: Thanks to Marcos for his work on the spec and test suite!
The WPSIG has published How EMVCo, FIDO, and W3C Technologies Relate.
<Ian> ...for those who are not in the WPSIG, we have a document about how our technologies relate
<Ian> ...we have done a press release
<Ian> ...and I just wanted to give eveyrone a heads up
Blog post summary of our 4-day meeting in October
NickTR: Highlights included SPC.
Lots of energy and enthusiasm.
... people expressing interest in experimentation beyond the
Stripe/Google pilot
... another interesting development was the Mastercard and Visa
work on SRC (including using SPC)
... good discussion around QR codes
... QR codes are of interest to the merchant community, as we
are hearing in the (new) Merchant Business Group
... One use case is QR code presented by merchant on mobile;
how do you use device to read QR code?
<Zakim> Ian, you wanted to comment on QR codes
<nicktr> ian: I met with Gerard from Entersekt
<nicktr> ...to dig down on what we would look for in browsers for QR
<nicktr> ian: 1) if there are n QR code formats and m helper applications, the browser could help navigate that experience
<nicktr> 2) what if the QR code is presented on the same device that would scan it?
clinton: In Ian's overview he talked about what entersekt called the "single device problem"
Ian: (1) matchmaking by the browser (2) communication by API of QR image to app to address single device use case
clinton: Both are single device use cases
Ian: Not necessarily...service worker could talk to server
Clinton: Is that really useful? What if the user is just using the camera app on the phone?
Lawrence: Suppose on desktop I am using Chrome... are we talking about same browser?
Ian: I am basically hearing the browser can help route the QR code either to same device or other device via service workers
Clinton: Agree that's an opportunity
Gavin: Ian's explanation...that I can reach out to the person's phone. Why not send the QR code directly?
IJ: I Was thinking the device had special quality and why you wanted to use its camera and authenticator
David: Another scenario is where
you are required to have an app on the device
... e.g., WePay
... and you know the QR code will be scanned
clinton: I think the problem is
there...the solution might lie more in the QR code containing
some information that, once scanned (e.g., a URL) gives the
browser the ability to determine which path is associated with
the QR code
... for the single device, I think your use case makes a lot of
sense
... for the two devices, I think we should think about scenario
where desktop state has no knowledge of mobile state
NickTR: So I am hearing there is
something here...and we can continue to work on this
... I have a standing action item to write up use cases
<clinton> +1
<scribe> ACTION: Nick to write up QR code use cases and how they relate to browser capabilities potentially
Chris_D: IS there any work going on related to pairing browser with mobile device?
Rolf: If the device knows what to
do, then FIDO are in the picture
... how you get the information there doesn't really
matter.
... CTAP is not generic to find a browser
... it's a way for an authenticator to connect to a device
Rolf: ...for authentication, we
are doing the connection via CaBLE
... so the transport is bluetooth
... there's an interesting open question (and relates to SPC as
well)... SPC assumes that the browser on the desktop (in our
example)
... when you use your mobile phone as an authenticator, the
phone has display capabilities.
... and so you'd like the payment details to be part of the
authentication request is sent to the (remote)
authenticator
... this was how the prior transaction conformation extension
was defined
... ...I think that we'll want to handle both use cases (same
device authentication and mobile auth)
Clinton: The problem is state communication
Rolf: I don't see need for QR code in case where the browser on the desktop can talk to the remote authenticator already (e.g., via CaBLE)
IJ: We are referring to two scenarios: there is a digital communications channel, or there isn't
Rolf: If QR code resolves to URL,
you could trigger FIDO through default browser
... so you can use QR when there's no direct communication
available
clinton: I think that what we are seeing is that there's a variety of use cases...thanks Nick! :)
<nicktr> ian: I think that the assumption that the QR encodes a URL might not always hold
Ian: Not all QR codes resolve to URLs. So browser could help
<clinton> +1
Rolf: But from a W3C perspective,
helpful to have all QR codes resolve to URLs
... that will make it easy for every user to use the QR code,
and that might resolve to a PR API experience
IJ: I Hear the plea but it seems like there's a proliferation of QR code formats
Clinton: I agree with Rolf that
it would be great to resolve QR codes to URL for scale
... you can really decouple the presenter from the consumer
Nick: I will start to capture the
use cases before we next meet
... thanks for everyone weighing in, and please continue to do
so
- No call on 26 November
- Next call: 10 December
- We MAY meet on 17 December; chairs will figure out closer to the date
Check out the Authenticate 2020 conference.
<nicktr> including a session on How Technologies Relate with Nick Telford-Reed, Bastien Latge, Christina Hulka, and Ian Jacobs.
Nick: Please come ask difficult questions!
Rolf: I'll also speak at the
authenticate conf, on best practices (see Rolf's Authenticate session)
... what existing deployments are out there
IJ: Any info on banks in Europe doing FIDO?
Rolf: I did a podcast on that
topic (in German)
... I think we are partly waiting on first movers