Re: Strong authentication for PayPal versus WebPayments

On 2014-05-15 21:46, Manu Sporny wrote:

Before going into the specifics I think it is useful realizing that the
"market" is pretty divided on security requirements.

Yesterday I had a long meeting with a security group of a major handset vendor
who claimed that ideally payment applications should run inside of a hardware
assisted secure compartment (aka TEE) within the CPU.  This compartment would
also be able to override the OS's and do direct I/O (trusted UI).  This scheme
has been designed by http://www.globalplatform.org and is of course completely
non-compliant with the web.

The Web payment CG's solutions OTOH do not depend on cryptographic keys in
the client platform which sort of represents the other extreme.  This seems
to align pretty well with the US way of doing things.

I'm personally focusing on schemes which eventually would be fully portable
but indeed require substantial upgrades, not only of the browser, but also of
the OS/platform the browser is running on.  This work started by decomposing
3D Secure which I consider a cool system in desperate need of a better platform.
3D Secure has been slashed by the US e-tailers but lives on in the EU.


> On 05/07/2014 12:54 PM, Anders Rundgren wrote:
>>> Why will U2F only work for 2-3 identity providers?
>>
>> A certificate using HTTPS Client Cert Auth like in WebID-TLS can be
>> used for login to any properly setup site, right?
>
> Yes. Although, not all of us are sold on the WebID-TLS strategy of using
> browser-based client-certs to do login (myself included).
>
> There are plenty of other ways to do it, though. We're currently
> building a proof of concept demo to show how you can couple a
> decentralized protocol (like Telehash[1]) with the Identity
> Credentials[2] spec to get something feature-equivalent, but without
> requiring browser-based client certificate support.

This could also be expressed as "without strong binding to a client-based
cryptographic key" which departs from the method already fully deployed in
EU brick-and-mortar shops.  To me this is essentially a market decision.


>> U2F, OTOH, presumes (for privacy reasons) a unique public key for
>> each domain/site enforced by SOP.  Getting around that
>> feature/limitation isn't my cup of tea.
>
> Ok, so you convinced me to finally try to find documentation on U2F and
> get myself educated. I had looked for the FIDO Alliance documents
> before, but couldn't find much. These are the pre-FIDO Alliance
> documents from Google, and I found them useful:
>
> https://sites.google.com/site/oauthgoog/gnubby
>
> I still don't understand why a unique public key for each domain/site is
> such a terrible thing. You can still couple that solution w/ a
> decentralized identity provider to be able to assert a single identity
> w/ specific credentials across multiple websites. That is, I don't see
> the one public key per domain/site being a road-blocker issue. What use
> case can't we accomplish w/ that setup?
>
>>> I'm assuming that it's going to be for the same reasons that OpenID
>>> Connect is probably only going to work for 2-3 identity providers.
>>
>> Yes, that's exactly the right comparison.
>
> After spending a few hours reading the U2F documents, I don't think it's
> correct any more. U2F doesn't prevent you from switching providers,
> OpenID Connect does. Sure, you can't re-use keys between providers, but
> that's a good thing wrt. privacy issues. Also, keep in mind that if you
> /do/ want to re-use keys, you can always layer that on top of a
> U2F-based login to an identity provider. There's nothing to say that the
> key you use for login must be the same key that you use for the U2F
> device.  That is, you can still have fully decentralized solutions w/
> U2F as far as I can see, so what am I missing?

You can do that but at some expense of user hassles.

Cheers
Anders


>
> -- manu
>
> [1] https://github.com/telehash/telehash.org/blob/master/protocol.md
> [2] https://web-payments.org/specs/source/identity-credentials/
>

Received on Saturday, 17 May 2014 05:56:24 UTC