Passcard(passcard.info)
passcard.info
Passcard
https://passcard.info/
27 comments
Why are major app vendors going to deploy another federated identity system that virtually none of their users will use? OpenID was a fiasco. This seems even more complicated than OpenID; at least in OpenID, there were huge sites you already used that could serve as anchor identities.
How is this different from iNames, OpenID, CardSpace, and all the decentralized identity platforms that came before it? Federated identity isn't anything new, and throwing a blockchain behind it is just an implementation detail.
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.
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.
One thing which I don't get is why the DNS system isn't used as a authentication system. A domain name is really cheap these days and it is a great way of authenticating. It just requires some work to interface with public keys. Maybe you can set your public key at the registrar?
DNS is not encrypted, not authenticated, can be spoofed and someone can hijack your authentication by hacking one company or exploiting some issue where the domain gets the ownership transferred forever... (or with months-long dispute time potentially) And that's before we go into most domains being owned by the US, other domains having interesting restrictions on usage and content, etc.
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.
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.
"When you sign up for a passcard, your registrar will give you a secret key"
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.
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.
Such great modern web design - no Javascript means a plain white page.
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.
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.
No idea what it is but I reserved my username in case it becomes a thing
I assume it is no coincidence that I read about this on the same day that Microsoft published that Microsoft Passport will be integrated in their new browser.
not really talking about the idea behind it, but why .info?
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.
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.
Everybody should be their own registrar! Decentralization! Hurrah!
This is an interesting idea, but every time I see these sorts of "reduce the number of items in your wallet, passwords in your brainbank, and keys on your keyring" products my knee-jerk reaction is, "okay, so now all an identity thief has to do is take my one item/password/key and they have access to my everything?"
The pain points you listed there are a lot different. Passwords are a huge pain. I don't mind having multiple cards in my wallet or keys on my keyring.
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.
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.
Yeah, that is my concern as well. I think the idea here though is more like a Mozilla Persona service via Namecoin
Idk, they mention eventually using it as both digital and physical identification:
> "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.
> "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.
My first reaction is: "This won't work because you'll have to get every business, government, and other entity to agree to use it. Which they won't."
Getting a blue page with ≡ and "passcard" at the top right corner and a strip of a black footer. Nothing else. That's not how it supposed to look, is it? Recent FF.
That background color is really not that pleasing to look at. IMO it also fails to explain what exactly this thing is, how do I use it?
I don't even understand how to sign up. It asks me to choose a registrar, I clicked Namecoin and it just brought me to the Namecoin site with no further instructions. At Onename I am already signed up, technically having a card there.
So what is Passcard.info for?
So what is Passcard.info for?
Namecoin isn't actually a "registrar" in this case, but the canonical blockchain used with Passcard.info. You can think of it as the self-registration alternative. The Namecoin link is definitely a conversion blackhole. This would be a bit better: https://github.com/namesystem/namesystem/wiki/Namecoin
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
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
That link isn't any better than the first. Passcard bills itself as a service for non-technical users. Any and all sign-up links should point to clear, easy-to-follow, step-by-step instructions. Neither the Namecoin front page nor a wiki page about important Namecoin esoterica fit that bill. :)
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.
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.
Yup, a bit confused here as well. I just signed up with Onename, but I'm not too sure what to do. How do I link this with Passcard? I've already linked it to Twitter (but I don't have an image of me like others seem to do).
"Passcards are securely encrypted and then stored across a secure network of computers (also called the blockchain)."
Is this where we're headed? Take any idea, then tack on "stored on the blockchain" to the end?
Is this where we're headed? Take any idea, then tack on "stored on the blockchain" to the end?
If you create something that is "Uber for X, stored on the blockchain, anonymous & ephemeral" that's like 80B valuation right there.
"Uber for x, blockchain, anonymous, ephemeral" -> the evolution of "Social/Local/Mobile"
"Uber for x, blockchain, anonymous, ephemeral" -> the evolution of "Social/Local/Mobile"
20 or so years ago, this comment would have been:
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.
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.
Choose a passcard Registrar:
* ONENAME
* NAMECOIN
* NOPE
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.
Well, in those terms, how does this solve anything that the PGP web-of-trust fails at?
(Disclaimer: I work part-time for Onename).
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 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 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.
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.
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 think we're talking past each other.
> 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?
> 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.
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.
[deleted]
But what is it? What does it do?
"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.
"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.
Yeah I closed the tab after the "What is passcard" copy gave no extra information. I am still not convinced this wasn't something generated by that great startup generator.
See this blog post for the appropriate context:
http://blog.onename.com/passcards/
This was submitted to HN earlier in the morning [1]
[1] https://news.ycombinator.com/item?id=9524702
http://blog.onename.com/passcards/
This was submitted to HN earlier in the morning [1]
[1] https://news.ycombinator.com/item?id=9524702
That's information that should be on the homepage, not hidden away on some blog.
Seconded. Shouldn't have to understand the "context", that should speak for itself
Passcard is a decentralized, blockchain-based identity system.
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.
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.
Here: "Passcard is a decentralized, blockchain-based identity system." -> This should be their tag line.
For those curious, there's also BlockchainID (something I've worked on):
https://github.com/okTurtles/blockchainid
And BitAuth:
https://github.com/bitpay/bitauth
https://github.com/okTurtles/blockchainid
And BitAuth:
https://github.com/bitpay/bitauth
Yea can someone explain what this does... I'm all the way at the sign up page and still have no clue what its for...
something resembling real information:
https://github.com/namesystem/namesystem/wiki/FAQ
https://github.com/namesystem/namesystem/wiki/FAQ
If this is meant to provide secure identity checks [1], how does this compare to keybase.io?
[1] Not sure, because of lack of information on the site.
[1] Not sure, because of lack of information on the site.
I keep looking over the main page of this site to see if there's anything I missed, but it really does seem like either this is a joke that I don't get, or there is no information whatsoever to say what this actually is, how it works, what is involved from my end. There seems to be a lot of expectation from this page that users will dig into documentation or other resources on something that apparently controls or maintains their identity (?) instead of just ignoring it and moving on.
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?
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?
It seems more that the reason the copy is as vague and doesn't directly mention blockchains on the homepage is because this is supposed to be a project for non-tech people - personally, I'd find a decentralized blockchain-based identity system very difficult to describe in simple non-tech terms to anyone, so good copy is clearly a challenge.
Are you kidding me? This page renders absolutely nothing with javascript disabled. This crap has to stop.
Are you surprised that disabling part of the website renders the website inoperable?
Yes, I am. Graceful degradation is a wonderful thing. Shame so many devs simply don't care.
> Turns off Javascript
> Complains page doesn't load.
It's your fault. Esp. since many sites are using stuff like AngularJS now.
It's your fault. Esp. since many sites are using stuff like AngularJS now.
Hypothetical:
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?
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?
Doesn't it deauthenticate when it isn't on your wrist?
Oh look it's another Identity and Access Management for The Real World company trying to turn your phone into the Thing That Unlocks. Interestingly enough there's actually not a lot of companies out there trying to be this ambitious about using your phone to unlock things- sure there's Lockitron and Knock[1] but those are individual apps, not one huge holistic app that will replace username/password combos for online and software plus replace anything else that requires you to verify your identity in some way (credit card transactions, Gov ID, School ID, keycard for work, etc etc).
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...
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...
The site does a poor job explaining what it actually is. How exactly does it replace the keys to my apartment?
Design question: why is the "☰" (hotdog / hamburger button) migrating into desktop versions of websites?
No practical purpose. Probably done to make the page look "cool" and clean, at the expense of actual usability and proper navigation.
Another scheme to get money in seeds funding form VCs, split biggest shares among co-founders and then BYE. Very "Innovative" idea.