View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000649||Main CAcert Website||web of trust||public||2008-10-18 09:39||2015-12-12 17:19|
|Status||needs review & testing||Resolution||open|
|Target Version||2015 Q2|
|Summary||0000649: verify that someone is an Assurer|
|Description||There needs to be a way for the Member to verify that someone is an Assurer.|
For an online system mechanism, it could be any of these variations to get confirmation:
1. type in an exact name.
2. type in an email address.
3. type in a code word selected by the Assurer.
4. send an email to a given address (might need additional control on/off as could be done by anyone).
5. some non-online mechanism such as business cards or security cards.
When the method is used, a confirmation of status should be shown: Member, Assured, Assurer. Optionally other information could be added, under control of the Assurer.
|Additional Information||DRAFT AP says "A Member may check the status of another Member, especially for an assurance process. Status may be implied from information in a certificate. The number of Assurance Points for each Member is not published." (as of today, it might change as it is still in DRAFT.) http://svn.cacert.org/CAcert/Policies/AssurancePolicy.html#2.3|
Member checking Assurer's status is necessary to establish the authority of the Assurance, to establish the mutuality and equality of the process, and to combat a potential identity theft. E.g., at some point, CAcert becomes valuable ("crosses GP") and becomes attacked for its value. One attack is to pretend to be an Assurer and ask people for their identity information.
Members should be taught to check the Assurer's status.
|Tags||No tags attached.|
|Test Instructions||see note (0005284)|
|related to||0000967||closed||egal||Main CAcert Website||Give an OA the oppertuntiy to check if a desiginated Organisation Admininistrator is a CAcert assurer|
|related to||0001253||needs review||egal||Main CAcert Website||Remove deprecated <font> formatting|
|related to||0001408||new||Main CAcert Website||API to return the Assurer Status to be used from CAcert systems|
Suggestion for Is Assurer Check:
A new page with a text box for the primary email address of a potential Assurer.
A dropdownbox with the reason why the information is needed e.g. Assurance, Event Preparation, Arbitration, CARS check, Organisation Assurance.
Once the form is send the result is not displayed on the screen. It is send to the requestor and the assurer via mail. The screen only shows the information that the mail was sent.
Mail to requestor:
you requested an Assurer check for the primary email address email@example.com for DROPDOWN info.
The account linked to this email address currently has / has not Assurer Status.
Mail to Assurer:
your Assurer Status was requested by REQEUSTER NAME, primary email address firstname.lastname@example.org for DROPDOWN info.
I pushed a fix to https://github.com/INOPIAE/CAcert/tree/bug-649.
Try to get the assurer status of an assurer, a non assurer and one email that is not list in the testserver.
in notary.inc.php for function get_user_id_from_mail:
1. we should be consistent on email vs. mail
2. trim should be the inner function call, thus trim first and then escape for the database.
3. The font tag is deprecated. Use span or div instead and possibly create a proper CSS class for it (or reuse an existing one).
4. Do proper indentation of the HTML in the file so the source doesn't look to messy. Names of tags should be lowercase (e.g. script at the bottem).
5. Why do we need sprintf on a translation without format string parameters?
6. Indentation for the notification on the web page doesn't need to be that far too the right.
I pushed a new fix to https://github.com/INOPIAE/CAcert/tree/bug-649
The font tag is handled in a seperate bug
||Dear Software Team, is there any progress on this bug?|
||I pushed a new fix to https://github.com/INOPIAE/CAcert/tree/bug-649|
||There was a dispute filed by BenBE and INOPIAE to check if this bug is allowed.|
I pushed a new fix to adjust the adminlog table
try to get the assurer status of at least 6 accounts
Check the mail box of the accounts if a mail arrived
If you check the sixth account within 1 hour you should get an message, that you are not allowed to proceed for the next hour.
no mail should be send now
Try the account again after 1 hour
Now it should work again
Did some tests from account email@example.com (Admin account), all checks within one hour, all mail adresses are @convey.de:
123, Is Assurer, Mail checked, OK
ted, Is Assurer, Mail checked, OK (this was my own account)
switch2, No Assurer, Mail checked, OK
switch1, No Assurer, failed see below
deleted2, No Assurer, Mail checkes, Probably OK
to_be_deleted2, Not found, OK but shouldn't there a limit to 5 checks?
deleted2, No Assurer, probably ok (repeated check)
to_be_deleted, No Assurer, OK but limit?
froehlich, Not found, OK is an additional address
deleted3, No Assurer, Failed account is deleted!
switch1 is an address that initially belonged to the account which is now switch2. If I request the status of switch1 the mail shows up in both Test Manager accounts, with target address switch1.
This may be a bug in the Test Manager, but it's a bit strange nevertheless...
Account deleted3 is reported as "No Assurer", but the account is deleted, so it should be reported as "Not found".
I guess it's intentional that only the primary mail address for an account is found.
deleted2 is a special account which should not occur in the production database since the USERS record is not marked as deleted but the corresponding EMAIL record is. I guess it's acceptable if the lookup finds such an account.
The limit did not cut in, maybe because I tested with an Admin-Account?
Another test with switch2 and switch1, now switch2 is Assurer, switch1 is not.
Checking correctly returns the status of both accounts.
Is there any limit how many requests one can send?
Is there a way to opt out?
Also I do not see the Arbitration reason. The bigger problem for Arbitration is to figure out the primary address, to begin with. In most cases this is not known to Arbitration. As to be able to test the assurance status the Arbitrator would first need to ask support for this. As there would be a need to ask support, anyway, any needed information - this could exclude the primary address - could be provided by support to Arbitration.
Also anybody could state to just ask for an arbitration reason. IF this would be implemented, it should only be possible for members of the arbitration team, as this could be missused anyway. Currently the software does not have a flag for a member of the assurance team
|2008-10-18 09:39||iang||New Issue|
|2012-05-28 10:50||INOPIAE||Relationship added||related to 0000967|
|2013-01-11 16:13||Werner Dworak||Status||new => needs work|
|2014-01-21 10:23||INOPIAE||Note Added: 0004532|
|2014-02-22 19:39||INOPIAE||Note Added: 0004596|
|2014-02-22 19:39||INOPIAE||Assigned To||=> BenBE|
|2014-02-22 19:39||INOPIAE||Status||needs work => fix available|
|2014-02-25 22:36||BenBE||Note Added: 0004610|
|2014-03-02 11:22||INOPIAE||Relationship added||related to 0001253|
|2014-03-15 13:10||INOPIAE||Note Added: 0004640|
|2014-03-15 13:11||INOPIAE||Note Edited: 0004640||View Revisions|
|2014-06-05 21:51||Benedikt||Note Added: 0004795|
|2014-06-07 20:20||INOPIAE||Note Added: 0004804|
|2015-01-25 12:34||BenBE||Assigned To||BenBE => egal|
|2015-01-25 12:34||BenBE||Status||fix available => needs review & testing|
|2015-01-25 12:34||BenBE||Product Version||=> 2008|
|2015-01-25 12:34||BenBE||Target Version||=> 2015 Q2|
|2015-01-26 05:44||Eva||Note Added: 0005279|
|2015-01-28 09:06||INOPIAE||Note Added: 0005283|
|2015-01-28 09:25||INOPIAE||Note Added: 0005284|
|2015-01-28 09:26||INOPIAE||Test Instructions||=> see note (0005284)|
|2015-01-28 16:30||Ted||Note Added: 0005296|
|2015-01-28 16:42||Ted||Note Added: 0005297|
|2015-02-03 19:55||Eva||Note Added: 0005299|
|2015-03-03 20:18||INOPIAE||Note Edited: 0005284||View Revisions|
|2015-10-20 20:14||BenBE||Assigned To||egal => Eva|
|2015-12-12 17:19||INOPIAE||Relationship added||related to 0001408|