Re: U2F Demo

On 2014-05-30 02:06, Herbert Snorrason wrote:
> On fim 29.maí 2014 21:13, Anders Rundgren wrote:
>> The demo describes quite well what U2F does, and how.
> Huh. Yeah, I'll admit I didn't watch it the first time around. Instead,
> I went and read a bit of FIDO's documentation. The actual spec is on my
> reading list now; if this tech actually gets deployed widely, it's
> definitely worth understanding. But none of that, including watching the
> demo, gives me the impression that U2F is able to do anything other than
> enable the user to authenticate against an existing user database.

Yes, this is the use-case that the established payment industry consider #1 with
respect to the user-side of things.  IMO, WebPayments do not have anything
similar meeting their (compared to PayPal much more advanced) use-case.

That's all I'm saying.

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.  There's IMO *no point whatsoever* "reinventing"
OpenID or try competing with OpenID.

Regards,
Anders


>   An
> important function, but only one step in federated identity. I do not
> see, for instance, how U2F helps you assert your identity with one
> service to another. That's what OpenID and OAuth are used for. (And note
> that it's OpenID in particular that Persona was gunning to replace, due
> to the blatant privacy problems of OpenID, which are features and not
> bugs to parties like Google and facebook.)
>
>> That the WebID and WebPayments groups (unlike the mentioned bunch of
>> mega-corporations
>> who put their money on U2F), do not have a useful and strong
>> client-authentication mechanism.
> Useful, perhaps not. Certificates are a shambles, and that's actually
> even more true of server-side certificates than client certificates. For
> client certificates, it's mostly the user experience that's broken. For
> the rest, it's the whole damn system. But that's another story.
>
> Persona, on the other hand, isn't client-authentication. What Persona
> does is enable you to prove that you're already logged in somewhere
> else. The duration that proof is valid is not controlled by the client,
> but by the identity provider. So you can use it to log in to a third
> party, but you still have to be logged in _somewhere_. Using U2F to log
> in there seems like a pretty good idea.
>
> The "detailed login example" in the Identity Credential document
> actually glosses quite glibly over this, but in between the "proper
> query" and final reply is a step where the identity provider decides
> whether or not to provide the information. How this process works is
> specified in some detail in the BrowserID spec.
>
>> Using U2F would be cool but I don't see how that could work.  If you do,
>> I suggest
>> writing a short paper showing how so we have something concrete to talk
>> about.
> My suggestion is that U2F is used by identity providers to handle the
> client login. Then you layer pretty much any federated protocol you care
> to mention on top of that. Persona, SAML, Kerberos. *shrug*
>
> Using WebID and Identity Credentials is much more about specifying a
> clear way to enable access to machine-readable user information than
> immediate authentication. Both say the identity should be a
> dereferenceable IRI, resulting in an RDF document containing user
> information. The difference is that WebID requires Turtle and suggests
> FOAF, Identity Credentials requires JSON-LD and seems to prefer
> Schema.org. Of course, that information may include stuff that is
> relevant to authentication. Such as public keys or their fingerprints.
> (Which is what WebID's certificate sign-in method relies on.)
>
> The "log in" proposal in Identity Credentials is actually not that; it's
> a proposed discovery system: "How do I get from an email address to a
> dereferenceable IRI for an authenticated user?"
>
> With greetings,
>    Herbert Snorrason
>

Received on Friday, 30 May 2014 06:30:02 UTC