Re: Proof of Concept: Identity Credentials Login

Not to mention that following the rise of the machines, my new digital cash
system will no longer be optional.  ;-)

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 Fri, Jun 13, 2014 at 2:28 AM, Dave Lampton <dave.lampton@gmail.com>
wrote:

> Hi Adrian,
> Yeah, I fully agree with your points in your #1, and I'm simply running
> with the idea while it's still entertaining me. :) The closest thing thus
> far is that ZeroCash protocol but at this point who knows how far any of
> those currencies may evolve, into some part of a long-term solution, or
> whether they will both have disappeared in two years? I agree that
> installing anything into government agencies will be like herding a nation
> of cats. And yeah, I imagine ALL bankers will feel more than a little
> nervous about the encroachment of these new machines & the threatening of
> the bankers' very need for existence. The banking industry will despise all
> of it. But guess what? The technology eventually sells itself every time.
> Presumably, at some point (but not any time soon) the world will be even be
> ready to go as far as abandoning physical money... maybe not. Maybe only in
> some places. We have no idea what's the future holds, but I have a feeling
> that getting from this stage to any kind of deployed system actually
> transacting *cash* in US dollars... we're talking decades! So, if we work
> hard it may be an official recommendation by then. ;-)
>
> 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 Fri, Jun 13, 2014 at 1:57 AM, Adrian Hope-Bailie <adrian@hopebailie.com
> > wrote:
>
>> Hi Dave,
>>
>> I think pursuing a better over-all system is a valid effort and I'm keen
>> to help if you ever want a sounding board or an argument :)
>>
>> My point is that there are two things that need to happen in parallel:
>>
>> 1. Invention
>> Invent better ways for payments to work.
>> Bitcoin, Ripple, DNS-based, distributed/federated systems etc. These are
>> all valid endeavours and are definitely disrupting the industry.
>> Using the concept of the Bitcoin block-chain for other distributed
>> systems is a great example of why this type of innovation is great!
>>
>> That said, the traditional centralised payment system is going nowhere
>> soon.
>> If we genuinely expect the world's national/federal reserve banks to
>> simply roll-over and hand control of the world's finances to a bunch of
>> distributed systems I think we are being very naive.
>> I suspect that over time the two systems (modern/distributed and
>> traditional/centralised) will start to merge and that is where I hope
>> standards will become relevant and facilitate innovation.
>>
>> 2. Standardisation
>> While the innovators innovate we can still look at the current status quo
>> and identify problem areas or areas where standardisation will improve the
>> status quo and develop those standards.
>>
>> My understanding of the way the W3C works is that nothing becomes a
>> standard until it's actually being used or at a minimum there are working
>> POCs so innovative ideas are going to take a long time to become standards
>> if they are too disruptive (that is not to say they shouldn't become
>> standards eventually).
>>
>> My suggestion is that the payment process be broken down into a generic
>> state-flow and we look at ways to standardise each step and not the whole
>> end-to-end process.
>> (This seemed to come up in a number of the conversations at the workshop
>> in March).
>>
>> At the end of the day, payments work right? Most of us are able to
>> perform a payment.
>> The friction is mostly due to interoperability (inter-bank), security and
>> regulatory issues.
>> Exactly the kind of issues that good standards address.
>>
>> My suggestion would be to take all of our use cases on the wiki and pull
>> the elements from them that are common to a specific stage in the payments
>> process and then focus on standardizing those stages.
>> Where the scope starts to grow too big explicitly make the standard
>> extensible to handle a broader range of use cases and new standards that
>> extend the base standard for those scenarios.
>>
>> I started writing these stages out here but it's becoming a long list.
>> Will kick off a new thread to discuss these in detail and get feedback.
>>
>> Adrian
>>
>>
>>
>> On 12 June 2014 18:18, Dave Lampton <dave.lampton@gmail.com> wrote:
>>
>>> Hi guys, I half expected to get flamed this morning for introducing way
>>> too much noise to the conversation, so thank you for being polite!  :-)
>>>
>>> Adrian, yes, I think you're absolutely right. My proposal probably DOES
>>> belong under IETF considerations not W3C. (It's been years since I've
>>> participated at all with any of these standards groups.) In fact, I was
>>> initially just thinking my end result was going to be a simple new PROTOCOL
>>> for monetary transactions running on a *privileged port* (which also
>>> requires an IANA assignment) - clearly IETF territory. But once I started
>>> thinking that I'd rather just piggy-back onto wss:// (WebSocket+TLS) I
>>> stopped thinking about the port, just assuming I'd be using TLS/1.0 +
>>> HTTP/1.1 on an upgraded port 80. I also initially looked at *the four
>>> new *Resource Record types provided by DNSSEC, but yeah I will try SRV
>>> - that looks like the right way to do things going forward. Thanks.
>>>
>>> I too am still not convinced identity is always a necessary component
>>> either. Especially if using a trusted channel. If the channel itself
>>> identifies the payer, the payee has enough to record the debt as paid.
>>>
>>> Being so unsatisfied with the present ecosystem and intending to
>>> eliminate the need for any third party involvement in transactions, I was
>>> never actually intending to attempt to integrate with the existing
>>> proprietary or closed payment channels but would instead seek to create a
>>> more appealing solution that they will want to migrate to simply because it
>>> would be the simplest, and most universally useful Open solution.
>>>
>>> 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 Thu, Jun 12, 2014 at 5:08 AM, Anders Rundgren <
>>> anders.rundgren.net@gmail.com> wrote:
>>>
>>>> On 2014-06-12 09:32, Adrian Hope-Bailie wrote:
>>>>
>>>>> Hi Dave,
>>>>>
>>>>>  <snip>
>>>>
>>>>
>>>>> I believe a greater discussion is required around what constitutes an
>>>>> effort to "standardise" and what is actually invention of completely new
>>>>> ideas. If there is to be a standard developed that marries the Web Platform
>>>>> with the traditionally closed and proprietary payments ecosystem it will
>>>>> need integrate better into existing payments channels and not simply
>>>>> propose to replace everything.
>>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>>  I also think there needs to be more discussion about whether identity
>>>>> is that important. If a payment is initiated by the payer via a channel
>>>>> they trust (internet banking, wallet app etc) and the payee simply receives
>>>>> a digitally signed proof-of-payment if the form of a receipt from an entity
>>>>> they trust (their payment gateway, bank, wallet provider etc) why does the
>>>>> payee need access to the payer's details at all?
>>>>>
>>>>
>>>> +1
>>>>
>>>> Anders
>>>>
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>>
>>>>> On 12 June 2014 03:30, Dave Lampton <dave.lampton@gmail.com <mailto:
>>>>> dave.lampton@gmail.com>> 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). 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 <http://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/ <http://www.linkedin.com/in/
>>>>> davelampton/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     On Wed, Jun 11, 2014 at 3:03 PM, ☮ elf Pavlik ☮ <
>>>>> perpetual-tripper@wwelves.org <mailto: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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>

Received on Friday, 13 June 2014 09:32:17 UTC