* Case Number: a20140305.1 * Status: closed * Claimant: Michael T * Respondent: Joseph S, Dirk A * initial Case Manager: EvaStöwe * Case Manager: MartinGummi * Arbitrator: EvaStöwe * Date of arbitration start: 2014-03-05 * Date of ruling: 2014-03-18 * Case closed: 2014-04-06 * Complaint: Date of Birth in account * Relief: TBD Before: Arbitrator name arbitrator (A), Respondent: Joseph S (R1), Dirk A (R2), Claimant: Michael T (C), Case: a20140305.1 == History Log == . 2014-03-05 (issue.c.o): case [s20140305.111] . 2014-03-05 (iCM): added to wiki, request for CM / A . 2014-03-05 (iCM): notified C, R1, R2 about case . 2014-03-05 (CM): I'll take care of this case and select Eva Stöwe as (A) . 2014-03-05 (A): chat with C, if C has issues with A also having assured the member with the DoB in question - C has no issues, but thinks that it is a good thing, if A can bring personal knowledge to the case . 2014-03-05 (A): init mailing to C, R1, R2 (A, CM) . 2014-03-05 (A): asks R1 and R2 about the DoB on their CAP forms and to bring the CAP forms to personal meeting . 2014-03-06 (A, R2): R2 has no issues with A also having assured the member with the DoB in question - R2 has no issues, but thinks that it is a good thing, if A can bring personal knowledge to the case - R2 tells A the DoB on CAP form (per phone) . 2014-03-06 (R1): tells the DoB on his CAP form - does not want to bring CAP form to personal meeting - sends scan of DoB . 2014-03-10 (A): answers R1 that A does not see a reason to not bring the CAP form . 2014-03-15 (A, CM, R2): R2 shows CAP form to A and CM; A tells R2 about other known dates; special implications of R2 being a co-auditor and a possible solution / ruling of the case is discussed (in person) . 2014-03-15 (A, CM, R1): R1 has no issues with A also having assured the member with the DoB in question; R1 shows CAP form to A and CM; A tells R1 about other known dates; special implications of R1 being a co-auditor and a possible solution / ruling of the case is discussed (in person) . 2014-03-18 (A): ruling send to C, R1, R2, assuree, support and CM. . 2014-04-06 (A): closing == Private Part == * '''Link to Arbitration case [[Arbitrations/priv/a20140305.1|a20140305.1 (Private Part)]], Access for (CM) + (A) only''' ## ==> INCLUDE SECTION BOT <> ## <== INCLUDE SECTION EOT ==== EOT Private Part ==== == original Dispute == {{{ > Hi [name of member with account in question], > > I have CCed CAcert Support, they'll know what to do. > > > On 05.03.2014 13:12, [member with account in question] wrote: > > Hi [C], > > > > You are right. I see that my profile it is reported as [a date] however > > I am not able to change it. Can you change it to [another date] or do you > > know how can I do it? > > > > Best Regards > > > > [member with account in question] > > > > > > On Wed, Mar 5, 2014 at 1:04 PM, [member with account in question] wrote: > > > > Hi [C], > > > > It is [birth date] > > > > Best Regards > > > > [member with account in question] > > > > On Wed, Mar 5, 2014 at 12:25 PM, [C] wrote: > > > > Hi [member with account in question], > > > > I just wanted to enter the Assurance we did at FOSDEM (soory > > that I'm a > > little late) but the date of birth in your account doesn't match > > the one > > I have on record. Could you please verify that the date of birth > > on your > > account is correct and if it isn't change it and notify me? > > > > If you already received some Assurances then you can't change > > the DoB > > yourself. In that case please write an email to > > support@c.o and > > tell them that I can witness the correct DoB. > > > > -- > > Cheers, > > [C] > > [C] }}} parts in [] anonymized accordingly == Preliminary considerations == A has also assured the member with the date of birth (DoB) in question, but did not decide to enter the account or how to proceed. A conflict of interest (CoI) has to be considered. Since A did not come to a decision on how to proceed and what is the correct DoB before the case was known to her (which A could demonstrate with mails) it is hard to define where such a conflict would be substanciated. A asked C, R1 and R2 if they would regard this as a problem (before A told them about the DoB on her CAP form). All agreed that they do not see an issue with A also having assured the assuree. On the contrary all found it helpful, that A could also bring additional information to the case. As all parties (including the CM and A) did not consider this situation as a CoI (and another person outside of the case also came to this conclusion), a CoI for this case has to be negated. (If one party would have an issue with such a constellation the decision should be otherwise!) == Discovery == * When C tried to enter the assurance C detected that there was a discrepancy between the DoB in the account and the one on the CAP form. * C contacted the member of the account who answered that the DoB in the account was wrong and tried to change it, but could not do so, because there were already assurances from R1 and R2 on the account * C contacted support about this. === DoB in the account === * A also had assured the member and detected the discrepancy, but had not decided how to proceed. (The according CAP form was shown to the CM of this case.) * Both R1 and R2 showed their CAP forms to A and CM. * All CAP forms that were examined, showed the same DoB. * This DoB matches the DoB C found on his CAP form. * The member with the account also declared this date as his DoB. * The DoB in the account did not appear anywhere else. So it has to be assumed to be wrong. * As there are 4 CAP forms indicating the same DoB, and the assuree also giving this date as the correct DoB, it could be set to this date by support. * Since neither R1 nor R2 have a doubt in the assurance as such, their assurances do not have to be removed, if R1 and R2 do not ask for this. === Wrong DoB entered by R1 and R2 === * One may not enter an assurance with wrong DoB (or only to block a change of the account, directly followed with a dispute if one suspects malevolence on the side of the assuree). * By entering an assurance one gives a [[AssuranceHandbook2#CAcert_Assurer_Reliable_Statement_-_CARS|CAcert Assurer Reliable Statement (CARS)]] that the data entered is correct. * If this is incorrect, the [[https://secure.cacert.org/policy/CAcertCommunityAgreement.php|CCA]] 1.2 ("You are obliged [...] to make no false representations.") * Even if this is not done purposefully. * When interviewing separately and in person, R1 and R2 both reacted compunctiously when informed about the date in the account. The assurance of the wrong DoB was obviously an error and not done by purpose. * When asked during the interview what they would propose to solve this case, both answered that a reprimand would be appropriate. * R1 and R2 are co-auditors. * Co-auditors are very experienced assurers specially trained to train and test other assurers with their assurances. * As such they should be aware of the importance to check a DoB carefully, before entering an assurance in the account. * R1 and R2 both have made the same kind of mistake, before (as can be seen in the list of similar cases). However non action was taken against them in that cases. Soon it will not be possible to make such an error again, since there is a new patch [[https://bugs.cacert.org/view.php?id=1226|bug bug1226]] waiting on software side to go life (when it reaches the needed test and review status) that will force to enter the DoB together with the e-mail of the assuree to be able to enter the assurance. So this will hopefully help to prevent R1 and R2 to make such an error again. Nonetheless they should be warned to be more careful in the future. It is human to make mistakes, but one should be careful when entering assurances and one should be aware of possible consequences and accept them, if one is not careful enough. Both respondents proposed to give them a reprimad as remediy in the ruling, when asked how they would rule in this case. During the interview both respondents complained independently about not getting enough assurance re-training as co-auditors. While they train others they get no training themselves. They asked A to inform the internal auditor officially about this issue, as the co-audit program was initiated by the last internal auditor. == Ruling == * Support should set the date of birth of [the account in question] to [the date everybody has agreed on]. * There is no need to remove the assurances of R1 and R2 from the account by support per ruling. But if one of them asks to get his removed, support may do so without another ruling. Any other assurance support finds on the account when changing the date of birth, should be reported to this case. * As the assuree was not aware that he entered a wrong date and instantly tried to correct it, when he was informed about his mistake, no action should be taken against the assuree because of the wrong entry. * R1 and R2 should regard this ruling as a reprimand and acknowledge this. They have to inform any arbitrator of any arbitration case, evolving around potential assurance errors done by them in the future, about this ruling. An arbitrator in such a case should consider to issue a (monetary) penalty against them. Currently open arbitration cases should not be affected. * The Assurance Officer should be informed by A or CM about said assurances and this ruling, because of R1 and R2 being co-auditors. No further action should be implied by doing so. * The Assurance Officer, Education Officer and the internal auditor should be informed by A or CM about the complains of R1 and R2 about too little co-auditor trainings. Hamburg, 2014-03-18 == Execution == . 2014-03-18 (A): ruling send to C, R1, R2, assuree, support and CM. . 2014-03-18 (A): send execution order to support . 2014-03-18 (Support): changed DoB in account . 2014-03-18 (A): informed AO, EO, internal auditor about ruling . 2014-03-19 (A): informed AO as team leader of the issues in the assurances done by R1 and R2 . 2014-03-19 (AO): officially asks A for a ruling that orderes a re-training of R1 and R2 because of the issues, first reaction of A is that she thinks that AO has all needed authority to order such himself as AO, if he thinks this to be appropriate (per voice during SAP-session) . 2014-03-21 (A): excution order to R1, R2 - information that AO, EO, internal auditor will be addressed by their complains . 2014-03-24 (A): informed internal auditor, AO, EO about complaints from R1 and R2 . 2014-03-24 (A): forwarded information to internal auditor, AO, EO about complaints from R1 and R2 to R1 and R2 . 2014-03-29 (A): reminds R1 and R2 to acknowledge the ruling as defined in the ruling . 2014-03-29 (R1): ack that he has read the ruling . 2014-03-29 (A): asks board for a motion to define if an officer may order (re)trainings of their teams . 2014-03-28 (R2): ack ruling (in person) . 2014-03-30 (board): [[https://community.cacert.org/board/motions.php?motion=m20140330.8|m20140330.8]]: Team leaders to manage training all teams to think about training processes and if necessary define and document them . 2014-03-30 (A): informs AO that he may order re-trainings as he seems needed, according to the board motions. == post Arbitration activity == . 2014-06-06 (internal Auditor): responding to A that partly based on the finding in this case, he plans to take over the Co-audit program into the audit area . 2014-06-06 (A): welcomes the idea of someone addressing the found problems, warning that the mentioned approach my violate policies, but as the internal auditor has good reasons advising the affected teams to support the internal auditor and his idea - while declaring to have no special authority in this regard, since the case was closed == Similiar Cases == || [[Arbitrations/a20110813.1|a20110813.1]] || [[Arbitrations/a20110813.1|DoB mismatch (Matthias S) ]] || || [[Arbitrations/a20090701.1|a20090701.1]] || [[Arbitrations/a20090701.1|Account contains incorrect DoB, is assured to 35 points ]] || || [[Arbitrations/a20090702.2|a20090702.2]] || [[Arbitrations/a20090702.2|account contain wrong DoB, addtl. wrong suffix, and have Assurance Points]] || || [[Arbitrations/a20120220.1|a20120220.1]] || [[Arbitrations/a20120220.1|DoB discrepancy in acount]] || || [[Arbitrations/a20090510.1|a20090510.1]] || [[Arbitrations/a20090510.1|User was assured with the wrong DoB]] || || [[Arbitrations/a20090510.2|a20090510.2]] || [[Arbitrations/a20090510.2|User was assured with the wrong DoB]] || ---- . CategoryArbitration . [[CategoryArbCaseAccountDataDoB]]