Re: Proof of Concept: Identity Credentials Login

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). Likewise, I don't want to conflate the conversation too
much with my own ideas for implementing "digital cash" transactions, so you
can take my comments with a grain of salt, at least for now. :-)


To me, the proposed system already just feels overly complex for the tasks
at hand - lots of moving parts, several steps involved. I'm all for using
existing open standards, but it seems like we may be limiting ourselves (or
rather, complicating the problem, I think) instead of simply inventing only
what's really needed.


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). 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.


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


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. Using the browsers as
secure endpoints seems like an even worse idea, regardless of who suggested
it all the way back in 1990. ;-)  Browsers are too transient or inconstant
for my taste, and again, multiple instances can be running simultaneously
on a host. If used properly they could work fine, I suppose, but they are
also a piece of software which means they are also game-able, open for
abuse, emulation, fraud.


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).


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"
for example. An FQDN is simply an assigned hostname controlled by the
domain owner, who can point it at any host or device on his or her domain
subnet, by using DNSSEC <http://www.dnssec.net/>, specifically (i.e.we
would probably need to insist on the adoption of Secure DNS, since standard
DNS has known security flaws). 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. No password needs to be
known or saved by the stupid humans. (No passwords using "123456"!) Thus
far, I'm yet to be really convinced any separate IdP is even required once
endpoints are secured by a unique hostname (FQDN)... more discussion on
that later(*).


Someone asked:
> How will the request to this identity provider location/URL be
authenticated?
So my answer to this is simply to use ZoneSigner
<https://www.dnssec-tools.org/wiki/index.php/Zonesigner>, a DNSSEC tool
used to secure the reverse delegations.


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.


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. 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. 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.


Now, in my own proposed (work-in-progress) solution, something akin to your
"Telehash" service would be hosted by the clearing house / central bank of
the corresponding currency itself and is responsible for auth/auth of
incoming requests for services, the immediate transaction approval or
disapproval, the immediate processing of each of those transactions, and
the updating of the public distributed database which keeps tabs on each
outstanding piece of currency (after already publicly invalidating the
previous FQDN's ownership hash for that unit of currency prior to
generating and publicly sharing the newly signed ownership hash. Anyone can
test any piece of currency in the marketplace at any time, but only the
current owner will get a matched signature, because their FQDN was used to
generate the current hash value stored with the currency's serial number in
the publicly distributed database.


(*) A bit more discussion: an FQDN is literally as close as we get to
something physical on the Internet because it IS physical and relatively
static. By attaching software objects to FQDN's we achieve a "physicality"
presently missing in the digital realm. This physicality implies true
uniqueness at all times - just like real cash. A digital entity (in this
case, some unit of digital cash) can move in the digital universe only when
a transaction is approved and executed, and may only exist in one place at
a time (namely, its current, pre-approved home). This is what is required
for money to only belong to one individual (account) at a time, only after
issued a new UUID and after previous incarnations have been publicly
invalidated already and marked for removal at some convenient time. Perhaps
Dave Longley's last comment alludes to this but I would emphasize that no
separate IdP is required - one's clearing house or central bank for the
currency being held in a particular wallet effectively becomes the IdP.
Each wallet can only hold currency issued or managed by the clearing house
/ central bank that issued that money (accounts themselves acting here as
the user's identity service provider). I think this concept of physicality
can (and should) be expanded to lots of other "nouns" that we would like to
have live in only ONE place at a time in our digital universe (the whole
Net or perhaps just a local subnet). As long as each one is *uniquely*
attached to a FQDN (or another software object that is already attached to
a FQDN, potentially ad infinitum...) and each previous instance (in some
other physical location) has been publicly invalidated before the newly
created instance arrives in its present destination, then we can trust its
uniqueness.


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.


Cheers. ;-)





Dave Lampton
* @dave_lampton <https://twitter.com/dave_lampton>*

* DaveLampton <https://www.facebook.com/DaveLampton> +DaveLampton
<https://www.google.com/+DaveLampton>*
www.linkedin.com/in/davelampton/




On Wed, Jun 11, 2014 at 3:03 PM, ☮ elf Pavlik ☮ <
perpetual-tripper@wwelves.org> wrote:

> On 06/10/2014 06:25 AM, Manu Sporny wrote:
> > TL;DR: There is now an open source demo of credential-based login
> > for the Web. We think it’s better than Persona, WebID+TLS, and
> > OpenID Connect. If we can build enough support for Identity
> > Credentials over the next year, we’d like to standardize it via
> > the W3C.
> Congratulations!
>
> I find it very impressing especially since you got running pushed to a
> public repo - kudos++
>
> First question coming to my mind:
>
> "The way that both Mozilla Persona and OpenID do it is fairly similar.
> OpenID assumes that your email address maps to your identity provider."
>
> In my case, and I believe nowadays quite many other people, I control
> domain which I use for email address. With simple DNS configuration I
> use different 'providers' for my email server and my web server (here
> myself).
> In this situation I find using webfinger[1] (also used by OpenID
> Connect), more attractive then hiding from myself via
> http://login-hub.com - even if His Holiness @Pontifex with His Holiness
> @DalaiLama would run it very carefully together ;)
>
> I still need to take some time and wrap my head around your design but
> maybe you could easily evaluate complexity of including webfinger based
> flow as an alternative option for those who may prefer such setup?
>
> Once again - GREAT WORK!!!
>
> [1] http://webfinger.net
>
>
>