Skip to main content

Contact Codes™

Contact Codes would make it quick and easy for any individuals or organizations to exchange all kinds of relevant, accurate, contact information. Then, the same service could be used to provide secure login and password recovery.

Solution: We would provide new codes for free through a public site on the web. Contact codes would be relatively short, unique codes, designed to be easy to enter through electronic devices. The codes could come with web addresses to retrieve the associated contact information. The web site would be optimized for mobile devices, and we could also provide mobile apps.

Unlimited Applications: Associated information could include actual name, physical address, phone number, email address, and links to profiles on Facebook, Twitter, Snapchat, etc. It is important that we would not limit the associated information to any specific kinds of contact information. This lack of such a limit would allow these codes to be used for all kinds of contact information, including kinds which have not been invented yet, but will be in the future.

Multiple Contexts: For convenience, we could provide multiple codes for separate sets of contact information (for example, business versus personal, or close companions versus casual acquaintances). That way, users could have fine grained control to provide others with easy access to only the contact information that is relevant within a certain context.

Privacy Note: Contact codes are not intended for securing private information. They are only designed to be used for information that would already be considered public.

Technical Details: Web links would be verified by a verification code. The user would login to the Contact Codes site or app, and add a link to a public web page somewhat under their control known as a channel (such as a profile page on a social network). Contact Codes would provide a verification code to verify that link. The user would use their access to the channel in question, to post the verification code within the content of the page. Contact Codes would automatically check the page in the background, and verify that it contained the code. (HTTPS could also be used in this process, to verify channel).

For offline contact information, a third party service would setup a provider for each type of contact information. The provider would provide a channel for each user. The provider would require the verification code from the user, then the provider would conduct their own offline verification, before adding the verification code to the verified channel. For example, a mailing address provider might send their own verification code by mail, and require the user to enter it to verify the mailing address. A phone number provider might send their own verification code by phone. (These channels could also have REST services).

Also, Contact Codes could have support for one or a very few certain reasonably well established channels built in--such as, perhaps, email addresses.

QR Codes: We could also include associated QR codes (special 2D barcodes) for added convenience, so that users could access the web addresses by snapping a photo of the QR code instead of needing to manually enter the address.

Physical Materials: The addresses and QR codes could be printed on business cards, letterheads, and other materials. We could possibly partner with third party printing services, to help facilitate easy access to physical materials containing the codes.

Online Directory: We could provide a reverse lookup directory so users could use some contact information to find the rest. When a user added a channel, we might provide them the option to make that channel support reverse look-ups. For example, a use may want to enable their real name to be used to lookup their personal profile, but they may not want to enable their Snapchat to be used to lookup their business profile.

Offline Support: We could store copies of the directory of contact information for everyone, on each users' device, so they could access the information while their device was offline, and synchronize to get updates when they come back online. We would find a way to do it that would not take up too much storage space.

Note: Please pardon the usage of some highly technical terminology in this article.

Secure Login: Identification would be provided as a combination of contact information in certain channels. A provider could associate a channel with an OAuth service. (For example, Facebook OAuth provider and associated Facebook Profile). Then, contact code users could choose which channels they wanted to trust for inbound authentication to manage their contact code. Then they could use an authenticated session with a chosen provider to authenticate with Contact Codes for managing the code associated with the validated channel for that provider.

Password Recovery: Besides inbound authentication, secondary channels could be used for password recovery. A user could choose a certain combination of verified channels and verification providers they trust for password recovery. For example, they may require a combination of email address and text message verification, from "Acme Verifications, Inc." Contact Codes would use the providers to re-verify those channels. (When the reverse-proxy in Contact Codes requests the channel URL, it could verify "Acme Verifications, Inc." as the Organization name in the Subject of the validated HTTPS certificate.)

Third Party Services: Contact codes could provide services to third parties of brokering secure authentication and password recovery. The third party could choose which channels and providers they would require. Once a user has established a secure session with contact codes, contact codes could confirm to the third party service (using OAuth) that password recovery or authentication should be allowed. Since Contact Codes would be free for users, perhaps these services is where this product could be used to earn money.

Comments

Popular posts from this blog

Shared Project Manifesto Version 2

Contents:IntroductionLaunchTradeRewardDevelopVoteHarvest 1. Introduction IP (Intellectual Property) is a great asset but it is hard to produce well. We hypothesize that a market to facilitate shared projects would make it easy to produce IP better.


The market contains projects. Each project has one admin and a number of traders and developers. One user can have any combination of roles at the same time. For example, a user may be an admin and also a trader, or a trader and also a developer. ProjectsUsersAdmin: Provides ideas in exchange for controlTraders: Provide incentives in exchange for growthDevelopers: Provide IP in exchange for incentives 2. Launch When somebody came up with an idea for an IP product, they could create a project for it on the market. That person would be the admin.
The market would record the time the admin launched the project. That lasting record could provide for the admin to claim credit for the project idea, on a first-come, first-served basis. This recogn…

Fog Machine

Fog Machine™ (named because fog is like a cloud, on the ground) is a software product to provide cloud services to customers without a cloud service provider. The problem with the traditional cloud is that it requires a provider. Fog Machine™ would run cloud "nodes" in idle system resources on ordinary user's devices. This would be a peer to peer system in which each connected device would be a peer.

It would support standard cloud APIs (perhaps Cloud Foundry?) and it would be easy to port cloud apps to it off providers such as Google cloud, Azure, or AWS--or maybe it would be effortless for apps that were already portable through compliance with open standards.

We might use encryption for privacy, redundancy for reliability, and remuneration/incentive for resource consistency. The showstopper (critical assumption) is that the synergy would be sufficient to significantly surpass the overhead, and provide competitive performance for at least some types of cloud applicat…

Nuke Login™

Nuke Login™ is a software product that would provide secure access to computer accounts without the user needing to worry about passwords or related concerns. Like other password manager products, Nuke Login™ would provide the ability to automatically login to many different accounts, but it wouldn't require a password to login to itself. Instead of replacing many passwords with one, it would replace many passwords with a different process.

Also, Nuke Login™ would not only manage the process of logging in. It would manage the whole login-related processes for the accounts, including registering, logging in, changing the security information, logging out, and closing accounts.

When a user was registering for a new account, if they only needed login credentials to register, Nuke Login would automatically generate those credentials and register them. If other things were needed, Nuke Login™ would take care of the login credentials and mask them in the registration process so the user…

Please Comment

Have you ever heard of a similar idea? What challenges might an idea run into? How might you like to be involved? Comment to add your voice to each idea.