Re: U2F Demo

On 2014-05-30 12:32, Herbert Snorrason wrote:
> On fös 30.maí 2014 06:29, Anders Rundgren wrote:
>> Yes, this is the use-case that the established payment industry
>> consider #1 with respect to the user-side of things.
> Seems to be more than #1; it is the _only_ use-case FIDO deals with.
> Well, though, from all appearances.

Correct.


>
>> IMO, WebPayments do not have anything similar meeting their (compared
>> to PayPal much more advanced) use-case.
> Wait, are you thinking of WebPayments as a replacement for PayPal? Then
> either you or I got something badly wrong, because WebPayments looks to
> me like a mechanism to standardise interfaces so _others_ can try and
> replace PayPal. How people authenticate to the PayPal-like thing is out
> of scope.

100% agreed.


>   How third-party websites can verify that their client is
> authenticated, though, is something that probably needs to be looked at.

I would rephrase it like: Whichever party is responsible for authenticating the client/user
must do that using [technically] Secure *and* Convenient methods, which is something that
needs to be looked at.


>
>> Well, to be entirely correct U2F really only fits perfectly for a
>> mega-provider due to its reliance on SOP.  All distributed uses of
>> U2F will force you into OpenID-kind of schemes and NASCAR screens.
> U2F, to me, appears at least on the surface intended to be broadly
> usable by anyone who wants to use it in their log-in procedure. What,
> exactly, makes it suitable in that case only for "mega-providers"?

If you use PayPal the U2F-token only needs to work with paypal.com, if there
are hundreds of paypal-ish providers you need to specify your particular one
to the merchant.


>
> For distributed use, yes, it requires a federating protocol on top. A
> federating protocol is what's being talked about here. So I don't really
> understand where you're going with this whole "use U2F instead" thing.

Does manually specifying a domain, URL or clicking a icon really qualify as a "protocol"?
IMO, it is rather an ugly workaround built to suit a browser-platform which was never
designed with ubiquitous federation in mind.

Microsoft actually once tried to fix this albeit through a rather heavy-footed machinery
which eventually was abandoned:
http://www.identityblog.com/?p=923

However, it is (AFAICT) possible to recast this scheme into *enhanced* web technology
which would allow it to work for a wide set of applications which neither CardSpace
nor OpenID is even close addressing.


>
>> There's IMO *no point whatsoever* "reinventing" OpenID or try
>> competing with OpenID.
> Then we disagree on a pretty fundamental level. OpenID is not
> acceptable, nor is any protocol which grants the identity provider the
> same level of surveillance capability over its users.

I don't think we disagree on a fundamental level, OpenID in itself is not
bound to specific providers more than a possible competitor would be.
I only questioned the value of creating new technology which does similar
things to OpenID.

Regards,
Anders

> A combination of
> an identity scheme that allows identity providers to monitor everything
> and an oligopoly in identities effectively controlled by US-based
> corporations (which is the status quo) is especially worrisome to me.
> What happens when the U.S. government goes on one of its quasi-regular
> McCarthy-ite political persecution sprees, and issues wildly overbroad
> search warrants asking for "everything" about a given account on the
> basis of hearsay and/or political affiliation?
>
> You're welcome to argue that such an effort is futile, but arguing that
> it is pointless is idiocy.
>
> With greetings,
>    Herbert Snorrason
>

Received on Friday, 30 May 2014 12:31:55 UTC