Re: U2F Demo

On fös 30.maí 2014 12:31, Anders Rundgren wrote:
> 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.
But authentication is, as far as I can tell, out of scope. Authorisation
isn't. These are two distinct functions.

> 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.
Or you need a mechanism to discover the provider from a global
identifier such as email. WebID's notion of just using the URL directly
as an identifier is flawed, but a discovery mechanism capable of
resolving an e-mail (or possibly XMPP or SIP) address to an identity URL
seems quite sane to me.

The thing is, if you only say "well, merchants can support whatever
payment means they want" you're really not giving the _users_ choice,
you're giving the _merchants_ choice. Users will have to get accounts
with whatever payment processor the merchants they want to buy from are
using. Unless, of course, you simply have a monopoly payment processor,
and everyone uses PayPal. Oh, hey, status quo.

> 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.
Manually specifying an identity of some sort is going to be required. We
do not have single identities, and pretending we do is a recipe for bad
design. User interfaces can make things easy for the people who do use
just a single identity when multiple identities can be used. They can
not make multiple identities possible if the underlying system assumes
only one can exist.

U2F bypasses this one by automatically selecting a key based on the
domain used. (User interface. See?) Meaning that not only is it not
designed as a federating system, but that by design it cannot be used as
one.

> 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.
What are the enhancements, and how do you envision them working? You've
stated a couple of times that you're waiting to see a detailed summary
from others; where's yours? (I've only been here a couple months, and
may well have missed it if sent earlier.)

> 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.
OpenID is structured in a way which makes it possible for the identity
provider to monitor every instance in which the identity is used towards
a third party. That is a property not shared by Persona. Persona does
this by mediating things through the user agent, rather than
authorisation happening server-to-server. The proposal in the Identity
Credentials, if implemented as-is, has the same deficiency as OpenID,
though.

Leveraging the user agent in this way requires either a fairly trusted
crypto implementation accessible to JavaScript (which is being worked
on, I believe) or direct support in the browsers. U2F faces the exact
same situation. Is it more likely to get browser integration because of
Google's commercial interests in pushing it?

Oh, and also: OpenID uses URIs for identifiers. This means that it
doesn't solve the discoverability question that Persona does.

With greetings,
  Herbert Snorrason