Re: [Auth]Freport Update

[Hans Zandbelt]

John,

> Provider" and no-onelse. The assumption was that the system had to
> contain a 3rd party provider, to enable remote access, but that this
> party was untrusted (if you don't trust Microsoft/Passport, why would
> you trust your ISP?). I thought this was rather clear from the context
> of my remark, but I was obviously mistaken. I hope this clarifies the
> above paragraph.

OK, I see where you are coming from. The IDsec specification clearly
states that the Profile Manager is a trusted party. We should not
have had the discussion about possible data-mining; it is obvious that
you would choose for local Profile Management since you don't want to
trust anyone else with your data. That is a choice that people have to
make. I myself think that the task of being a Profile Manager can
be highly optimized in terms of security and accesibility by a third
party just like you hire trusted third parties to do your privacy-
related stuff like banking, medical advice etc.
However lets focus on the local Profile Manager for now.

> The self-hosting scenario looks to be an option that isn't an option:
> one must be willing to jump through hoops to be their own host and wring
> their hands at the inevitable interference of Murphy's Inference - "Just
> when you need the data the most; your self-administered system will make
> the data unavailable and there will be no-one to call to fix the
> problem." (sort of like: the phone always rings when you've your arse in

If someone is not willing to trust a third party and he's not willing to
do it himself, the only other option is not to do it at all...
I think local Profile Management doesn't need to be that hard. You're right
about the fact that it needs a good implementation: reliable and easy
configurable. That's certainly an issue, but not a design issue.
It can be built in into the client application as a library. In that case,
you can guarantee availability and if it isn't there you won't need it
because your client application has crashed along with it ;-)

It is a fact that this is an issue for every single virtual identity
proposal that we can think of.

> Catch-22: increased convenience (3rd party) trades off for reduced
> privacy (transactional metadata gathering). Is this a trade-off DotGNU
> is willing to make? The further down the road to integration we go; the
> more difficult it will be to change our minds.

No, because I think both cases can be covered possibly even with the same
software linked against different executables (web server and web client).

I guess the discussion boils down to the question wether we can make a good
implementation of a local Profile Manager (speaking any virtual
identity protocol). That's something that is up to ourselves!

Hans.

PS: for sure the PHP implementation is not convenient enough for local
    Profile Management.