Re: [Agenda] 27 June WPWG call

> Since you can't call arbitrary native applications from the Web (in a
useful way) we are effectively stuck with FIDO/WabAuth as the only
realistic alternative.

> The SQRL author's claims about phishing resistance when using QR code are
false, you must create a trusted connection between the Web page and the
phone in order to achieve phishing resistance.  QR doesn't do that.

I think SQRL handles this by invoking the app directly using a custom URL
protocol. Following this, the interactions occur directly between the app
and the SQRL server until the session is authenticated at which time the
app passes the browser a URL that will allow it to step into that session.

> Before going into privacy and security details we need to specify which
entities and problems we are talking about. E.g. "Device Fingerprinting" on
the Web in general versus the issuer of a payment credential are not
entirely comparable. In Android you can even have the platform attests its
identity:
https://developer.android.com/training/articles/security-key-attestation

My read of the requirement from the networks is that they are not looking
for assurance of the payment credential but of the customer and device
identity specifically to kick off the SRC step of generating a candidate
list and/or as input into 3DS


On Thu, 27 Jun 2019 at 16:40, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2019-06-27 09:45, Adrian Hope-Bailie wrote:
> > By the way I found this project really interesting and potentially
> useful in this context.
> >
> > https://sqrl.grc.com/pages/what_is_sqrl/
> >
> > The technical spec is here:
> >
> > https://www.grc.com/sqrl/SQRL_Explained.pdf
>
> Adrian:
> Since you can't call arbitrary native applications from the Web (in a
> useful way) we are effectively stuck with FIDO/WabAuth as the only
> realistic alternative.
>
> The SQRL author's claims about phishing resistance when using QR code are
> false, you must create a trusted connection between the Web page and the
> phone in order to achieve phishing resistance.  QR doesn't do that.
>
> Marcos:
> Before going into privacy and security details we need to specify which
> entities and problems we are talking about. E.g. "Device Fingerprinting" on
> the Web in general versus the issuer of a payment credential are not
> entirely comparable. In Android you can even have the platform attests its
> identity:
> https://developer.android.com/training/articles/security-key-attestation
>
> Anders
>
> >
> >
> > On Thu, Jun 27, 2019 at 07:54 Marcos Caceres <marcos@marcosc.com
> <mailto:marcos@marcosc.com>> wrote:
> >
> >     Hi All,
> >
> >      > On 25 Jun 2019, at 8:34 pm, Adrian Hope-Bailie <adrian@coil.com
> <mailto:adrian@coil.com>> wrote:
> >      > I wanted to expand a little on the topic of "Risk assessment vs
> privacy" just to set the context and ensure those interested in this
> discussion make sure to join.
> >      >
> >      > This is one of those "meta" topics that I think we'd all benefit
> from discussing widely. In short, there are two sides to this:
> >      >
> >      > On the one hand, the payments industry prioritises security over
> most else and specifically goes to great lengths to assess the risk of
> authorizing a payment that may be fraudulent. The logic to authorize a
> payment is seldom binary, it's often a pretty fuzzy assessment based on
> various risk factors. The greatest tool for this is data. Lots of
> contextual data about the transaction including device fingerprints, user
> data, location data and more.
> >
> >     This is definitely true and appreciated - however, the
> fingerprinting aspect is where we have a few options... for instance,
> instead of fingerprinting the device, it's better to work with browser
> vendors to come up with a unique identifier that keeps the user in control.
> Similarly, with deriving the user's location, and so on...
> >
> >      > On the other hand, we have the privacy focused members of the Web
> community who are battling against the prevalent data collection that
> happens online to facilitate the advertising industry's need for better
> ad-targeting.
> >      >
> >      > As you can see these two groups' requirements are at odds, even
> though their motives are not so even if we can just understand each other's
> point of view I think that's a good start.
> >
> >      From a browser vendor's perspective, we definitely have shared
> goals: protect users/customers from fraud as best we can. Where we get into
> conflict sometimes is where we don't know what's possible... for instance,
> it's not necessary to query ~200 data-points from the device to create a
> fingerprint: instead, asking the browser to give a unique identifier for
> the purpose of payment that the user controls would achieve the same goal,
> and prevent brittle fingerprinting... that's privacy preserving, keeps
> users in control, and should give payment providers the assurance they need
> to mitigate fraud aspects.
> >
>
>