Antenore Gatta wrote:
> I wouldn't like to reach an agreement about OpenID just because of numbers,
> but because of understanding, me an MJ we could be wrong, you as well, so
> is needed to discuss and reach an agreement all together in these cases.
> The wrong decision could compromise the project...
You are right. Let discuss a little more...
IMHO OpenID is more usable but its security is weaker than UserID + passphase
just because you delegate authentication on an external system which can have
its own security risks, etc.
It's also true that the security system of a third party could be more safe then the GNU Herds one, but also that a Third Party could be more desirable for attackers.
We can assume OpenID is less secure than local user/password, as it is. So we
can set the level of access/grant according to the log-in method used, and
ask for a higher level authentication if the user want to realize a more
critic operation as read-bank-status(medium), transfer-money(critic), ...
Yes, asking also for additional information to better trust the identity. It could be an optional second registration's step.
By me a user can be:
* Logged (With or without OpenID)
* Registered (in the GNU Herds DB as an authorized and verified entity)
* Trusted (we know everything it's needed to trust him)
OpenID should provide access to all the (and only to) base functionality.
So, maybe, we could authorize only some operation when users are logged via
OpenID. That is to say, we can have:
* several authentication mechanisms,
and define the security level which each one offers, and
* an operation catalog,
which lists the security level requirements to get authorization for
realizing each operation.
ACL based mechanism...
The user log in with his preferred method, then each page has its own access level.
So it means that we should add an access layer.
That is how my actual bank account works. My bank uses:
* To log in: UserID + passphrase, and a card with a matrix of numbers,
via HTTPS.
* To transfer money: an additional special passphrase is required.
And even so, it is know it has been broken and lot of money lost. I think
the final solution is said to be something similar to GPG.
We could use the OpenID support to make it easier to register at GNU Herds.
Just a click and go avoiding the current process.
We could define the OpenID security level to allow only:
* create account
* access account
* modify account: job offers, pledges, etc.
and require the current gnuherds password, (and maybe other security
measures), to realize bank operations.
Maybe we could add GPG keys to the authentication method pool.
IMHO GPG it's not easy to use for normal users and GPG (and similar technologies) are not so used (unlucky).
About this I would prefer something like this:
1. Separation between static content and dynamic content.
Static content would be always accessible, no matter how, we don't need to protect pages like "About GNU Herds", so everything we put on the local file system will be accessible.
2. Access Layer and Access attributes
We would need a table with all the dynamic created pages with a default attribute of "deny access". So if not differently set nobody can access this page (URI or whatever we want).
Each pages could have two different attributes, one for the kind of access (deny, access, commit) and one with the level of access (i.e. not logged, logged, registered, trusted).
In this way we can have all the different possibilities and for example to do a payment transaction a user must match the two attributes, commit + trusted, of the requested page (the transaction one)
It's just an idea... flames are welcome.
Antenore, if you can and want, you could follow thinking about how to
integrate bank support (bank to use, design and libs to carry out the
implementation) according to the functionality we are going to develop.
I'm going to start a new thread about this point.
The project is not in a hurry.
Antenore.