Re: U2F Demo

On 5/31/14 2:30 PM, Dave Longley wrote:
> 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.

+1

There is no other architectural path to a solution in regards to:

1. broad adoption
2. scalability following adoption.



-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen