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

[Mason Ham]

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
>