Re: Proof of Concept: Identity Credentials Login

hi Tim,
yes, I may need to depart from this group soon as I agree my goals extend
beyond just Web, and while I'm not sure if it will end up as a protocol, it
might just be a "service specification" for every "wallet" endpoint - would
likely belong with IETF.
I'm calling it 'cash' only because two entities will be able to conduct a
transaction without a middle-man, nobody ever taking a piece of the action.
these transactions occur in real time and are as final as handing someone a
paper bill
I won't be printing any paper receipts, but details are always available -
just point your browser at your wallet's FQDN.
I'll want to specify the software stack at the endpoints, which may be
spec'ed all the way to bare metal
rather than having many use cases that resemble "making an operating system
with better GUI",
I'll have a small handful of use cases that more resemble the simplicity of
flushing a toilet. :)
well, identity displacement seems adequate, but I doubt my system will even
include any concept of Identity
I'm not really concerned with anonymity at the time of the transaction, but
instead simply concerned
with ensuring that "money has no memory"
"I must always be able to track my spending, but my spending should never
be able to track me"
Adrian was right that the scope and goals of my project are broader than
just Web
I'll probably need to revisit the creation process for a new protocol under
the IETF (check back with me in 50 years! ;-)
There is a crypto-currency called ZeroCash (which is based on BitCoin) and
is really quite close to reaching all of my intended requirements, however,
my intent to be capable of transacting with a nation's real currency as
issued by their central bank.
I fully understand the issues involved in managing your own FQDN but we
don't have the same goals. I won't be developing a lightweight payment
system, but instead, more like your own fully-capable business checking
account (but without the bank, and hosted at home, perhaps) by an
individual who actually *needs* all of that extra functionality and is
capable of managing his registrar and his DNS. In any case, IPv6 is around
the corner and every man woman and child on the planet will have
<some_huge_number> of IP addresses at their disposal. I imagine that
managing one's registrar and configuring one's DNS for each wallet endpoint
will be about as complex as buying yourself a wallet. also, trivial &
common enough that having them managed and/or virtually hosted for you will
be so common that the expenses will likely be tiny fees, or you can set one
up on your smart phone. etc. not only will more & more "average citizens"
be able to do these things, but there will also be plenty of cheap
hosted/managed solutions available.

Dave Lampton
 @dave_lampton
www.linkedin.com/in/davelampton/


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 11:12 PM, Tim Holborn <timothy.holborn@gmail.com>
wrote:

> I can, and will write a volume or two about this area (identity, privacy,
> anonymity, etc.): however, figure it’s not something for the list, and in
> any case; it’ll need some editing…
>
> When the terms ‘digital cash’ and ‘anonymity’ is concerned; are you
> talking about entirely anonymous? or identity displacement?
>
> Perhaps as an exercise; consider the instances where your identity as a
> purchaser, or payee becomes ‘anonymous’ (meaning, cannot be proved); vs.
> those where identity remains intact throughout the lifecycle of what
> #upaid4  or #uvoted4
>
> Could be retaining a readable receipt (i.e. not thermal receipt printing)
> from a retailer.  Could be something that forms the world of online
> content, could be an email with a proposal put into a powerpoint or
> business plan format. Many use-cases….
>
> Another good activity; is looking at the manifest forms of social-policy
> decisions made; that could benefit if you a. had data relating to your
> economic footprint, and b. were entitled to actively share elements of that
> data, in a structured format; as to support research.
>
> Whilst I absolutely believe enormously beneficial to encouraging users
> with an Email Address - to migrate towards owning and operating their own
> domain - it’s not specifically within the ‘domain’ of web-payments.
>  Perhaps it’s something that could be formally supported by the group;
> should an appropriate group become recognisable, in how to push that form
> of promotional activity (Not for profit styled) to web-users.  I also think
> part of that function, requires improvements to traditional
> domain-management tools.
>
> A bit like making an operating system with better GUI.
>
> On 12 Jun 2014, at 11:30 am, Dave Lampton <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"
> 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
>>
>>
>>
>
>