Re: [Auth]Freport Update

[John]

Hans-

I'm not concerned with what or how ID-Sec protects it's data, but rather
what ID-Sec leaves open to collection: valuable transactional metadata.
I have no objection to the existence of the ID-Sec project, but with
every step and every tacit weaving of ID-Sec into the DotGNU framework;
DotGNU is accepting what will eventually be a fait accomplais. I voice
my warnings once again, and will continue to do so. If DotGNU wishes to
remain true to its moral imperative as reflected in the original
requirements; we must question the shortcomings of ID-Sec in light of
morality, legality, and the broader ethics that we, collectively, wish
to spread.

The Rest
========
In the original discussions with the DotGNU council in this mailing
list, agreement was made that "nothing should be mineable", and that
definition of "nothing" included incidental transactional meta-data.
ID-Sec does not reflect that "must have" of the original requirement.
You and I established your indifference to the hiding of incidental
"sites visited metadata" in our long ago conversation. Please, do not
believe for a moment that your shouting me down then, gives you carte
blanche to do so now. I did not agree with you then, and I don't now,
and my reason is unchanged:

IDSec is concerned with securing profiles, and preventing *Service
Collusion*, but does nothing to secure the incidental transactional
meta-data that can be collected by the Manager Provider. This is a
privacy chokepoint - a major flaw.

I have read the ID-Sec SOP and RFC repeatedly; I might add: your
inference that I have not is a fine orator's trick, but is nothing more
than an assumption. If you wish to argue the privacy flaw to a
fare-thee-well; I've no objection, but would prefer not to - it's your
project, and I'm not concerned with influencing your decisions in
development - only that developer/adopters in other projects be well
informed of what assumptions they incorporate by utilizing ID-Sec. They
make the decision whether ID-Sec meets their moral principles and
imperatives.


Everyone needs to be reminded:

What is transactional metadata?
Quoth the IDSec white paper
===========================
"Upon starting an Internet action that requires the use of IDsec, a
Profile Owner will login with the Profile Manager. This "session login"
will result in the creation of a "session certificate" that is sent to
the Owner. The session certificate represents the Owner in the current
Internet session and it contains a reference to the location of his
Profile.

The Profile Owner sends the session certificate to the IDsec enabled
Profile Requester. The Requester in his turn, sends it together with his
own root certificate to the location specified in the session
certificate. The Profile Manager uses the session certificate to
identify the Owner and to assemble a Profile Requester specific Profile
based on the Requester credentials and the Access Control List that the
Owner specified.
===========================

The above two paragraphs describe the creation of the transactional
meta-data: a Profile Requestor requests via a certificate, BUT the user
establishes that certificate via the Profile Manager per login session
(not transaction, which is stronger, but that's another argument). For
ID-Sec to work as you describe in your draft
(http://search.ietf.org/internet-drafts/draft-zandbelt-idsec-00.txt) the
Manager *must* relate the Owner of the profile data, and the spercific
release to the Profile Requestor and return the data to the requestor
through an IP. This triangular transaction, O->PM, O->PR, PR->PM allow a
simple, transitive guarantee that the Owner has dealings with the
Requestor, and that the Manager Provider knows who both parties are!
Since the Requestor probably has a static IP address (most permanent
sites do), very little work is required to find with whom the Owner is
dealing - anyone from a Yahoo Mail account to a Domain Name Registrar to
a Bookseller.

I repeat: ID-Sec protects the Requestors from colluding, but does
nothing to prevent the Manager Provider from collecting incidental
meta-data. I have more than perused both your RFC and your original
white, studied them and asked, "Does this meet the requirements?" ID-Sec
did not then, and does not now protect transactional meta-data, in fact:
ID-Sec exposes the metadata. I'm reminding everyone of the fact of that
requirement and I will continue to stress the importance of not ignoring
it.

ID-Sec wants to depend on the trust. The Owner trusts the Manager
Provider or he does not. The Owner trusts the Requestor or he does not.

The Problem with Trust is that Trust is not Perpetual
=====================================================
Example: I live in a US state where a Manager Provider does not even
have to alert me that they have changed their TOS (darned UCITA); the
Provider can change the TOS at will - they can be a (by my definition)
trustworthy entity one day, and not the next. If they can technically
mine my transactional meta-data, and want to; I may start receiving spam
for months before I realize the connection to my Manager Provider. By
then, it's too late: I can switch Providers, but I won't stop receiving
that spam generated from my historical transactional metadata. Who is
trustworthy under such laws? No-one.

Consider that all 33 million Aamericans who sign-up for AOL are subject
to the laws of my state. I'm hardly alone facing this problem. So, don't
try to say, "that's your problem." It's also a problem that impinges the
lives of an 1/8 of all Americans. If ID-Sec is broadly adopted, then we
subject the other 230 million Americans, and Ghu knows how many
worldwide, to the same sniffing that Microsoft is capable of through
Passport. 

Pardon me for being a bit provincial about that, but perhaps you don't
know what that can be like:

Real World Example:
===================
Suppose Hans that I could follow you around for months at a distance of
30 meters and make a notation every time you purchased something or
requested information or performed any other meaningless task of daily
life? Suppose in-re this limitation: because of the distance I can't
record the task, or the item purchased, or the money spent, but only the
entity with whom you committed the transaction? Suppose that I wanted to
sell that information? Would a food mart competitor want to know that
you visit a different market to send you snailmail spam? Sure. Would one
bank wish to know that you have dealings at a competitor to tell you
about their great new loan options? Sure! Would Penthouse like to know
that you subscribe to Spy? Sure! Would PETA want to know that you
regularly visit the offices of the Beef Council? Sure! Think on it. That
transactional metadata is valuable and value can be mined and sold.