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.
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
Post a Comment