Re: Proof of Concept: Identity Credentials Login

On 06/11/2014 09:30 PM, Dave Lampton wrote:
> Hi all, I am still relatively new to this group and trying to catch
> up with the work that has been done thus far on Web Payments, and
> I'll be the first to acknowledge that I may have still missed some
> important details (but I don't believe so).

I think you have (missed some important details). :)

Here are two of them that I think you missed:

* The Web Payments stuff we're working on right now isn't really
  targeted at solving the payments clearing problem (Bitcoin, Ripple,
  Zerocash, and Ethereum are in the business of doing that).
* Email addresses aren't required for the Identity Credentials stuff to
  work.
* DNSSEC doesn't protect against pervasive monitoring/tampering.

> TL;DR - I'm with Melvin Carvalho and his comments made yesterday re:
> his fundamental dissatisfaction with 3rd party identity solutions
> (even just the concept of a 3rd party doing this for me is
> troublesome).

You don't have to have a 3rd party to do this for you w/ the Identity
Credentials design. Why do you think you need a 3rd party identity provider?

> I'm largely unsatisfied with the various identity systems already
> competing - they are not particularly fun or easy to work with, and
> the one you need today is usually that one you've never needed to
> look at before today.

Not enough information here to respond, mind elaborating?

> Additionally, I still feel uneasy about using email addresses at all
> in any sort of next-gen payment system, but especially if the real
> goal is to ultimately just attach to browsers/devices anyway.

If not email addresses, then what? Where in the process are you not
comfortable with email addresses? Are you aware that you don't need to
use an email address (with the Identity Credentials stuff), but could
instead just use something like "DaveLampton" or "Dave"?

> This "shim" already sounds like something we would prefer to throw
> away, so then, let's just leap-frog it altogether.

Which "shim" are you talking about, there are a few of them (mostly in
places where we're expecting eventual browser support)?

> Furthermore, I agree with a few others that URI's are wholly
> inadequate in the role of endpoints because more than one can be live
> on the same host and therefore they invite people to potentially host
> multiple people's money (and the transactions thereof) on a single
> host or device, which just seems like the quick road to widespread
> corruption.

I don't follow. Facebook and Google can host multiple accounts on a
single domain, is there widespread corruption there? What sort of
corruption are you talking about? Won't the most corrupt players be
weeded out of the market the second the public finds out?

> And while I'm complaining about everything, I'll even point out that
> our de facto API these days, a RESTful interface, is also overkill
> for the very few types of messages we actually need to pass around. I
> find that the problems can be solved with a small set of JSON-LD (or
> BSON-LD?) messages (representing individual sets of currency units
> and the transactions intended to be applied to them) which can be
> passed around over secure Web sockets (wss:// protocol over port
> 443).

Why not HTTPS, isn't that simpler? Isn't Telehash even more simple and
secure? Why Web Sockets?

> So... in my mind, it seems our digital "wallets" or "accounts", or 
> whatever we call the things that send and receive transactions and
> are the "physical" homes for our digital money, should each only be
> assigned to one and only one *fully qualified domain name* such as 
> "usd1.davelampton.com <http://usd1.davelampton.com>" for example.

You've just opened yourself up to attack, haven't you? That requires
DNS. Your domain can be spoofed or taken away from you by a variety of
governments. It's also very easy to attack, even if you use HTTPS.

How are you staying in compliance with Know Your Customer and Anti-Money
Laundering regulations? Have you talked to any central banks or policy
makers about this approach?

> A new type of resource record would need to be used, perhaps a "CTX"
> record for "currency transaction exchanger"? Anyone controlling a
> FQDN controls the (necessarily homogeneous) currency units (money)
> held in the one CTX residing there, period.

So, in this case, if you have a .com domain, then ultimately Verisign
(and the US Government) controls all of your currency units since it's
they who have ultimate control over what the DNSSEC entry states. The
public/private keypairs aren't going to give you any sort of protection
from a government (or corporation) that doesn't like your government (or
you).

Bitcoin, Zerocash, and Ripple provide protection against this sort of
attack by not placing the trust in a place that can be easily spoofed.

> When an end user creates an account with the clearing house (or
> central bank, or whoever is clearing transactions on that currency),
> a new unique keypair is generated and assigned - private keys saved
> and public keys shared only by those two parties. One unique keypair
> per CTX account - and only one CTX account per FQDN.

It seems like you are assuming that many people have access to DNS (or
even know what it is). We're trying to build a solution that could scale
to the 3 billion plus people that will be online in the coming decade.
How are each of those 3 billion plus people going to put DNSSEC entries
into the global DNS?

> In general, the Peer-Assisted Key Derivation Function (PAKDF) as 
> suggested by Evan Schwartz is a great solution for turning a weak 
> password (the kind humans can remember) into a strong signed key.

+1, we should probably move to something like that in the future. We
didn't in the first iteration of the Identity Credentials stuff due to
lack of time.

> If a unique keypair is generated by the clearing house / central bank
> for that currency and then assigned to the corresponding
> account/wallet nobody else will ever know or manage any server or
> account/wallet passwords other than for server/endpoint
> administration, perhaps.

It sounds like you think that a password is required for the Identity
Credentials stuff to work (it isn't, that's just how it's implemented
right now... and we use the password as a part of a key-derivation
function). We could swap it out for a PAKDF, or some other KDF.

> We can thus begin and end with strong keys and not bother with the
> human incapacity for remembering important things. I don't think it's
> even necessary for anyone to know a password other than possibly for
> the Web-based administration interface to manage the hosted
> transaction services.

I'm at a public terminal and I need to send someone money, how do I do it?

> OK, I'm probably rambling now... while I could go on and on, I've 
> probably already ruffled more feathers than perhaps I should in one
> day.

I'm having a hard time understanding the benefits of what you're
describing to, say, Ripple or Ethereum since both of those systems seem
to have most (if not all) of the benefits and none of the drawbacks of
what you're proposing. Could you perhaps clarify what problems with
those systems you're solving?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Sunday, 15 June 2014 21:35:52 UTC