Because it provides a decentralized mechanism to verify things without a central authority? It may or may not be the future, but it's pretty much what we have right now.
The key difference is that Passcard requires a quorum of mutually-distrustful blockchain peers that attest to the validity of your public keys. We believe this is a much stronger guarantee than a web-of-trust, since it (rightfully) does not assume that trust is somehow transitive.
I guess I don't understand specifically why a distrusted "blockchain peer" is superior to a distrusted peer's digital signature.
The way I see it, blockchains use proof-of-work to enforce/record transaction sequences. It not clear to me what use transaction sequence is for establishing identity. If I'm looking for a quorum of distrusted endorsements, I just want to know how many endorsements exist, right? Where's the use of the transaction sequencing? Proof-of-work doesn't make one endorsement more trustworthy than another, does it?
Blockchains don't look at how many transactions an address has performed except to compute available funds for the transaction--otherwise they just check the signature validity. It's just not at all clear to me what's even trying to be achieved here.
The intuition is that the cryptocurrency miners act as a large decentralized first-come first-serve notary for the transactions they append to the blockchain. If a peer submits a valid transaction and it gets included in the blockchain, it means the majority of the other peers have accepted the transaction as valid and will continue to serve it to other peers. As a side-effect, any data within a transaction gets included and served as well, and (this is where the proof-of-work comes in) it cannot not be retroactively altered without first retroactively altering the blockchain itself.
Onename leverages this fact to bind your human-readable username to the hash of your passcard in a first-come, first-serve basis. When you sign up for a passcard, the (username, passcard_hash) tuple gets submitted to the blockchain as part of a valid transaction, so that once the transaction gets accepted, the peers will continue to preserve this information. There's similar process for changing name ownership and revoking names and credentials.
The trust you place in the validity of Onename records on the blockchain comes from the steep cost of silently altering it. You have to launch a 51% attack to alter it at all, and you have to alter every local copy of the blockchain without drawing notice to do so silently (otherwise, a fork will be observed). This means once you're committed the requisite information in a transaction, there's a good chance it will persist.
The situation is much more fluid with PGP, since the number of endorsers can be somewhat smaller than number of miners, and there's no guaranteed "paper trail" of what bindings have have processed (thereby making silent alterations easier to come by). Moreover, trust is not transitive--Alice trusting Bob and Bob trusting Charlie does not imply that Alice trusts Charlie--so the degree of trust you get from a web-of-trust is hard to quantify even in the absence of malicious behavior. This in turn makes it hard to reason about the strength of your endorsements, as compared to the strength of your adversary's claims against you.
At the end of the day, Onename gives me the ability to say "I am jude-, and my passcard is ..." in a non-repudiable manner, and I can quantify how strong of a testament it is by measuring the blockchain's hashing power versus my adversary's hashing power. The passcard itself is stored elsewhere (but its hash is incorporated into the blockchain), but the passcard can include information like your public keys, your identities on other services, hashes of digital assets you created (e.g. pictures, documents, etc.), and so on.
That is a flawed intuition and seems to misunderstand how bitcoin and namecoin fundamentally work. I don't have any reason to care when a trusted or untrusted notary endorsed someone's identity. Particularly if they aren't doing any sort of identity validation at all.
Miners don't verify anything relating to identity beyond the correctness of the digital signatures vs signature hashes. So miners hashing on something doesn't represent any sort of endorsement that I should recognize at all. I don't see why I should trust one signature that appeared deeper in the blockchain vs a newer signature? Older addresses are less trustworthy in bitcoin not more, that's why we use change addresses.
Sorry, this just makes no sense to me on a very basic level and I don't think you're answering any of the fundamental questions. Even in bitcoin, proof of identity goes into the encryption, not the proof-of-work. These are fundamentally different beasts.
> I don't have any reason to care when a trusted or untrusted notary endorsed someone's identity.
Sure you do--you're doing it right now :) This is how usernames on websites work in general. The reason why someone besides you cannot create an account on HN with the username "fluidcruft" is because names are unique on this site, and you claimed it first. You, I, and the rest of the commentators here trust HN to ensure that this is the case for everyone--we each have the usernames we have because we claimed them first. I must emphasize that this is orthogonal to authentication; this is simply about preserving a common property of typical user account systems.
The goal of Onename is to provide a user account system that binds usernames to personal data of your choice without needing a central administrative entity to enforce the above property. Instead of everyone trusting servers controlled by a single administrative entity (like HN), we instead trust that the underlying storage medium that hosts each (username, principal) binding has the property that once a record of a binding gets written, it cannot be altered later. In the absence of compromises, the overall effect is the same as on HN--usernames are globally unique, and are bound on a first-come first-serve basis to principals.
You seem to be thinking that we're relying on the blockchain to do some kind of extra user validation. This is not the case at all. We're only using the blockchain to provide a highly-available write-once read-many (WORM) storage system for (username, passcard_hash) bindings. What I've been trying to argue is that the degree to which we can ensure immutability hinges on the WORM property holding true for the foreseeable future. My point was that there is reason to believe that a blockchain with many peers has the WORM property because by construction, it's costly violate this property, it's very difficult to violate without drawing attention to oneself, and it's financially desirable to to preserve anyway--the WORM property also guarantees the immutability of transaction histories. This is what I meant by "the blockchain peers attest to the bindings"--by mining blocks and constructing the blockchain, they're preserving the property of the blockchain that makes it useful for constructing a decentralized user account system.
Because of the WORM property, you're guaranteed that the first occurrence of a (username, passcard_hash) pair you find for a given username was issued by the owner of that username. Any subsequent attempts at writing a different passcard_hash for that username can be ignored (preserving global uniqueness). Unless you can attack the underlying blockchain, you cannot trick someone else who audits the blockchain into finding a different original passcard_hash for the same username (ensuring everyone finds the same original username/passcard_hash binding).
Does this make a little bit more sense? Does this help you understand what it is we're trying to do?
Basically, you're using the blockchain as a decentralized passwd file. But again, I don't see why this is desirable in light of existing and much more powerful alternatives to passwd files (U2F for example)?
> Basically, you're using the blockchain as a decentralized passwd file. But again, I don't see why this is desirable in light of existing and much more powerful alternatives to passwd files (U2F for example)?
Not quite. To use a UNIX analogy, we're using the blockchain to bootstrap a global, decentralized LDAP. We're making it so applications can resolve a username to its owner's information without users needing to trust us, without applications needing to trust us, and without users needing to trust applications.
Now, my "LDAP entry" (i.e. my passcard) can contain whatever information I want to put there. Anyone can verify the authenticity of subsequent updates to my passcard data by verifying that each update was signed by the same private key whose public counterpart got bound to my username when the passcard was created.
I could put information in my passcard that further identifies who I am, and I could put information that authenticates me to certain applications. These are some of the key use-cases of my passcard. However, what this information is exactly depends on the application. The only thing Onename concerns itself with is ensuring that the application can discover this information when given the username, and be assured that the information was generated by the same principal that owns the username without having to trust Onename or the user.
