Re: U2F Demo

On 05/31/2014 03:41 AM, Anders Rundgren wrote:
> On 2014-05-30 16:25, Dave Longley wrote:
>> On 05/30/2014 02:29 AM, Anders Rundgren wrote:
>>> 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.
>>
>> Suppose:
>>
>> 1. You register with an Identity Provider of your choice using your
>> browser. Your Identity Provider may/may not use U2F or some other
>> mechanism to register your device. Your browser, if it supports this
>> feature, will remember your Identity Provider.
>>
>> 2. You visit some other website you'd like to log into to get access to
>> their services.
>>
>> 3. When asked to login, your browser contacts your Identity Provider to
>> authenticate you. If your browser does not yet support this mechanism, a
>> login shim is provided by the website you're trying to log into. The
>> shim accesses a trusted third-party site to provide you with an
>> appropriate interface to your Identity Provider.
>>
>> 4. Your Identity Provider may/may not require 2-factor authentication.
>> If it does, and your device (or browser, etc.) is registered, login will
>> happen immediately, without the need for any username/password. It is
>> likely that people will choose Identity Providers with N-factor
>> authentication options because it provides them with extra security.
>>
>> 5. Your Identity Provider transmits some credential, with your approval,
>> to the relying party (the original site you're trying to log into) which
>> is used to authenticate you and provide you access to the service.
>>
>> Note:
>>
>> 1. There is no NASCAR screen. Your browser knows who your Identity
>> Provider is. If your browser doesn't yet support this protocol, then the
>> third party shim executes a discovery query to determine who your
>> Identity Provider is for you, based on your email address and a
>> passphrase that is only used for this discovery purpose.
>>
>> 2. This is fully compatible with a distributed use of U2F. You only need
>> to use it at your Identity Provider and any Identity Provider may
>> implement it. A digitally-signed credential is provided by your Identity
>> Provider to some other relying party to provide the appropriate level of
>> authentication there (no U2F registration is required at the relying
>> party).
>>
>> 3. If your browser can't yet obscure information about the relying party
>> from your Identity Provider, a trusted "login mixnet" can be provided to
>> intermediate communication between your Identity Provider and the
>> relying party in order to protect your privacy.
>>
>> Much of the above comes from the "Identity Credentials" proposal that
>> has been discussed on this mailing list. We have also discussed using
>> "Telehash" as part of a solution to provide an Identity Provider
>> discovery mechanism that solves the NASCAR problem.
>>
>> I don't believe any of this to be incompatible with U2F, and if Identity
>> Providers want to use U2F, they are more than welcome to; it is likely
>> value-add for their customers.
>>
> 
> Thanx David for the elaborate write-up!

You're welcome, I hope it cleared up some of the strategy/design goals.

> 
> I understand what you are writing but still do feel a bit confused about
> WebPayments fixation with identity and identity providers.  In my world
> payment providers are rather in the center.  They typically want customers
> to authorize transaction requests.  3D Secure is my starting point which
> may explain why we seem to end up with different tools and concepts.

The idea is that ensuring a person's identity need only be loosely
coupled with their payment provider is an important feature of a
payments system that is intended to fit in with the rest of the Web.
That means talking about "Identity Providers", not just "Payment
Providers". We need to address the "Identity Problem" because it is
important for payments, however, Identity touches many different areas
of the Web, not *just* payments.

This is about creating (or preserving) appropriate abstractions and
expanding choice so that a person may *either* choose to have a separate
Identity Provider (from their Payment Provider), or they may use a
service that acts as both. We're trying to ensure that various component
pieces can work both on their own and together. This approach, in
general, yields a better overall design (eg: reusable components) and it
has the potential to protect against various failure scenarios or spec
holdups during the standardization process.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Saturday, 31 May 2014 18:30:24 UTC