Re: [Auth]Re: [CoreTeam]IDsec meeting

[Mike Warren]

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?

-- 
address@hidden
<URL:http://www.mike-warren.com>
GPG: 0x579911BD :: 87F2 4D98 BDB0 0E90 EE2A  0CF9 1087 0884 5799 11BD