CAcert Code Development list.

[Michael Tänzer <NEOatNHNG AT users.sourceforge.net>]

Mario Lipinski schrieb:
> This is a point we really need to think about. However, this should not
> change the design of the software. We only should consider having a
> strict policy on external applications.

The only thing we need to do is make the external applications look as
if they weren't external but one "the CAcert website". As soon as we
have approved a third party website which uses these mechanisms and
really looks like a third party website (no matter how secure and
trustworthy it is) we open up a big hole. As long as we don't do that we
should be pretty safe.
The problem with the big hole is that it doesn't care about us
authenticating the surrounding fence, metaphorically speaking. Please
see my other mails for details.

> Am 11.07.2009 1:56 Uhr, schrieb Michael Tänzer:
>> Additionally we should not only have application accounts but also
>> assign data access rights to them. For example the geo/social app should
>> only be able to access the primary email address in order to send
>> announcements, maybe the name (the user could also enter this separately
>> as e.g. he might want to omit middle names) and possibly the number of
>> experience points while the web frontend needs wider access to the data
>> (in order to let the user tweak preferences, request certs etc.).
> 
> I think, this was already planned that way.

I guessed something like that would have been discussed but I thought
"better just spend those few extra characters, maybe they haven't"

Michael

Attachment: signature.asc
Description: OpenPGP digital signature