Re: [Auth]Freport Update

[David Sugar]

My own opinion, quite honestly, is that IDsec should be one of several 
solutions we examine and make use of.  I believe IDsec does, even if, as 
some feel, justifiably, very marginally or conditionally, meet our 
goals.  Certainly the question was never mearly to provide an 
alternative or an alternative that simply is outside the scope of 
control of one vendor, but one that, as ?John? very correctly points out 
here points here, meets our philosophical goals, the most important 
being to protect user's privacy and security.  Could IDsec be better in 
this respect?  Perhaps.  Could something else possibly do this in a 
manner more consistant with our goals?  That is certainly possible.   
It is also possible that IDsec can still be further improved in ways 
that unconditionally meet our goals.  While IDsec is certainly not 
perfect, it is useful, and I think worthy of use.  Freport is also very 
much worth considering, and I would like to see that and other projects 
that wish to try and meet our goals in full continue as well.

Hans Zandbelt wrote:

> > gain endorsement? Or as I phrased it originally, "do we go with code
> > that's out there (ID-Sec, which provably misses on one requirement or
> > another) or do we stick by our philosophical guns (and insist that
> > projects meet the requirements)?"
>
> ???
>
> Which one would be missing now considering the local Profile Manager?
> I think we just concluded that it must be possible to create a local
> Profile Manager client library; after all you use a similar concept
> for Freport. I really don't see the difference here.
>
> But I also want to get back to the IDsec remote Profile Manager:
> I think the issues of trust that you see can equally be applied
> to the party where someone would download/purchase/get/retrieve
> the Freport sofware!
>
> I'd say that this party is a good party for being a remote Profile
> Manager, just as David stated.
>
> And I can go on about assumptions and issues of trust that are not
> IDsec specific:
> - you trust the internet service provider that you use
>  to send out the Freport announcements, software and updates.
> - you trust the e-mail software that you use to mail
>  about Freport.
> - you trust the creator of the compiler that you use
>  to compile the Freport software.
> - you trust the creator of the encryption techniques
>  that you use in Freport.
> - you trust the DotGNU auth mailing list maintainer and the
>  software
>
> As you can see there is always a trusted third party problem, and
> a trusted communication channel problem even for a local Profile
> Management system like Freport.
>
> Can we agree that this is not an IDsec specific flaw?
> Or does anyone have any new arguments?
>
> If we agree I would like to take a look at Freport so we can align
> Freport with the IDsec local Profile Manager API and hopefully
> even combined with the Liberty Guardian.
>
> Hans.
>
> PS: the IDsec implementation as it exists is no threat to the DotGNU
>    auth system initial requirements or Freport; it is focussed
>    on remote Profile Management although non-average users can use it
>    for local Profile Management
>
>
> _______________________________________________
> Auth mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/auth