* Case Number: a20090625.1 * Status: closed * Claimants: Stefan Freudenberg * Respondents: Matthias Petschick * Case Manager: BernhardFröhlich * Arbitrator: UlrichSchroeter * Date of arbitration initialize: 2009-06-26 * Date of arbitration start: 2009-11-04 * Date of ruling: 2010-01-12 * Date closed: 2010-07-07 * Complaint: DoB recorded in account is incorrect, addtl typo in date of assurance {{{ The date of birth recorded is not correct. When attempting to assure him I noticed a mismatch with the information he provided on the CAP form verified by his ID card. The member has already confirmed that he made a mistake when creating his account. Nevertheless he has been issued 85 points. }}} * Relief: to be corrected Before: Arbitrator Ulrich Schroeter (A). Respondent: Matthias Petschick (R) Claimant: Stefan Freudenberg (C) Case: a20090625.1 == History Log == . 2009-06-26 CM: Sent initial email . 2009-06-26 C: Sent response, accepts CCA and gives viewpoint . 2009-10-26 A: reminder request for accepting CCA / DRP to R . 2009-10-26 A: CM, please request from support who has assured this account. . 2009-11-04 A: Reminder: Request for CCA / DRP acceptance from R . 2009-11-04 CM: no response from support c.o yet . 2009-11-04 R: questions regarding arbitration process, and answered by (A) . 2009-11-04 R: accepts CCA / DRP . 2009-11-04 A: requested infos about assurance from (C) . 2009-11-04 A: requested infos about assurance from (R) . 2009-11-04 C: the assurance was made at [[events/LinuxTag2009|Linuxtag Berlin 2009]] at June 25th 2009 . 2009-11-04 A: requesting infos from addtl. potential assurers (9) from [[events/LinuxTag2009|Linuxtag Berlin 2009]] as support at c.o is unresponsive at the moment . 2009-11-09 A: rcvd needed infos from (R) . 2009-11-09 A: 3 of 9 addtl. potential assurers from [[events/LinuxTag2009|Linuxtag Berlin 2009]] answered, wasn't helpful to this case. . 2009-11-09 A: re-requesting infos from addtl. potential assurers (6) from [[events/LinuxTag2009|Linuxtag Berlin 2009]] as support at c.o is unresponsive at the moment . 2009-11-10 A: notification from support: currently the support team doesn't have the resources to make such investigations in the system . 2009-11-10 CM: please keep this as a standing request for the time when there are more resources available . 2009-11-11 A: requesting addtl. assurances from (R) with experienced assurers to prevent assurance points revocation . 2009-11-11 A: re-requesting infos from addtl. potential assurers . 2009-11-14 Support reports Assurers that have Assured the Respondent: || Bart-Jan V. || 20 Points || {{attachment:choice-yes.gif}} || || Daniel L. || 25 Points || {{attachment:choice-yes.gif}} || || Robert B. || 15 Points || {{attachment:choice-yes.gif}} || || Sebastian D. || 15 Points || {{attachment:choice-yes.gif}} || || Jan B. || 15 Points || {{attachment:choice-yes.gif}} || || Christian H. || 15 Points || {{attachment:choice-yes.gif}} || . 2009-11-15 A: requesting CAP scan from Christian H. . 2009-11-15 A: requesting CAP scan from Jan B. . 2009-11-17 A: rcvd a note, that the request from Nov 15th didn't rcvd by Jan B. in the meanwhile. Sending both requests again. . 2009-11-27 A: requesting CAP scan from Christian H. and Jan B. . 2009-12-01 A: rcvd encrypted email from Jan B. that i cannot handle. Sending request to (CM) of beeing a proxy or Jan B. changing to S/MIME encryption . 2009-12-01 A: send request for DoB from 4 addtl. assurers, who assured Matthias in 2008. . 2009-12-01 A: walking thru the list of Assurers before, one addtl. typo was unseen before, the date of assurance is stated to the year 1008 (highlander II) . 2009-12-01 A: CAP form from Jan B. states DoB to be the same as (C) states. . 2009-12-01 A: CAP form from Robert B. states DoB to be the same as (C) states. . 2009-12-08 A: sent reminder to assurers: Bart-Jan, Daniel, Sebastian, Christian . 2009-12-08 A: CAP form from Bart-Jan states DoB to be the same as (C) states. . 2009-12-08 A: CAP form from Sebastian D. states DoB to be the same as (C) states, Assurance date was year 2008 . 2009-12-08 A: response from Christian H., not at home yet, delayed . 2009-12-08 A: CAP form from Daniel L. states DoB to be the same as (C) states. . 2009-12-13 A: sent reminder request for CAP form or DoB info to Christian H. . 2009-12-25 A: sent reminder request for CAP form or DoB info to Christian H. . 2009-12-26 A: rcvd email from Christian H.: was this also Linuxtag Berlin ? . 2009-12-26 A: answer to Christian H.: Yes, this was also Linuxtag Berlin. . 2010-01-05 A: from IRC log: (FS) i have met Matthias at 26c3 and assured him. DoB is wrong in his account. . 2010-01-05 A: send CAP form scan request to Fabian, who assured Matthias at 26c3 . 2010-01-05 A: CAP form from Fabian states DoB to be the same as (C) states. . 2010-01-05 A: phone call with Christian H. about CAP not found . 2010-01-05 A: intermediate ruling . 2010-01-11 A: reminder request for CAP form scan to Christian H. including deadline: Mo Jan 18th, 23:59 . 2010-01-12 A: CAP form from Christian H. states DoB to be the same as (C) states. . 2010-01-12 A: ruling == Discovery/Investigations == * The correct DoB has been verified by the (C) and a scan of (R)'s ID doc * Support cannot deliver a list of assurers who have assured (R) before in a timely fashion caused by lack of resources * Requesting at least 2 addtl. Assurances * 2009-11-14 Support has sent a list of assurers who assured Matthias before the problem has been identified. * 2009-12-01 A: walking thru the list of Assurers before, one addtl. typo was unseen before, the date of assurance is stated to the year 1008, that needs also to be corrected. * there was no malfeasance of an type alleged or found * all 6 Assurers who did assurance over (R) before dispute filing, have verified by a CAP form scan that the DoB in question is to be the same as (C) states. * all 6 assurers have a valid CAP with the correct DoB. * there is no certs problem in this case, because certs doesn't include a DoB * The assurers in question, displayed in above table, hadn't the full points awarded, at the time of assurance, nor did they attend an ATE before the assurance were made. * Assurance Date wrong - technical background * Though the database stores the date of completion if the web assurance form automatically (notary.when) only the date of the meeting (notary.date) which is entered by the Assurer is shown a read only in the support interface. * A workaround would be to revoke the Assurance from the support interface and then notify the Claimant that he should repeat his Assurance == Intermediate Ruling == * 6 Assurers confirms to the DoB change request. So I order hereby to support, that the DoB of the account in question has to be corrected to the requested date immediately. * Further I rule, that the assurance from Sebastian D. should be revoked, caused by a wrong assurance date (year 1008 instead of 2008), so that the assurer can correct the mistake (Support cannot change the assurance date). * The assurance from Christian H. is still unverified and is still in question. * Since this is a minor and understandable mistake no further action is needed against those Assurers. Given that all of them could provide reliable evidence about the facts on short notice shows their dedication when doing Assurances. * Since there are statements by six independent CAcert members about the correct DoB, all Assurance Points from those of assurers who confirmed the correct DoB are still valid and no forther change is needed. * there was no malfeasance of an type alleged or found * Both problems (DoB wrong, Assurance date wrong) was due to a hasty typo so the account contains the wrong DoB and a wrong assurance date Frankfurt/Main, Jan 5th 2010 == Ruling == * Due to the facts found under discovery I hereby rule, that the intermediate ruling dated Jan 5th 2010 is still valid. * Additionaly the mistakes that were made regarding the wrong accounts DoB is a 100% failure to enter the DoB into the account by a new member (this is to excuse) and also by verifying the data given in the assurances by six assurers. Only the 7th assurer found this problem. * This confirms the problems regarding DoB errors found at the starting of the Audit over Assurances (see report [[https://svn.cacert.org/CAcert/Assurance/Minutes/20090517MiniTOP.html|MiniTOP Assurance - Munich 20090517]]) with a failure rate of 50% (!). This was too high. So therefor this topic has been added to the [[comma/RegularCampaigns/AssurerEvents/AssurerTrainingEvents|Assurer Training Events]] [[https://svn.cacert.org/CAcert/Education/Material/v3-mrmcd/DE/CAcert-07_foreign_Passports_DE_v3.odp|ATE presentations - Foreign Passports (incl. Date errors)]] (slide 8 and 9). * The DoB correction is to be made without the removal of any assurance or experience points if assurers have a valid CAP with the correct DoB. This was verified by receiving the CAP form scans from the assurers. * The assurance from Christian H. that was still unverified at the time of intermediate ruling is no longer in question. * The execution that followed the intermediate ruling has been finished. * However, the assurers have to receive an advice regarding DoB checking failures and how to prevent them and about the obligation in doing a 2nd data check between CAP form and account data if they enter the assurance points into the 'assure someone' online form. Frankfurt/Main Jan 12th 2010 == Post-Arbitration-Ruling == Post-Arbitration-Ruling against Assurer: Christian H. in Arbitration Case a20090625.1 ==== Deliberation ==== regarding Arbitration case [[Arbitrations/a20090625.1|a20090625.1]] I've wrote the ruling dated 2010-01-12 I've sent out Assurers advice with the request of confirmation: 2010-01-12 A: sent out Assurers advice with confirmation request to 6 Assurers (DE), awaiting confirmations I've sent out a reminder about the confirmation dated 2010-01-29 but still got no answer from Christian H. till today. I will bring to your attention, that not answering in an Arbitrators request can be read as a non-response from the Assurer. This raises the question, what action to take next. * CCA 3.5 Communication * ... Notifications to you are sent by CAcert to the primary email address . registered with your account. You are responsible for keeping your email . account in good working order and able to receive emails from CAcert. * Arbitration is generally conducted by email. * and DRP 2.1 Authority * The Board of CAcert and the Users vest in Arbitrators full authority . to hear disputes and deliver rulings which are binding on CAcert and the Users. * and an implication of the 2.6 Remedies and the Arbitration Act. . In short: if a user refuses to respond, the termination of the account is the next step. ==== Ruling ==== As Christian has answered the emails before but did not respond with a confirmation to the Assurers advice, I hereby rule a post-arbitration-ruling fine of 10 Euro, or 1 hour work for CAcert if Christian H. () will not respond within the next 14 days the Assurers advice confirmation (see attachment). Deadline set: Monday, 28th of June 2010, 23:59 Frankfurt/Main, 2010-06-14 == Execution == . 2010-01-05 A: execution request to support for the intermediate ruling . 2010-01-05 A: rcvd execution report from support for the intermediate ruling . 2010-01-06 A: sent order to Sebastian D. to re-apply the assurance points transfer onto (R)'s account . 2010-01-06 A: notification to assurer (FS), that he now can transfer his assurance points . 2010-01-06 A: Sebastian D. reports assurance points transfer onto (R)'s account reapplied . 2010-01-12 A: notifications sent to (C) and (R) about the ruling . 2010-01-12 A: sent out Assurers advice with confirmation request to 6 Assurers (DE), awaiting confirmations . 2010-01-12 A: rcvd mail from Bart about translation to EN . 2010-01-12 A: sent out english version of the Assurers advice with confirmation request to Bart || Bart-Jan V. || {{attachment:choice-yes.gif}} || || Daniel L. || {{attachment:choice-yes.gif}} || || Robert B. || {{attachment:choice-yes.gif}} || || Sebastian D. || {{attachment:choice-yes.gif}} || || Jan B. || {{attachment:choice-yes.gif}} || || Christian H. || {{attachment:choice-yes.gif}} || . 2010-01-13 A: rcvd confirmation from Sebastian . 2010-01-13 A: rcvd confirmation from Jan . 2010-01-19 A: rcvd confirmation from Robert . 2010-01-29 A: sent reminder to Christian, Daniel, Bart . 2010-01-29 A: rcvd email from Daniel, don't understand reminder . 2010-01-30 A: sent out english version of the Assurers advice with confirmation request to Daniel . 2010-02-02 A: rcvd confirmation from Daniel . 2010-02-17 A: rcvd confirmation from Bart . 2010-06-13 CM: progress report request from (A) . 2010-06-14 (A): post-arbitration-ruling against Assurer Christian H, not to respond about the Assurers advice confirmation, set with deadline . 2010-07-06 (CM): deadline for Christian H has passed. How to proceed ? . 2010-07-07 (A): forwarding of post-arbitration-ruling and reminder to Christian H . 2010-07-07 (A): rcvd reply from Christian H, was on vacation this time . 2010-07-07 (A): case closed == Similar Cases == || [[Arbitrations/a20090510.1|a20090510.1]] || User was assured with the wrong DoB || || [[Arbitrations/a20090513.1|a20090513.1]] || User was assured with the wrong DoB || || [[Arbitrations/a20090510.2|a20090510.2]] || User was assured with the wrong DoB || ---- . CategoryArbitration . [[CategoryArbCaseAccountDataDoB]]