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.
_______________________________________________
Auth mailing list
address@hidden
http://subscribe.dotgnu.org/mailman/listinfo/auth