#New Idea for Contact Cards
##Rational
For some time now I've been aggravated by the concept of contact cards. As I look through my Address Book, I'm overwhelmed by the inaccuracies in there, even though I'm pretty diligent in ensuring it is up to date. There is no way of communicating an update to your info without a mass email to everyone in your address book, or sending it out over some form of social media. Beyond that, if there's someone who is not in your address book, you probably don't have a way of informing them of your contact update.
I also don't like the fact that once someone has my card, there's no way to take it back. It's a bit of a problem if someone gets your information
I love the idea of QR codes that contain embedded vCard information, and the fact that it's possible to update the information while NOT changing the QR Code. The problem remains however that once someone inserts the vCard into their address book, the only way to update it is manually.
##My Idea
My idea (in it's infancy) is to create a protocol around contact information. It should be distributable as to not rely on a single central server, but it should be cloud based as to allow for dynamic updates.
Essentially, I should have my own public IdTag that contains all of my contact information. There should be sub-tags to indicate personal, business, whatever else. Then I pass out my IdTag, attach it to my business card, embed it in a QR Code, email it as an attachment, or deliver it as a link. The tag is mine forever, and contain as much or as little contact info as I want.
##Working Concept
By default when someone requests a valid IdUrl, the handshake is granted (maybe using OAuth) unless either the requesting IdUrl or the requesting ServerUrl are in the Revoked list. If in the future, a user would like to revoke access to their contact card for a specific user or server, they can simply add them to the revoked list, and they're no longer accessible.
When it comes time for a user to contact someone via email, they simply enter their contact name into the "TO" field, and their email client will fetch the most current details from the Server.
Also, when a users contact card is accessed on the local client, the client will fetch the current information before displaying the card. This ensures that when you are contacting someone, you're not likely going to get the wrong number/email address/ whatever.
Also, if a user decides that they want to change to a new contact server, the OLD server is to 301 Redirect the request to the new server.
##Structure
I've structured the concept using JSON to give an idea of what it could look like.
https://gist.github.com/ChaseFlorell/6754779#file-contactstructure-json
Then when you want to pass out your personal contact card, you pass it as
https://contactserver.example.com/j6k7l8/asdf
// returns shared + personal
And your business card as
https://contactserver.example.com/j6k7l8/1234
// returns shared + business
And if you want to give ALL your details, you share
https://contactserver.example.com/j6k7l8/asdf:1234
// returns shared + personal + business
##Pitfalls that I see
Currently I haven't worked through the concept of people using copy/paste to retain details even after being revoked. Maybe this concept gets introduced by default into the Communication Client, and maybe it's all part of replacing the archaic "Email/SMTP" protocol.