* Case Number: a20091124.2 * Status: closed * Claimants: Philippe T., Dominik G., Johannes W. * Respondents: CAcert * Case Manager: MartinGummi * Arbitrator: UlrichSchroeter * Date of arbitration start: 2010-02-07 * Date of ruling: 2010-03-16 * Case closed: 2010-06-17 * Complaint: Witvliet - User has shortened form of name in account (II) + (III), Removal of surplus account (cleanup) {{{ I'm claiming that on Johannes Witvliet's second account () his name is Hans but his identification states Johannes. }}} * Relief: TBD Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: Philippe Teuwen (C1), Dominik George (C2) Johannes Witvliet (C3), Case: a20091124.2 == History Log == . 2009-11-27 (UlrichSchroeter): added to wiki, request for CM / A . 2010-02-06 (issue.c.o) case [s20100206.79] . 2010-02-07 (UlrichSchroeter): added 2nd (C2) to this case to wiki, request for CM / A . 2010-02-07 (CM): I'll take care about this case . 2010-02-07 (A): I'll take care about this case . 2010-02-07 (A): intermediate ruling at Fosdem within the interview . 2010-02-08 (A): forward of original dispute filing (Nov 2009) to (CM) and (A) . 2010-02-08 (CM): sent init mail to (C3) . 2010-02-13 (A): cleanup on (C3) and (R), moved former (R) to (C3) . 2010-02-13 (issue.c.o) case [s20100213.68] . 2010-02-13 (A): added delete (cleanup) account request to this case, caused as a result from interview with (C3) at 2010-02-07 (see intermediate ruling) . 2010-02-13 (A): rcvd PoV from (C3) . 2010-02-13 (C3): accepts CCA / DRP under this arbitration, name change req. for account #1 + #2 . 2010-02-28 (A): req to support for (1) name in account, (2) assurances rcvd, (3) assurances given with all 5 accounts of the user (C3) . 2010-02-28 (A): update request to (C3) about the current state of move operations (email addr E is in conflict) . 2010-02-28 (A): rcvd info from (C3) about his email account moves to account #1, with request to delete accounts #3, #4, #5 (see Discovery steps 2 + 3). Account #1 and #2 should be leaved active . 2010-02-28 (A): updated to support for (1) name in account, (2) assurances rcvd, (3) assurances given with all 5 accounts with updated email addresses of the user (C3) (see discovery step 3) . 2010-03-01 (A): rcvd overview over accounts and email addresses of (C3) from support (see request from 2010-02-28) . 2010-03-10 (A): req. to confirm givenname in ID doc of (C3) from Assurer (A1), (A2), (A3), (A4), (A5), (A6), (A7) of Account #1 || A1 || Raimond K || {+} || || A2 || Bart-Jan V || {+} || || A3 || Marcel N || || || A4 || Teus H || {+} || || A5 || Wytze R || {+} || || A6 || Marc F || {+} || || A7 || Raoul B || {+} || . 2010-03-10 (A): req. to confirm givenname in ID doc of (C3) from Assurer (A8), (A9), (A10) of Account #2 || A8 || Johan S || || || A9 || Winfried T || {+} || || A10 || Marco C || {+} || * 2010-03-10 (A): asking (C3) about Client certs with his account #1 and #2 beginning Nov 8th, 2009 (CPS to Draft) * 2010-03-10 (A5): confirms givenname in ID doc is Johannes * 2010-03-10 (A10): confirms givenname in ID doc is Johannes * 2010-03-10 (C3): confirms that he has not issued any client cert after Nov 8th 2009 (CPS to Draft) on Account #1 * 2010-03-10 (C3): confirms that he has not issued any client cert after Nov 8th 2009 (CPS to Draft) on Account #2 * 2010-03-10 (A4): confirms givenname in ID doc is ... Johannes (given name; in short Hans (normal and common abbreviation in NL)) * 2010-03-10 (A6): will be back next week ... CAP scan delayed * 2010-03-10 (A1): confirms givenname in ID doc is Johannes * 2010-03-10 (A9): confirms givenname in ID doc is Johannes * 2010-03-11 (A): question about givenname prefered variant to (C3) (question relates to [[Arbitrations/a20090618.12|a20090618.12]] ruling) * 2010-03-11 (C3): Considering the fact that not everybody might read/understand the impact of case a20091124.2, and to avoid deviating from common pratice, i would considder it more appropiately the use only the name printed in the official documents, thus i choose "Johannes" as givenname * 2010-03-12 (A7): confirms givenname in ID doc is Johannes * 2010-03-13 (A): req from (C3) a reliable statement thus he understand that he cannot use both accounts in assuring others and that he cannot use account #1 to assure account #2 * 2010-03-16 (A): reminder about last req. to (C3) sent * 2010-03-16 (A6): confirms givenname in ID doc is Johannes * 2010-03-16 (C3): confirms again with a CARS statement: that he understand and agree with the obvious rules that . -one is not allowed to perform self assurances, . -one is not allowed to use both accounts to assure another Assuree. * 2010-03-16 (A): answering * 2010-03-17 (AA): confirms givenname in ID doc is Johannes == Discovery == * 2010-02-07 (A): Interview face-2-face at Fosdem with (C3): User states to have 5 accounts * there was no malfeasance of any type alleged or found * The problems results from not understanding how multiple email addresses can be added to one account and how to create seperate client certs for those email addresses * (C3) requests to reduce 5 accounts to 2 * (C3) understands the problem, to not assure one account with the other by assuring themself (statement made at the interview dated 2010-02-07) * 2010-02-28 case [[Arbitrations/a20090618.12|a20090618.12]] ruling can probably take precedense, not yet published as of 2010-03-10 * The certs problem on Name changes * 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. * (C3) states as of March 10th 2010: "NO client certificates have been issued **after** the 8th November 2009" with account #1 and account #2 * Question from (C3) within mail, dated 2010-03-16 {{{ ... please explain WHY you need this written statement, as it should be obvious enough for anybody participating with cacert and passing the assurance-exam.. If this appears not obvious enough to all, i would like to suggest an amendment to both with wiki and the exam. }}} * Answer (A) to (C3), dated 2010-03-16 {{{ one can assume, you may not understand how to use multiple email addresses in one account, and so therefor you also didn't understand the multiple accounts problem. As thus upcoming ruling becomes a precedense case, that one is allowed to use multiple accounts under AP regulations that relates to the understanding of this special circumstance, that its theoretical possible to use one account to enter assurance points onto the 2nd account, thus needs a record in the logs, that the user has been asked about his understanding. As I've asked you this question within the interview, but there is no recording, nor a signed statement from you, therefor I've redone this thru this re-request. As your statement becomes part of the ruling, its a strong signal to the community, that you're within the bounds of the AP regulations. One 'project' I'm working on currently, is the 'Conflicts of Interests' (CoI) thing, that relates to board members, and is also part in the ABC's (Arbitrated Background Checks) To identify CoI's is difficult. So what one can do is to bring someone to a clear statement. Further on, if something goes wrong, the Arbitrator can compare the situation with the given statement and can identify that someone lies or not. The multiple accounts thing is a 'hot' topic to the community and also the arbitration system. So here I as the Arbitrator has to sort out, all the facts. With your written statement, thus protects yourself from further wrong accusations and thus protects the community that here is one community member who acts within the given policy boundarys. So therefor, with this written statement its the same like the written statement, that you are bound by the CCA and therefor you're bound to the Arbitration system and accepts the Liabilitys that are defined by the CCA. The Arbitration system is not merely installed to punish community members. The Arbitration system is installed to have an open forum with a mediation to solve disputes and also handle system and support tasks under a 4-eyes principle view. As written in all our init mailings in an arbitration case, so we ask all the participients in a case to maintain a positive and helpful spirit at all times! So thus includes also discussing things, to find the right answer in a case. Its an open forum, where each participiant can ask questions, to get answers. So here again, if you have any further questions, don't hesitate to ask the questions }}} ==== Accounts cleanup ==== * '''Step 1''' || # || Prim Email || Sec Email || request rcvd || proposed next change || || 1. || A || || name change request || || || 2. || B || || name change request (?!?) || || || 3. || C || || name correction solved || should be moved next || || 4. || D || || || should be moved next || || 5. || TempF || E || delete accnt req || || * '''Step 2''' || # || Prim Email || Sec Email || request rcvd || proposed next change || || 1. || A || || name change request || || || 2. || B || || name change request (?!?) || || || 3. || TempG || C || name correction solved || should be moved next || || 4. || TempH || D || || should be moved next || || 5. || TempF || E || delete accnt req || || * '''Step 3''' || # || Prim Email || Sec Email || request rcvd || proposed next change || || 1. || A || C, D, E || name change request || || || 2. || B || || name change request (?!?) || || || 3. || TempG || || delete accnt req || name correction solved || || 4. || TempH || || delete accnt req || || || 5. || TempF || || delete accnt req || || == Intermediate Ruling == * 2010-02-07 (A): as result from the interview, the 1st step is to merge 4 of 5 accounts to one active account by adding temporarely email addresses onto the accounts to be cleaned, switch the primary email address, remove that email address and add it to the active account. Please return with a cleanup of no longer used accounts request == Ruling == * I hereby follow the request of the Claimants for changing the Givenname in his account. At least 2 Assurers states for each of the both remaining accounts, that they have read the users requested Givenname in his ID documents. * The Account cleanups after the intermediate ruling did happen. * Email addresses were moved to a primary account. However, the Claimant wishes, to continue with 2 accounts because he has issued certs with his 2nd account. * The cleaned up accounts are no account removal request as per CCA 3.3 Termination. The user is still a continuing member of the community. All email addresses are still available, and the user is keeping his email accounts in good working order and is able to receive emails from CAcert. * With the three, by the account cleanup affected accounts, were was no Assurances made and therefor no Assurance points were issued. No special CAP form handling procedure needs to be ruled. * The user stated that he has no client certificates issued after CPS comes to DRAFT. So no special certs handling procedure for CPS appliance needs to be ruled on user accounts #1 and #2 relating the Name change request. * The assurances that were made over account #3 and #4 are still valid and can be moved to account #1 the way as the email addresses were moved to account #1 by revoking those assurances on account #3 and account #4. However, assurances made to one of those accounts related to another primary email address than the current one on account #1. After merging the email addresses to one account, only one Assurance made over the user was made twice that is prevented by the system. But all the other assurances can be moved to the primary account by setting the primary email address temporary to the email address from account #3 and account #4 by re-applying the assurance points from the assurers except the assurance that is given twice. * The users wish to continue with 2 accounts, is a potential problem within Account handling as it allows theoreticly assurances from one account over the 2nd account. Thus is not AP conform. However the user stated in the interview that he is aware of this problem and he takes care about this problem. This was also stated again with a CARS statement in the emailing dated 2010-03-16. The user got an advice about this issue, and therefor nothing prevents him to continue with the second account as long he follows AP rules. So therefor I hereby rule, that the user can still continue using the second account. * The execution steps needs to be done in the following order: 1. change the Givenname in account #1 and #2 2. revoke assurances on account #3 and #4 3. re-apply assurances from account #3 and #4 to account #1 4. delete the cleaned up accounts #3 - #5 Frankfurt/Main, 2010-03-16 == Execution == . 2010-03-16 (A): ruling notification sent to participients . 2010-03-16 (A): Support: please modify the Givenname in both user accounts #1 and #2 of (C3). Please provide me with the exec report. . 2010-03-16 (Support): Givenname on both accounts corrected. . 2010-03-16 (A): to (C3): please set primary email address on account #1 to email address from account #3. Please provide Support with the info, once the primary email address is set . 2010-03-16 (A): to Support: please revoke assurances on account #3, inform Assurers for re-applying assurances after (C3) has changed primary email address on account #1 || || '''Assurance''' || '''revoked''' || '''re-applied''' || || A11 || Cedric M || {-} || || || A12 || Michael C || {-} || || || A13 || Marc L || {-} || || || A14 || Phil T || {-} || {+} || || A15 || Ulrich S || {-} || {+} || . 2010-03-16 (A): to (C2): please enter your assurance over (C3) into the system. Please provide me with an exec report. . 2010-03-16 (C3): question regarding making the email address in question primary in account #1 . 2010-03-16 (A): answer to (C3) with detailed execution steps to make the email address in question to the primary email address in account #1 . 2010-03-17 (C3): primary email address in question on account #1 is set . 2010-03-17 (A): info to Support that (C3) has switch the primary email address, so Support can continue with the exec request dated 2010-03-16 . 2010-03-17 (Support): revoked assurances on account #3 . 2010-03-17 (Support): sent out notifications to assurers affected by assurance revocation on account #3 with deadline for reapply assurance until March 24th 2010 . 2010-03-17 (Support): forwared msg assurance reapplyed by Ulrich S (A15) . 2010-03-17 (Support): forwared msg assurance reapplyed by Phil T (A14) . 2010-03-22 (A): sent reminder for re-applying assurances to (A11), (A12), (A13) . 2010-03-26 (A): info: 2 of 5 assurances re-applyed, deadline passed. continue with next exec step. . 2010-03-26 (A): to (C3): please set primary email address on account #1 to email address from account #4. Please provide me with the info, once the primary email address is set . 2010-03-26 (A): sent infos to (A11), (A12), (A13) how and when they can contact (C3) individualy, to re-apply the assurances . 2010-03-26 (C3): switched primary email address to former primary email of account #4 . 2010-03-26 (A): Support, please revoke assurances on account #4 temporarely so the assurers can re-apply the assurances on account #1 || || '''Assurance''' || '''revoked''' || '''re-applied''' || || A16 || Teus H || {-} || {-} || || A17 || Bruno C || {-} || || || A18 || Jan K || {-} || || || A19 || Antony W || {-} || || . 2010-03-26 (Support): The four assurances mentioned .. are revoked as requested. . 2010-03-26 (A): info to (A16) sent regarding revocation of assurance. Assurer already assured (C3) on the primary account . 2010-03-26 (A): Exec req. info to (A17), (A18), (A19) to re-apply assurance over email address from former account #4 of (C3) with deadline Tuesday, Apr 6th, 2010 . 2010-06-14 (A): Exec req. to Support to delete accounts #3, #4 and #5 (cleanup) . 2010-06-14 (A): Exec req. to (C3) to set the primary Email address of choice on account #1 . 2010-06-14 (A): Notification to (C2), that he can apply his assurance over (C3) into the system . 2010-06-16 (Support): Exec report that Accounts #3, #4, #5 has been deleted, outstanding certs has been revoked . 2010-06-16 (A): req to (C3) to set the primary email address on account #1 to the primary email address that is used in (C1)'s assurance and also to (C1) to finish the assurance over (C3) by transfering the assurance points to Hans account. Please report the exec steps . 2010-06-16 (C3): has set primary email on account #1 as requested . 2010-06-16 (C1): has transfered assurance points onto account #1 of (C3) . 2010-06-17 (A): all exec steps now finished. case closed. == Similiar Cases == || [[Arbitrations/a20071023.1|a20071023.1]] || Nickname used in account || || [[Arbitrations/a20071205.1|a20071205.1]] || Spelling difference in name || || [[Arbitrations/a20080604.1|a20080604.1]] || Shortened first name in account || || [[Arbitrations/a20090618.6|a20090618.6]] || Quite complicated noble name does not match account || || [[Arbitrations/a20090618.2|a20090618.2]] || User has shortened form of name in account || || [[Arbitrations/a20090618.12|a20090618.12]] || [[Arbitrations/a20090618.12|User not registered under full name]] (Dutch Givennames) || || [[Arbitrations/a20091129.1|a20091129.1]] || [[Arbitrations/a20091129.1|Adding my second first name]] (CPS) || ---- . CategoryArbitration . CategoryArbCaseAccountDataNameModificationsRequested . CategoryArbCaseOthers