Re: [Agenda] 27 June WPWG call

On 2019-06-27 17:53, Adrian Hope-Bailie wrote:
> > 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.

I was rather thinking about the Mobile + PC use case which is also mentioned in the white-paper/spec.

Regarding URL protocols: The only URL protocol solution I'm knowledgeable about is the one in Android and it does not transfer the page's security context and should therefore be fully phishable.  FIDO2/WebAuthn doesn't suffer from this problem since is integrated in the browser itself.  It even uses the TLS channel ID to further strengthen the binding.

>
> > 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

I understand but not why :-)  If you sign payment authorizations using hardware backed keys (supported by Apple et al) issued by the bank what more can you do except trying to verify that the user is authentic?

SRC is looking for a problem that is already solved unless it is about extending the life of CNP.  All providers of mobile payment systems claim that their systems are secure. Why should they rewrite their perfectly working systems to use SRC?

Anders

>
>
> On Thu, 27 Jun 2019 at 16:40, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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> <mailto: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> <mailto: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.
>     >
>