Re: [Auth]Okay, so how about some code...

[Mason Ham]

Okay, just to be clear on this. Here is the world that I have seen:
1) If the end site can make a decision on a piece of data that is more than
"does it exist", then that data is no longer opaque to the site... how else
did it make a decision on it in the first place.
2) The auth. system is different from the personalization system. If the
site only needs to get information from the site that says say first name,
and the site wants to display the saying that is first name, then it will
have to render the first name on the screen. That means that the data is no
longer opaque.
3) Data mining or not data mining is a business issue. If the end user knows
that the site is going to warehouse data and still the end user says "yes
send the info." we shouldn't get in the way of that. This at least is how
the system that we have works. What we do instead is place the user in
control by letting them "know before they go". This is what I think make the
difference. The use, with out having to go to the site first, can no, by
going to one of the auth. servers for the site, what data that site is going
to need. We also have grouping for what sites are going to do. That is, a
site falls into different "pledge" categories. These are things like "will
not warehouse", "will warehouse, but  not sell", etc. The absence of a
pledge is a "buyer be ware pledge".

Soooo... I am not sure that this answers all the questions, but it should
give a little more insight in to what we thought were good and appropriate
trade off's.

One final thing, I am not saying this is the way the system has to stay,
only that it is the way the system is, and we did actually take quite some
time trying to get the balance between "pie in the sky" and "real world"
right, and this is the balance that we chose, nothing more and nothing less.
The only thing that we were sure of when we build the system was the we
where wrong, and so we made it as flexible as possible given technology,
time and people constraints.

Mason
----- Original Message -----
From: "John" <address@hidden>
To: "Mason Ham" <address@hidden>
Cc: "Norbert Bollow" <address@hidden>; <address@hidden>
Sent: Friday, October 05, 2001 5:04 PM
Subject: Re: [Auth]Okay, so how about some code...


> Mason-
> The problem is who encrypts. As I noted in the FrePort spec, the user
> agent must send the data and metadata to the auth syatem and not give
> that provider a key to decrypt it, otherwise both the data an metadata
> can be mined. It's not ONLY the "flow through the system" that must be
> secured, it's the repositories at either end with one crucial
> difference: the Customer (user) must be able to decrypt, the Provider
> must NOT be able to decrypt, otherwise privacy from mining is not
> guaranteed.
>
> John Le'Brecage
>
> John Le'Brecage
>
> Mason Ham wrote:
> >
> > Yeah, you guys are right about the LDAP issue. That was one in the plus
for
> > DBs :-)
> > As for the encrypt or not encrypt, again as with different parts of the
> > system, we left it up the Auth. provider. If system uses encryption to
store
> > the data, there is actually a location to store member specific data
> > encryption keys in the database. This key is then used to encrypt the
data
> > the user has. Then, it would be a no brainer for us to down the road
write a
> > "module" that will let us decrypt with the users private key and
re-encrypt
> > with the sites public key. This way the data can flow through and be
secure
> > as long as the system that is running the decrypt/re-encrypt module.
> > On the note of the data being transmitted. The system actually assumes
that
> > the end user has gone in and given rights to the site to get the data.
More
> > specifically, the site specifies what data it is looking for (there is a
> > grouping/role based request as well as individual item). This is also
where
> > the use of a database over say ldap came in. We have types that are
stored
> > in the database. Thus a site can no ahead of time that they want to put
> > custom fields into a known server. The example here is that a site
decides
> > that it wants to use only a certain server for authentication. This
server
> > then can house different pieces based on the site that is being used.
This
> > is more of an "enterprise" feature when the web services is being used
with
> > a private uddi server.
> >
> > Mason
> >
> > PS I site not to me a web site, but
> >
> > ----- Original Message -----
> > From: "John" <address@hidden>
> > To: "Norbert Bollow" <address@hidden>
> > Cc: <address@hidden>; <address@hidden>
> > Sent: Friday, October 05, 2001 8:09 AM
> > Subject: Re: [Auth]Okay, so how about some code...
> >
> > > Perhaps I'm seeing something that isn't there?
> > >
> > > > 5) bar encrypts the information with foo's public key. and
"transmits"
> > the
> > > > data to bob to be redirected.
> > >
> > > If bar is encrypting the data it retrieves from LCRS to send to Bob,
> > > then the implication is that the data is stored unencrypted, else
there
> > > is no need to re-encrypt it? There's no spec here of how LCRS stores
> > > data, but if it's based on LDAP, we should note that though one can
> > > store encrypted data in LDAP, LDAP is not specifically designed to
hide
> > > metadata (ie the name of the data to be retrieved) from the sysadmin.
> > >
> > > Hmmmm... hmmm... that give me another idea for Freport. A way to solve
> > > the public terminal problem, maybe...
> > >
> > > Anyhow, I'm just guessing from inference here. Maybe I'm missing
> > > something also. Mason?
> > >
> > > John Le'Brecage
> > >
> > > Norbert Bollow wrote:
> > > >
> > > > John Le'Brecage wrote:
> > > >
> > > > > This still does not prevent the data or metadata from being mined
by
> > B,
> > > > > which was another requirement of the DotGNU design. Wasn't it?
> > > >
> > > > John is right.  Data mining must not be possible as long as
> > > > people use software that is officially released by the DotGNU
> > > > project.  I believe that this is a non-negotiable requirement.
> > > >
> > > > But I don't understand Mason's design well enough to see whether
> > > > this is indeed a problem with his approach... Mason, maybe you
> > > > could clarify this?
> > > >
> > > > Greetings, Norbert.
> > > >
> > > > --
> > > > A member of FreeDevelopers and the DotGNU Steering Committee:
dotgnu.org
> > > > Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich,
Switzerland)
> > > > Tel +41 1 972 20 59       Fax +41 1 972 20 69
http://thinkcoach.com
> > > > Your own domain with all your Mailman lists: $15/month
http://cisto.com
> > > > _______________________________________________
> > > > Auth mailing list
> > > > address@hidden
> > > > http://subscribe.dotgnu.org/mailman/listinfo/auth
> > > _______________________________________________
> > > Auth mailing list
> > > address@hidden
> > > http://subscribe.dotgnu.org/mailman/listinfo/auth
> > >
> >
> > _______________________________________________
> > Auth mailing list
> > address@hidden
> > http://subscribe.dotgnu.org/mailman/listinfo/auth
> _______________________________________________
> Auth mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/auth
>