• Arbitrations
• a20090702.2

• Case Number: a20090702.2
• Status: closed
• Claimants: walter güldenberg (walter at sidux-ev dot de), Sebastian K.
• Respondents: s.j.boser at gmx dot de, harald.schnitzler at gmx dot de

• Case Manager: BernhardFröhlich

• Arbitrator: UlrichSchroeter

• Date of arbitration start: 2009-10-26
• Date of ruling: 2010-02-22
• Case closed: 2010-02-23
• Complaint: DoB error in account, wrong suffix in account

hello,
during the assurance at linuxtag 2009, 3 or maybe more ppl. setup the
cacert account with wrong dob data.
i gave them note to change it. one could do it, because he didn't earn
assurance points before i saw the mistake, he change an so i could give
him the points.
the other 2 had points on the account, so they can't change the dob. i
ask support@cacert.org and they adviced me to go in contact with you.
here the details:
s.j.boser at gmx dot de
wrong: 1969-08-08
right: 1969-08-18 (as in the id)
harald.schnitzler at gmx dot de
wrong: 1963-01-26
right: 1963-05-26 (as in the id)
is there a way to change the dob to the right data?

kind regards
walter güldenberg

• Relief: TBD

Before: Arbitrator UlrichSchroeter (A). Respondent: S.J.Boser (R1), Harald Schnitzler (R2) Claimant: Walter Güldenberg (C) Sebastian K. (C2), Case: a20090702.2

History Log

Note from CM: R1 initiated her own case a20090701.1

• 2009-10-26 A: CM, please request from support who has assured those accounts.
• 2009-10-27 A: Request for CCA / DRP acceptance from (C), (R2)
• 2009-11-04 A: Reminder: Request for CCA / DRP acceptance from (C), (R2)
• 2009-11-04 CM: no response from support c.o yet

• 2009-11-04 A: Request for CCA acceptance of (R2) made on a CAP form thru the CARS program from (C)

• 2009-11-04 R2: the assurance was made at Linuxtag Berlin 2009, please correct or account removal

• 2009-11-04 A: requesting infos from addtl. potential 9 assurers from Linuxtag Berlin 2009 as support at c.o is unresponsive at the moment

• 2009-11-04 A: one assurer states that there is also a name typo ('hs' as name suffix) in the (R2) account that he hasn't seen on any ID document

• 2009-11-09 A: 4 of 9 potential assurers from Linuxtag Berlin 2009 answered. From 3 assurers, the response wasn't helpful.

• 2009-11-09 A: re-requesting infos from addtl. potential 5 assurers from Linuxtag Berlin 2009 as support at c.o is unresponsive at the moment

• 2009-11-09 A: Re-Request for CCA acceptance of (R2) made on a CAP form thru the CARS program from (C)

• 2009-11-09 C: states that (R2) accepted CCA on CAP form
• 2009-11-11 A: re-requesting infos from addtl. potential assurers

• 2009-11-14 Support reports Assurers that have assured R2 are Heinrich W. and Christian H. Account of R1 has been deleted in accordance to a20090701.1.

• 2009-11-15 A: requesting CAP scan from Christian H.
• 2009-11-15 A: requesting CAP scan from Heinrich W.
• 2009-11-17 A: resend CAP scan requests as of possible mail loss to Christian H. and Heinrich W.
• 2009-11-27 A: resend CAP scan requests to Christian H. and Heinrich W. (reminder)
• 2009-12-08 A: resend CAP scan requests to Christian H. and Heinrich W. (reminder)
• 2009-12-25 A: rcvd answer from Hanno B. in reply to the global request to all assurers from Linuxtag Berlin dated Nov 4th. Hanno didn't assured (R2)
• 2009-12-25 A: last request: CAP scan requests to Christian H. and Heinrich W. (reminder). Deadline: Jan 8th, 2010
• 2009-12-26 A: rcvd CAP scan from Christian H. that confirms the requested DoB correction
• 2010-01-12 A: deadline for CAP form scan request passed for Heinrich W. Offer for step-by-step execution of DoB correction, Assurance points transfer from (C), Assurance revocation of Heinrich W. assurance to (R2)

Discovery

• 2009-11-04: the account has actual issued 70 assurance pts
• 2010-01-12: proposal execution plan for arbitration closure
  1. execution request to support to correct DoB
  2. exec report to (A) from support
  3. execution request to (C) to complete assurance and assurance points transfer to account to prevent decrease of assurance points rcvd
  4. exec report to (A) from (C)
  5. execution request to support for assurance revocation or assurance from Heinrich W.
  6. exec report to (A) from support
  7. arbitration case closure
• there was no malfeasance of an type alleged or found
• 1 of 2 Assurers who did assurance over (R) before dispute filing, has verified by a CAP form scan that the DoB in question is to be the same as (C) states.
• 1 Assurer has a valid CAP with the correct DoB, 2nd Assurer didn't respond
• there is no certs problem in this case, because certs doesn't include a DoB
• The Assurer 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.

Ruling

• One Assurer and (R2) 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.
• Further I rule, that the assurance from Heinrich W. should be revoked, because he didn't answered to the requests for a CAP form scan and therefor doesn't fullfil his obligations as given thru CCA 2.3 Obligations - clause 1. statement and therefor assurance is still in question.
• Since the DoB error 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 two independent CAcert members about the correct DoB and also from (R2), 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
• This problem (DoB wrong) was due to a hasty typo by (R2) so the account contains the wrong DoB
• 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 2 Assurers. Only the 3rd Assurer found this problem.

• This confirms the problems regarding DoB errors found at the starting of the Audit over Assurances (see report MiniTOP Assurance - Munich 20090517) with a failure rate of 50% (!). This was too high. So therefor this topic has been added to the Assurer Training Events 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 one of both Assurers just entered the Assurance points given.
• 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 Feb 22nd, 2010

Ruling #2

• The name in the account contains a suffix, that cannot be confirmed to be on any ID document, stated by a 3rd Assurer, that also isn't stated by the CAP form scan rcvd from Assurer Christian H.
• So therefor I rule to remove the suffix from the name field in this account.
• The removal of addtl. name parts isn't in any conflict to existing assurances.
• Client Certificates that has been created by the user after 2009-11-08 and includes the wrong suffix in the cert, must be revoked by the user regarding CPS 3.1.1. Types of names - CN= The common name takes its value from one of: ... * For individual Members, a Name of the Subscriber, as Assured under AP

Frankfurt/Main Feb 22nd, 2010

Execution

• 2010-02-22 (A): Ruling
• 2010-02-22 (A): sent ruling notification to (C), (R2), (CM), assurers
• 2010-02-22 (A): Ruling #2 regarding "wrong suffix in account name"
• 2010-02-22 (A): sent ruling notification to (C), (C2), (R2), (CM), assurers
• 2010-02-22 (A): sent execution order request to support to 1. remove one assurance, 2. correct the DoB, 3. remove addtl. suffix in name, requesting confirmation of execution
• 2010-02-22 (A): Advice sent to Christian H., Heinrich W.
• 2010-02-22 (Support): order request is executed
• 2010-02-23 (A): sent notification to (C), (C2) that corrections are executed, they now can enter the assurance onto (R2)'s account.
• 2010-02-23 (A): case closed.

Similiar Cases

• CategoryArbitration

• CategoryArbCaseAccountDataDoB