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

[Hans Zandbelt]

Mike,

At 12:33 11/29/2001 -0700, Mike Warren wrote:
>This sounds reasonably similar to my idea; I may be interested in
>helping with this project.

Please do so!

>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.

It is not forbidden to maintain multiple profiles with multiple
Profile Providers as a single user. I'm not foreseeing that these
profiles are synchronized so some attribute values may have to be
duplicated manyally. However somehow but I think it can be useful in
cases where you would like to have a "private profile" for surfing
the internet from you home environment and a "work profile" when 
being on the internet for your company. If principle you can solve
this within a single profile (namespacing is supported) but you can
always choose to split up your profile like this.
Your company profile could be stored at your company, your ISP or
you yourself could provider your personal profile.

>Perhaps some users would like their Profiles stored at the Profile
>Provider; this certainly could be accommodated. I think both methods
>should be allowed.

You are right. It is supported. A Profile Provider merely is a webserver
that is able to provide a profile over a secure connection. Users can
do it themselves.

About encryption of profiles:
We have been thinking about this but we had to abandon this idea:
A user would have to send a key to decrypt the profile to the
content provider. (or it could be encrypted with the public key of the
content provider, but it would have to be done on a per-web-site basis
and the profile provider would not be able to do so it because he is
not trusted and has no access to the plain profile data).
Sending this key implies doing so over an secure connection. Also
the profile data must be checked by the user because he doesn't trust
the profile that is returned the profile provider.
It turns out that the Profile Provider is merely a remote storage and
that all other processing functionality (manipulating profiles, encrypting
them, providing them) has to be done by the user himself on his local machine.
This boils down to the fact that a user is his own Profile Provider, which is
a configuration that is also supported in the current IDsec system.
Bottom line: if you don't trust anyone with your profile, do it yourself.

>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.

Yes, this is a typical scenario that we have been thinking of.
Either the Profile Provider could be a bank itself, or you could give access
to your creditcard attributes to a trusted bank party. If a content
provider trusts this bank party as well, it can give the guarantee for you
without the content provider knowing who you are. And the bank party
in his turn, does not need to know what the money is being used for.

>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?

There is no web site yet. I'm working on more detaild documentation which
I intend to put on a web-site.
I'm looking forward to any contribution you have.

Hans.


------------------------------------------------------------
Hans Zandbelt                         address@hidden 
Telematica Instituut                     http://www.telin.nl 
P.O.Box 589, 7500 AN                   Phone: +31 53 4850445 
Enschede, Netherlands                    Fax: +31 53 4850400