* Case Number: a20140129.1
  * Status: running
  * Claimant: Adolf A.
  * Respondent: CAcert
  * initial Case Manager: BernhardFröhlich
  * Case Manager: EvaStöwe
  * Arbitrator: BernhardFröhlich
  * Date of arbitration start: 2014-03-29
  * Date of ruling: 201Y-MM-DD
  * Case closed: 201Y-MM-DD
  * Complaint: Accidentially assured wrong DoB in account

  * Relief: Revoke Assurance

Before: Arbitrator BernhardFröhlich (A), Respondent: CAcert (R), Claimant: Adolf A. (C), Case: a20140129.1


== History Log ==
 . 2014-01-29 (issue.c.o): case [s20140129.99]
 . 2014-03-28 (iCM): added to wiki, request for CM / A
 . 2014-03-29 (A): volunteers to be A in this case and EvaStöwe has agreed to be CM
 . 2014-03-30 A sent initiating mail, asking about the delay between recording of Assurance and sending of the notification.
 . 2014-03-30 C replies that he's currently abroad and may not be able to react quickly in the future.
 . 2014-04-06 A: Intermediate Ruling given
 . 2014-04-06 A: Sent execution request to Support
 . 2014-04-06 A: Sent mail to C about Intermediate Rulig.

== Private Part ==

 * '''Link to Arbitration case [[Arbitrations/priv/a20140129.1|a20140129.1 (Private Part)]], Access for (CM) + (A) only'''

## ==> INCLUDE SECTION BOT
<<Include(Arbitrations/priv/a20140129.1)>>  
## <== INCLUDE SECTION EOT

==== EOT Private Part ====

== original Dispute ==
(translated and anonymized by iCM)
 {{{
Hello,

I noticed that in Assurance xxxxxx the wrong DoB was assured.

The ID documents and the CAP form did contain the DoB DD.MM. In the account the DoB is set to CC.MM.

I noticed the problem but hit the wrong button, so the Assurance was accidentially commited to the system.

I ask for the Assurance to be revoked.

}}}

== Discovery ==

 * There have been requests by Support to re-evaluate [[Arbitrations/a20100210.2|a20100210.2]] and maybe update the procedure considering experiences made since this ruling. Two proposals were made:
  * Add a feature to the software so Assurers may revoke an Assurances themselves up to 24 hours after the Assurance has been made.
  * As a rule, Support may revoke an Assurance on request by the Assurer immediately and require Arbitration only in "problematic" cases.
 * Since 2010 a total of 31 Assurances have been revoked according to a20100210.2
 * One Problem related with revoking Assurances is how Experience Points are affected by revoked (and redone) Assurances
  * According to tests on the testsystem: The "new" points calculation does not count experience points for revoked Assurances
  * In the "old" points calculation the experience points are extra point increases which must be revoked on their own.
 * The Assurance may only be easily revoked if it is the only one on the assured account. Otherwise there might be certificates issued by accounts not confirming to the CPS.
 * If Assurances can be revoked by the Assurer herself some kind of statistics should be installed to evaluate revocations for potential abuse.
 * It may make sense to differentiate between "typo" and "real" cases:
  * "Typo" cases concern non-critical data, like the date and place of the assurance. This data is not relevant for certificates, and do not relate directly to the policy statements.
  * "Real" cases concern name and DoB, and potential other data provided by the Assuree. These data is considerably more critical, since it may be included in certificates, and differences sometimes indicate problems in the Assurance process.
 * The fix to [[https://bugs.cacert.org/view.php?id=1226|Bug #1226]] changes the "Assure Someone" application, so the DoB of the Assuree must be entered by the Assurer, without showing the DoB from the database. This should significantly reduce the number of cases where a wrong DoB is accidentially assured.

=== Concerning the current case ===

 * C's Assurance is the only one on the assured account. The Assurance prevents the owner of the assured account to correct the mistake.

== Ruling ==

=== Intermediate Ruling 1 ===

The Assurance in question is the only one on the assured account. Therefor it is not possible that certificates with invalid content have been issued.

I order that Support shall revoke the Assurance. The Claimant shall notify the owner of the assured account about the mistake in the account, and may redo the Assurance once the data in the account is correct.

Munich, 2014-04-06


== Execution ==

 . 2014-04-07: Support reports the Assurance in question has been revoked. C and the owner of the account have been notified by Support.

== Similiar Cases ==

|| [[Arbitrations/a20100210.2]] || Precedence ruling for revoking Assurances by Support ||
|| [[Arbitrations/a20101016.1]] || Clarifications to a20100210.2 ||
|| [[Arbitrations/a20111204.3]] || Precedence Ruling for minor account differences ||

----
 . CategoryArbitration
 . [[CategoryArbCaseAccountDataDoB]]