Hans Zandbelt <address@hidden> writes:
User profiles are stored with so-called Profile Providers somewhere
on the Internet. Profile Providers are parties that have a trusted
relationship with the users whose profiles they have stored in their
databases.
This sounds reasonably similar to my idea; I may be interested in
helping with this project.
I would argue for a system which doesn't depend on a database, though;
I think it makes sense for only the user to keep a copy of the
Profile. The Profile would be encrypted by the Profile Provider,
though, so that the user would still only be able to edit the Profile
with the Profile Provider's server.
The advantage I see here is that there is far less danger of a single
security failure (at the Profile Provider) resulting in the release of
potential a lot of Profiles. If each user controls her own Profile,
then an attacker would have to compromise each users' computer to gain
their Profile; they wouldn't be able to attack a single point (the
Profile Provider).
Perhaps some users would like their Profiles stored at the Profile
Provider; this certainly could be accommodated. I think both methods
should be allowed.
When starting a web session that requires the use of IDsec, the user
will login with the Profile Provider with a username/password
combination. This "session login" will result in the creation of a
so-called session certificate that is sent to the user. The session
certificate merely consists of a session identifier and a URL that
indicates the location of the user's profile.
If the user had chosen to control their own profile, the session
certificate would instead include a URL where the (included) Profile
could be decrypted (i.e. at the Profile Provider).
The users web-client sends the session certificate to the IDsec
enabled web-site of the Content Provider. The Content Provider in
his turn, sends it together with his own certificate to the URL
specified in the session certificate over a secure connection. The
Profile Provider uses the session certificates to identify the user
and assembles a Content-Provider-specific user profile based on the
Content Provider credentials and the Access Control List that the
user specified.
This sounds good; again, if the user had chosen to control their own
Profile, then the IDsec enabled Web site would also pass along the
(encrypted) Profile.
The Content Provider now has a user profile that he can use to
personalize content, to do accounting and/or billing (eventually in
combination with a third party) and any other business that he would
normally do with a customer database.
I've also thought that a good revenue-generating service for Profile
Providers would be a type of virtual cash; the user can give their
credit card information *only* to the trusted Profile Provider who can
issue virtual-cash tokens to the user at their request. These tokens
could be used at participating Web-services as payment (and then
redeemed by the Web service for cash via the trusted Profile
Provider). In this manner, the user must trust only a single service
with their credit card information instead of a variety of Web
services.
If such a system became ubiquitous enough, one could use such virtual
cash tokens for many types of purchases. Any such virtual cash tokens
should have the following features:
. ability to be anonymous (i.e. a $20 token shouldn't necessarily be
connected to a particular Profile). This implies they are untraceable.
. must specify a recipient, somehow; I can't see a way around this,
since any such token could be copied.
. should have option of being time-sensitive (i.e. the token might expire
in 24 hours if it's not redeemed by then).
Notice that IDsec supports "anonymous browsing"; it does not
neccesarily reveal the name and/or address of the user. IDsec
transmits exactly those attributes that a user trusts to be sent to
the requester.
Your system sounds very similar to the one I thought would be good. I
may be quite interested in helping design and implement this, if help
is still needed. Is there a Web site for the project?