Re: [Auth]Freport Update

[John]

Hans Zandbelt wrote:
> 
> At 08:02 3/15/2002 -0600, John wrote:
> >convenience. Build paranoia into our solution from the start as we
> >originally planned, assume that everyone is dishonest and will try to
> >benefit from dishonesty.
> 
> It is impossible to build a virtual identity system if you
> don't trust anyone. In fact, it is not even necessary to build
> one in that case: you wouldn't trust anyone to with the data
> that you provide with it anyway.
> The whole point of a virtual identity system is that it
> must enforce the rules about trust that you have.

Let's amend the wording to "trust as few entities as is absolutely
necessary to meet the requirements". The only allowable trusted parties
in those original requirements were the "Owner" and the "Service
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.


> >As I said before, I only believe that people should be informed, and if
> >Hans can show me that the transactional metadata cannot be collected
> >under his current design *in any sane usage scenario*, then I will
> >renounce my objection: and probably apologize.
> 
> There is no need for any apologize, from me nor from you.
> My statement is that IDsec does not allow transactional metadata to
> be collected by anyone that you don't trust. I think this is
> a sane scenario ;-)

That would of course depend on your definition of sanity and your
definition of the word "is". The insertion of "sane scenario" was of
course to avoid discussions of "there's no Internet connection on the
moon, but I need a virtual identity accessible from there" to often one
can step far outside the realm of the impossible when discussing the
impractical.

I'd say that the temptation to mine transactional data, or change a TOS
to allow such to be done rises in direct proportion to the quantity and
quality of the data that can be collected. In Passport both the quality
and quantity of the data is high, thus fairly guaranteeing it will be
abused. In IDSec the quality is low, but the quantity is high - high
enough I'd argue that the temptation still exists. Paraphrased - the
DotGNU requirements were no quantity or quality without the Owner's
explicit consent - the user holds the keys, not the Provider.

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
the tub and no-onelse is home) Thus the enormous sucking sound I posit
of people trampling each other to the third-party Manager providers, who
may or may not be trustworthy and who can shift spots overnight to cross
the non-existent technological impediment to gathering transactional
metadata through ID-Sec.

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.

John Le'Brecage

PS- I think I'm going to lay me down for a nap. With the exception of
the last 7 hours (now), I've been up for more than two days coding (51
hours.

Ciao beaners.