Passcard
passcard.info
passcard.info
"Introducing your passcard!", "Choose a registrar", "Your all access pass to everything.", "A system giving users control of their identity."
I still have no clue what this thing is, or why I would want it.
http://blog.onename.com/passcards/
This was submitted to HN earlier in the morning [1]
The idea is to give you back control of your online identity, which you currently do not own (you either rent or borrow it from companies like Facebook and Twitter). With the blockchain, you can actually own your digital identity.
Onename will (hopefully), remain a "default" but not essential intermediary.
Passcard will hopefully replace login systems like Facebook Login, Twitter Login, etc.
Info: I do not work for Onename, I am not paid by them, but I collaborate with them because I believe in the importance of decentralization and they are helping with that.
https://github.com/okTurtles/blockchainid
And BitAuth:
EDIT: I see there is an FAQ page if you click on the "☰" at the top. It is mostly just as vague, though it talks blockchains -- something I'm very unfamiliar with. Is it to be assumed that this is a product for very specific tech people who are familiar with blockchains?
> "At first, you'll be able to present your digital passport when logging into applications, and eventually you'll be able to use it when asked to present identification in an in-person context (as you would with a passport or driver's license)."
Pragmatically, it seems like a good idea. It just makes me nervous.
What everybody misses with the whole "Too many cards in our wallets" 'problem', is that there's utility in having multiple cards in your wallet. My wallet isn't just a place to store cards, it's a physical interface designed to make it easy to pick the right card quickly.
If you replace that all with one card then sure, you've solved a (very tiny) problem, but unless that device's interface does a better job than my wallet does with letting me pick the card I want to use instantly and clearly, then it's simply a non-starter.
Is this where we're headed? Take any idea, then tack on "stored on the blockchain" to the end?
"Uber for x, blockchain, anonymous, ephemeral" -> the evolution of "Social/Local/Mobile"
Is this where we're headed? Take any idea, and then tack on "on the internet" to the end?
Yes, that is exactly where we're headed. New and interesting technologies have a way of having very broad use cases.
* ONENAME
* NAMECOIN
* NOPE
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.
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.
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.
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?
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.
So what is Passcard.info for?
Onename, which has designed Passcard.info, is attempting to standardize the identity protocol by decoupling it from its core identity registration service.
A somewhat fragmented space, here's an example of another blockchain based identity protocol using the id/* namespace on Namecoin: https://nameid.org/?name=domob
Note: I'm not trying to shit on the project (just as I'm not trying to shit on your comment). I'm sure it was a substantial amount of work, and is at an early stage in its development. If, however, one is launching a project that has non-technical folks as its audience, appropriate documentation is just as important as the software.
No part of your car would need gasoline if it were designed in a way not to need gasoline. But it does.
It's your fault. Esp. since many sites are using stuff like AngularJS now.
:(
[1] Not sure, because of lack of information on the site.
I have a gambling problem. I store my banking information in my Passcard tied to my iWatch. I don't pay my bookie. He beats the crap out of me and takes my iWatch along with my banking information. Am I broke now?
The concept of a single, verified digital identity is going to be an even harder sell now than it was ten years ago, with people concerned about governments spying on their online activity. People are trying to be more anonymous, not less.
I'm going to sign up for an account anyway because I'm a sucker for new digital identity solutions. And I might teach myself Python to contribute some code. But I don't see what's going to drive Passcard adoption. Microsoft couldn't even sell the concept of identity cards in their heyday.
As of a year ago when I was working for a company trying to make pretty much this exact product, the prevailing wisdom was you'd secure it with biometrics (for those of you wondering how you'd secure it if your bookie beat you up and stole your iWatch).
Why it won't work, and why it didn't work for the company I worked for (and why I got laid off), and why it will probably never ever work in the way that everyone envisions is that getting all these disparate entities to agree to utilize this one app for access management just WILL. NOT. HAPPEN. As a company trying to build an app like this, you have to negotiate with every entity separately- so you have to negotiate with every state separately if you want to display state IDs on a mobile phone and have that be an accepted display method (didn't work- they wouldn't even talk to us). You have to negotiate with every separate credit card issuer who are all working on their own "Use your mobile as a credit card" idea. You have to negotiate with every separate access management company (Assa Abloy, etc etc) who are all ALSO working on their own mobile app to replace keycards... and on and on and on.
Plus then on top of all that there's Apple, who wants the mobile phone to be the ubiquitous access device more than any other company out there, and who actually has the time and the money and the chops and the influence to make it happen, if anyone can make it happen. It's an impossible goal right out of the gate, and if you scale down the operation at all (focusing on logical access instead of logical + physical, for example) there's already an app that does it and does it better and has been doing it for longer.
AND THEN you get to the consumer side of things where instead of simply typing in a username and password to get into a website (the standard way) or whacking your iPhone a preset number of times (as with Knock) you have to pull out your phone, unlock your phone, go to the app, scan the QR code or whatever, and then hope that the servers haven't crapped themselves for the tenth time today and will let you log into your damned computer already.
No, I'm not pessimistic, why do you ask?
[1]https://itunes.apple.com/us/app/knock-unlock-your-mac-withou...
I like DNS, but unless you're big enough to raise your issues personally with the registrar and get heard, I wouldn't use it for any kind of auth.
How is this decentralized if the registrar issues your secret keys for you? Couldn't they hijack your identity at any time?
It sounds more like a federated system of identity providers like OpenID.
If there's no fallback for something as simple as a web page, I dread to think how well the 'all access pass' works under stress.
i own passcard.id (and some other .id such as awesome.id, privilege.id and printed.id), contact me at my username at gmail.com if you're the maintainer and interested in acquiring it.