Re: [Auth]Freport Update

[Hans Zandbelt]

> The paragraphs explicitly refer to the "third-party". As you and I both
> know, a third-party is only needed in the Remote Manager situation.
> Local Manager doesn't enter into the paragraphs. Neither he, nor I, ever
> mentioned or eluded to the local manager.

I don't think I tried to point out anything else.

> His paragraph referred to the elimination of the LINKAGE which occurs in
> the ID-Sec messaging between the Service and the Remote (third party)
> Profile Manager.  He suggested severing the linkage between the Service
> and the Remote Manager and passing everything through the Owner. He did
> NOT suggest the *removal* of the Remote Profile Manager itself (at least
> I don't believe he did). Once the linkage is removed and the data
> request is forced to be passed from the Service through the Owner to the
> Remote, and the resulting response is passed from the Remote to the
> Owner and back to the Service; the resulting network connection *IS* the
> Databank retrival mechanism of FrePort.

But the Remote Profile Manager is merely a data storage provider then;
in that case the data could also be stored on a local disk (read: local
Profile Manager) ... You'd lose the dependency of remote Profile Manager
uptimes and network connectivity which seemed to bother you in the
context of IDsec. Right?

What about the things about trust that I brought up in one of my previous
e-mails such as: I say that the party that provided the Freport software
is a good candidate for an IDsec remote Profile Manager.
(if you trust he didn't build in a spy backdoor into Freport, he might
as wel be trustworthy as IDsec remote Profile Manager for you)

> The net result of this change to the messaging topology is that one
> piece of the transactional metadata is eliminated from mining by the
> Manager Provider. There's more transactional metadata that must be
> eliminated to completely clean the topology, but if you use my methods
> to eliminate those other bits of incidental data; the result would be
> that you'd be developing FrePort and not ID-Sec!

I don't care if it is called IDsec or Freport; it needs to work.
But you seem to bring up issues that you consider problems in IDsec
where I say they are facts that need to be handled with care
and that you even do the same thing in Freport (which by the way in
my opininon and your opinion does not make Freport a bad thing)

Hans.