Re: U2F Demo

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!

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.

Regards,
Anders

Received on Saturday, 31 May 2014 07:42:20 UTC