Re: U2F Demo

On 31 May 2014 20:30, Dave Longley <dlongley@digitalbazaar.com> 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


>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
>
>