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