[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Auth]ISsec Profile Providers (was Re: IDsec meeting)

From: John Pugh
Subject: [Auth]ISsec Profile Providers (was Re: IDsec meeting)
Date: Thu, 29 Nov 2001 16:11:21 -0700

One issue I have with this model... I "trust" these providers only to a
certain extent. I will not allow Provider A to have x data where I would
allow Provider B to have it. I need a method that allows selective sync
of information.
For instance. I have a single provider of my choice which I trust and
that provider supports dotgnu. I keep one set of everything (profile as
you call it) for redundancy with this provider. I have the other full
set on my laptop and another at my home office. This allows for
redunancy (something we call a replica). I can access info at my home
office or other "provider" via a browser or from my full featured
"client" on my laptop if changes are necessary.

But...I don't fully trust these "providers" so I only allow them
certain information or I give certain information for their use for free
where some of my information is available for a nominal usage fee. Since
I control everything, I allow only a few attributes to sync...this works
especially well if my "provider" has a specialized schema for a special
purpose. I can allow the attributes for that specialized schema to sync
with this "provider" only.

Another issue I see is the lack of "choice". Provider A has a value
added service they want to provide. They in turn have a value added
schema that I can choose to implement or choose not choice. I
also don't see any dynamic synchronization of information. Granted, I've
just glanced over the "spec", but is anyone looking into this?

These are the things that a "personal directory" can accomplish very


>>> Norbert Bollow <address@hidden> 11/29 3:01 PM >>>
Mike Warren <address@hidden> wrote:

> The advantage I see here is that there is far less danger of a
> security failure (at the Profile Provider) resulting in the release
> potential a lot of Profiles. If each user controls her own Profile,
> then an attacker would have to compromise each users' computer to
> 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.


I propose that the DotGNU's standard Profile Provider software
should be designed in such a way as to make it very attractive
for banks to become Profile Providers.  We absolutely need to
win the banks over to our side.  This is of key strategic

> > The Content Provider now has a user profile that he can use to
> > personalize content, to do accounting and/or billing (eventually
> > combination with a third party) and any other business that he
> > 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
> 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.

Actually, if the Profile Provider is a bank where the user has
an account, the payment doesn't need to be via credit card... it
could go directly from the user's bank to the merchant's bank.
(True e-banking :-).

> If such a system became ubiquitous enough, one could use such
> cash tokens for many types of purchases.

I think this is a very good idea.  Because the virtual cash
tokens don't need to allow for chargebacks, it'll not have
to be complicated to gain the ability to accept them.  (Not
like a credit card "merchant account" which you'll only apply
for if you have very good reason to do so.)  This will make
them attractive to e-business merchants and even to simple
netizens who can use them to accept the occasional payment.
It will be attractive to the banks to become trusted Profile
Providers for their clients and issue virtual cash tokens for

> "Mario D. Santana" <address@hidden> writes:
> > Near as I can tell, the basic difference is that Flysolo's data is
> > fetched from repositories and fed to web services by the _client_.
> Is there any way to verify the data? That is, Profile Providers
> likely be more trustworthy to Web services if they (optionally, at
> user's request) verified the data in a user's Profile.

At least here in Switzerland, banks verify customer-provided
personal information anyway (because of the
anti-money-laundering due diligence rules).  So it shouldn't
be difficult for them to optionally provide a certificate
that the user's personal information is true.

Greetings, Norbert.

A member of FreeDevelopers and the DotGNU Steering Committee:
Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich,
Tel +41 1 972 20 59       Fax +41 1 972 20 69 
Your own domain with all your Mailman lists: $15/month 
Auth mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]