* Case Number: a20090619.1 * Status: closed * Claimants: Antonius L F Huiskens * Respondents: CAcert * Case Manager: Alexander Prinsier as substitute for Nick Bebout * Arbitrator: UlrichSchroeter * Date of arbitration init: 2009-06-19 * Date of arbitration starts: 2009-10-12 * Date of ruling: 2010-01-29 * Date closed: 2010-02-01 * Complaint: User wishes correction of Givenname in his Account {{{ Hi All, I recently attended the assurers training in Amsterdam and realised the data in my passport and driver's license doesn't match the details as known by cacert.org: Passport: Antonius Laurentius Franciscus Huiskens Drivers licens: Antonius L F Huiskens My cacert.org account is linked to I discussed this with Lambert, and after verification of my passport and driver's license, he suggested I file a name dispute at this very alias. So, what can be done about this? thanks in advance, Antoon }}} * Relief: Name correction in CAcert account Before: Arbitrator UlrichSchroeter (A). Respondent: CAcert (R) Claimant: Antonius L F Huiskens (C) Case: a20090619.1 . 2009-10-12 (A) I'd care about case a20090619.1 . 2009-10-12 (A) request for CCA/DRP acceptance . 2009-10-12 (C) accepts CCA/DRP . 2009-10-12 (C) wants the name to be corrected to Antonius L F Huiskens . 2009-10-12 (A) started req. for a VipAssurance for confirmation from at least 2 exp. assurers . assurance to be finished until end of Oct'09 . 2009-10-12 (A) rcvd a critique using VipAssurance as a regular workaround in arbitrations from an assurer {{{ As you already will expect I personally find this a mis-use of the VIP assurance. The question should not be 'am I technically allowed to use the VIP assurance in such a case', but 'is it a wise thing to ask my senior assurers to jump into their cars, find an unknown person, and assure him'. The VIP program should only be used in extremely rare cases, as it requires much extra effort of our senior assurers. When a VIP assurance is ordered in each and any ruling, in very short time nobody wil treat the VIP assurance as 'extra value', only as 'extra burden'. And as 'old' rulings are often used as an example for a current ruling, chances are that other arbitrators will start thinking 'oh, that's the way I am supposed to do', and start ordering VIP assurances also. }}} . 2009-10-23 (A) resend location information of Antoon regarding Assurances . 2009-11-04 (A) requested progress report from (R) and potential assurers . 2009-11-04 (A) answer from one assurers . 2009-11-11 (A) reminder request progress report from (R) . 2009-11-27 (A) req. to Support: list of assurers who assured Antoon and when . 2009-11-28 (A) rcvd answer from support . ||Date ||Assurer || ||mets change requirement || ||2009-02-26 ||Cornelis S ||AS1 || {{attachment:choice-cancel.gif}} || ||2009-02-26 ||Peter G ||AS2 || || ||2009-02-26 ||Michael H ||AS3 || {{attachment:choice-cancel.gif}} || ||2009-02-26 ||Rudi D ||AS4 || {{attachment:choice-cancel.gif}} || ||2009-02-26 ||Joost V ||AS5 || || . 2009-12-08 (A) req. to assurers: AS1, AS2, AS3, AS4, AS5 . 2009-12-08 (AS1): name in CAP doesn't met requirements for name change request. Offers a re-assurance with 3 other assurers . 2009-12-08 (AS4): I will dig it up, but I pretty much am sure that it was Antoon . 2009-12-26 (A): request for a CM as substitute for NB . 2009-12-26 (AlexanderPrinsier): I'll take care about this case as CM . 2009-12-26 (A): request of CAP form scan from AS2, AS3, AS4, AS5 . 2009-12-26 (A): rcvd CAP form scan from AS3 . 2010-01-04 (C): progress report request to (A) . 2010-01-05 (A): answer on progress report request, with order for re-assurance if it doesn't happen since Nov '09 to (C) . 2010-01-05 (C): answer to the progress report of (A) . 2010-01-05 (A): request for contact email adresses of the assurers from Dec 14th assurances to (C), (AS1) . 2010-01-12 (A): reminder request for contact email adresses of the assurers from Dec 14th assurances to (C), (AS1) . 2010-01-12 (C): "I've not heard from Hans either. I'll give him a call." . 2010-01-12 (AS1): "I'm have a little backlog on my mailbox and todo-list. I'll act on this tonight" . 2010-01-13 (A): rcvd CAP form scan from (AS1), also rcvd list of assurers and their email addresses from Dec 14th assurance party ||Assurer || ||mets change req requirements? || ||Cornelis S ||AS1 || {{attachment:choice-yes.gif}} || ||Joost V ||AS5 || {{attachment:choice-yes.gif}} || ||TB ||AS6 || {{attachment:choice-yes.gif}} || ||TS ||AS7 || || . 2010-01-13 (A): sent CAP form scan requests out to (AS5), (AS6), (AS7) . 2010-01-13 (AS6): asks if its ok, to send the CAP form scan within the next 1, 2 days ? . 2010-01-13 (A): to (AS6) its ok. . 2010-01-16 (AS6): sent CAP form scan. Mets name change request. . 2010-01-22 (A): sent out reminder about CAP form scan request to (AS5) and (AS7) . 2010-01-25 (C): progress report requested . 2010-01-25 (A): progress report request answered. We're in the need to receive the CAP form scans from the Dec 14th assurance of (AS5) and (AS7) . 2010-01-27 (AS1): did (AS5) send his CAP form scan yet ? . 2010-01-28 (A): answer to (AS1) + (AS5): no, didn't received a CAP form scan from (AS5) yet . 2010-01-28 (A): rcvd CAP form scan from (AS5) via (AS1) as of scanner problems and also X.509 cert problems in sending signed and encrypted email, this mets the name change request . 2010-01-29 (A): req. to confirm under the [[AssuranceHandbook2#CAcert_Assurer_Reliable_Statement|CARS]] statement from (AS5) about the procedure with forwarding of the CAP form scan thru (AS1) == Discovery == * there was no malfeasance of an type alleged or found * the rules regarding names have been in flux since then claimant became a member * from the general rule 'you can reduce information but never increase information' the removal of middle names in the account name doesn't conflict with other assurances made * this dispute is the result of learning at an ATE * addtl. question that araised in this case: can VipAssurance be used as a workaround to handle arbitration cases? * Information about re-assurances of (C) {{{ I've been reassured by Hans and several others at that occasion (well, it was the 14th of dec). I'll check with Hans to see what happened. Two of them: Theodoor and Tor Assured me from what I can see. I know for sure that Hans also assured me, and I seem to remember a fourth. }}} * the claimant has the experience required of assurers * three Assurers have verified the requested name in the account * these 3 assurances would bring the Account up above 50 points according to AP * The certs problem * The [[http://www.cacert.org/policy/CertificationPracticeStatement.php|CPS]] comes to draft at Status: DRAFT p20091108 * If the user has created client certificates, with the not yet corrected name in the account, the certs are built up with the wrong givenname from account. * [[http://www.cacert.org/policy/CertificationPracticeStatement.php|CPS]] 3.1.1. Types of names - Client Certificates. The Subscriber Naming consists of: * CN= The common name takes its value from one of: * For individual Members, a Name of the Subscriber, as Assured under AP. * The givenname in question isn't AP conform * Using [[Arbitrations/a20090621.2|a20090621.2]] as precedence with minor variations regarding the certs problem that uses [[Arbitrations/a20091129.1|a20091129.1]] as a precedence. == Ruling == * The first name (givenname) in the Respondent's account shall be changed from "Antoon" to "Antonius" * Since there are statements by three independent CAcert members about the correct name, by default all Assurance Points are still valid and no forther change is needed. * But there is still a complicated part in this arbitration: The 5 assurances Antoon received could not be verified against the arbitrator or doesn't meet the change requirements, so therefor I have to rule, that all 5 assurances needs to be revoked. * Two of the assurers who did assure Antoon at the first time, did a re-assurance in the meantime, that was confirmed within this arbitration. So therefor, both assurers can add the given assurance points after the old assurances are revoked. * One additional problem araises, because Antoon is at the 100 assurance points level. revocation of the 5 assurances reduces Antoons points below 50 pts. So therefor I rule, that the revocation and re-add of assurance points have to be in a given order. 1. rename the givenname 2. revoke the old assurances of (AS1) and (AS5), so both can re-add the missing assurance points. 3. in the last step, all other old assurances needs to be revoked and addtl. assurance points can be added by the assurers from the assurance party at Dec 14th. * The Assurers which have assured the account at the very first time and didn't send a confirmation of their assurance needs to be notified that according to PracticeOnNames name variants like Matthias/Matthew do not match. Further they needs to be informed, that their assurances has been revoked. * Client Certificates that has been created by the user after 2009-11-08 and includes the wrong givenname in the cert, must be revoked by the user. * About the addtl. question: "Can VipAssurance be used as a workaround to handle arbitration cases?" I came to the conclusion, that I follow here the argumentation Hans V. made, to use it only in very rare cases, not a default arbitrations instrumentation. * What does this mean? * This case starts mid June 2009. As of the arbitration backlog, the arbitrators were peaked with cases. The first review about this case was made mid Oct 2009, 4 months after the dispute was filed. Communication starts sluggish. CAP forms of previous assurances doesn't met requirements of an assurance (CAP forms incomplete, name was not written as ID documents states, and so on). Some of the assurers was unresponsive. The only option to get this arbitration case fixed is to do a re-assurance, to find 2 experienced assurers who can bring the assuree above 50 points, so at least, a client cert with a name becomes valid. The "experienced" assurers can also be 3 not so yet experienced assurers. With Hans S. assistance, a reassurance did happen. Without the help of Hans S. this case probably didn't find an end. * From the experiences of this case [[VipAssurance|VipAssurances]] aren't an option. Better: find assurers, together with the assuree, to plan a reassurance party. * If an arbitrator uses VipAssurance as instrumentation in an arbitration, this needs a justification, why he uses VipAssurance instead of regular assurances. * Starting with a VipAssurance in this case justification is: the arbitration backlog is no fault of the community members nor this arbitration case related parties. The very long delay, before the case has entered the running state, that was longer then 3 months, and the need of a re-assurance given by the facts of missing informations suggests to start a VipAssurance. * DRP says only: If no Arbitrator accepts the dispute, the case is closed with status "declined." (here DRP only assumes: all arbitrators are waiting for cases, but the backlog case hasn't been forseen) * [[https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html|Case Manager Guidelines / Handbooks]] says: a. If no immediate allocation occurs, the case is referred to the Arbitration Manager, and additional strategies are taken. a. If no Arbitrator accepts after one calendar month, the case is declared "closed." * The "additional strategies" in this case was to leave this case open. Caused by arbitration blockage (that was handled Nov/Dec 2009). First occurance of topic "Arbitration Blockage" was [[Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/20090913|Board Meeting 2009-09-13]] and following meetings. Frankfurt/Main Jan 29th, 2010 == Execution == . 2010-01-29 (A): 0. awaiting confirmation email from (AS5) . 2010-01-29 (A): sent ruling and notification to (C), (CM), support and all assurers . 2010-01-29 (A): rcvd confirmation email from (AS5) . 2010-01-30 (A): sent execute req. "1. rename givenname in account" to support. Further please send actual list of assurances Antoon received . 2009-01-30 (S:) list of assurers sent to (A) and changing the givenname completed in account . 2010-01-30 (A): sent execute req. "2. revoke the old assurances of (AS1) and (AS5), so both can re-add the missing assurance points." - addtl. 2 revocations of 2 old assurances (AS2), (AS3), so they don't decreases the points level of the account below 50 points . 2010-01-30 (S) revocation of 4 assurances completed in account, actually list sent to (A) . 2010-01-30 (A): There is no re-calculation of counting points: actual state: 3 assurances: 20 + 35 + 0 = 55 points, so assurance #3 does needs to be re-done. So the next steps have to be: 1. order to support: revocation of assurance from Tor. 2. order to Tor: re-apply assurance . 2010-01-30 (A): sent notification about temporarely revocation of assurance to (AS6) . 2010-01-30 (A): notification about revocation of assurances sent to (AS2) and (AS3) including advice about name handling . 2010-01-30 (A): notification about revocation of assurances sent to (AS1) and (AS5) including advice about name handling . 2010-01-30 (S): 1 assurance revoked (AS6) . 2010-01-30 (A): sent execution order to (AS6) to re-apply the assurance to Antoons account . 2010-01-31 (AS6): confirms re-applied assurance points transfer . 2010-01-31 (A): request for actual list of assurances Antoon rcvd . 2010-01-31 (A): rcvd actual list of assurances Antoon rcvd from support. Actual state as expected. . 2010-01-31 (A): sent order to (AS1) to add his assurance onto Antoons account . 2010-02-01 (AS1): confirms applied assurance points transfer . 2010-02-01 (A): sent execute req. "5. revoke the old assurance of (AS4)" to support . 2010-02-01 (S): 1 assurance revoked (AS4), actual list sent to (A) . 2010-02-01 (A): notification about revocation of assurances sent to (AS4) including advice about name handling . 2010-02-01 (A): sent order to (AS5) to add his assurance onto Antoons account . 2010-02-01 (AS5): confirms applied assurance points transfer . 2010-02-01 (A): case closed == Similar Cases == ||[[Arbitrations/a20090621.2|a20090621.2]] ||[[Arbitrations/a20090621.2|User not registered under full names]] || ---- . CategoryArbitration . CategoryArbCaseAccountDataNameModificationsRequested