Re: [Agenda] 27 June WPWG call

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


On Thu, Jun 27, 2019 at 07:54 Marcos Caceres <marcos@marcosc.com> wrote:

> Hi All,
>
> > On 25 Jun 2019, at 8:34 pm, Adrian Hope-Bailie <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.