* Case Number: a20091124.1 * Status: Closed * Claimants: Thomas K * Respondents: CAcert * Case Manager: [[Mario Lipinski]] * Arbitrator: UlrichSchroeter * Date of arbitration start: 2011-04-07 * Date of ruling: 2011-04-08 * Case closed: 2011-04-08 * Complaint: Arbitration request: wrong DoB moved to Administrative Delete Account {{{ (undecryptable) }}} * Relief: TBD Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: Thomas K (C), Case: a20091124.1 == History Log == . 2009-11-27 (UlrichSchroeter): added to wiki, request for CM / A . 2010-08-29 (CM): I'll take care about this case . 2010-08-29 (A): I'll take care about this case . 2010-08-30 (A): forwarding all emails to (CM) . 2010-08-30 (A): sending init mailing with CCA / DRP acceptance req to (C) . 2010-09-04 (A): rcvd response from (C), delayed until early October . 2010-10-06 (A): switched from ''hold'' back to ''init'', sending init mailing with CCA / DRP acceptance req to (C) . 2010-11-15 (A): re-request (C)'s CCA / DRP acceptance and further infos about wrong DoB claim with deadline set to Nov 30th, 2010 . 2010-12-04 (A): Intermediate Ruling sent to (C) . 2010-12-04 (A): Intermediate Ruling exec request sent to (Support) with request for an exec report . 2010-12-10 (Support): [s20101204.36] exec report, (C)'s account locked . 2010-12-13 (A): clarification to intermediate ruling, re-request CCA/DRP acceptance, re-request about informations to the dispute filing (all in German language) to (C) . 2011-01-14 (A): reminder sent to (C) . 2011-01-29 (A): 3rd and last reminder with deadline set to Feb, 12th, 2011 to (C) . 2011-02-13 (A): request to (Support) for Assurances rcvd/given on user account of (C) . 2011-02-13 (Support): [s20110213.11] sends list of Assurances rcvd/given by user (C) . 2011-02-13 (A): invitation to [[Events/2011-04-02-ATE-Munich|ATE-Munich]] sent to (C) . 2011-02-15 (DRO): progress report request . 2011-02-15 (A): sent progress report and expectation to close this case within next 2 months to (CM), (DRO) . 2011-02-15 (A): contacting organizers and attendees of OpenSource-Treffen Munich (2009-11-20) to (AS1), (AS2), (AS3) . 2011-02-16 (AS1): (C) is unknown to me. Some hints about contact sources . 2011-02-16 (AS2): (C) is unknown to me. . 2011-03-20 (A): reminder invitation to [[Events/2011-04-02-ATE-Munich|ATE-Munich]] sent to (C) with response request . 2011-04-04 (A): request to event organizer [[Community/HomePagesMembers/FrankBrückner|Frank B]] if (C) was on the attendance list at [[Events/2011-04-02-ATE-Munich|ATE-Munich]] ? as (C) didn't contact (A) at the event as requested . 2011-04-04 (A): receiving mailbox full NDR on [[Community/HomePagesMembers/FrankBrückner|Frank B]] recipient . 2011-04-05 (A): resending request [[Community/HomePagesMembers/FrankBrückner|Frank B]] to another known email . 2011-04-07 (FB): (C)'s name not on the attendent list . 2011-04-07 (A): case moved to Administrative Delete Account case, Intermediate Ruling #2, send to (C) . 2011-04-07 (A): exec order request to (Support) regarding intermediate ruling #2 . 2011-04-08 (Support): [s20110407.100] exec report for intermediate ruling #2 exec order == Intermediate Ruling == CAcert's internal Arbitration forum is about to solve our problems and disputes. CAcert's Arbitration forum will also used to handle administrative correction requests, as we have to handle identity related, so therefor sensitive data. Arbitration work is based on the informations received by the arbitration participients. So therefor Assurers have not only to check Assurees identity against their presented ID docs, also Assurers have to check and verify that the members agrees to be bound to the CACert's own Arbitration forum, and if they'll accept liabilities upto 1000 Euro. If an Assuree doesn't agree to these requirements, the next step is the termination of the agreement. For Arbitration to become workable, users have to follow the CAcert Community Agreement, that also lists obligations. One of these obligation is, to keep his email address in good working order. This means, that on requests from CAcert to the users primary email address, the user responds to requests in an appropiate time frame. What is an appropiate time frame ? With vacation times in mind, an appropiate time frame can be set upto 6 weeks. This is annoying in an Arbitration process, but gives an user enough time for responding. This case started with an undecryptable email dispute filing dated 2009-11-24 with subject "wrong DoB" indicating, that the Assurer running into a problem by a wrong DoB in an assurance. But this is only an assumption, to be made, based on the subject text and no more infos available. End of August, Arbitration picked up the case, to start the Arbitration case. With (C)'s response dated 2010-09-04, to delay a response until early October 2010, the case was set on hold till this date. Restarted 2010-10-06. Since 2010-10-06 now 8 1/2 weeks without further response from (C). Without Assurers assistance, we cannot continue with this case, with the knowledge that something is wrong with a DoB. As not only Assuree's are to be bound to the CCA, all members are to be bound to CCA, I hereby state a CCA violance by (C) not responding on requests by an Arbitrator, based on * CCA 2.3 Obligations . You are obliged . 1. to provide accurate information as part of Assurance. You give permission for verification of the information using CAcert-approved methods. . and * 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. * [[http://www.cacert.org/policy/CAcertCommunityAgreement.php|CAcert Community Agreement]] Based on [[http://www.cacert.org/policy/DisputeResolutionPolicy.php|DRP]] 2.1 Authority I hereby order Support, to lock (C)'s users account until he delivers the informations we need, to continue this Arbitration case, to answer following questions: * Which account (primary email) is involved on the "wrong DoB" * What background infos exists, to state a "wrong DoB" * what happens to the dispute filing with subject "wrong DoB" ? * Assurance made ? * When ? * Where ? * over whom ? * What documents has been presented ? * What has been noted onto the CAP form ? Until we receive further infos, (C)'s account has to be kept locked. Frankfurt/Main, 2010-12-04 == Discovery (Private Part) (optional) == * Link to Arbitration case [[Arbitrations/priv/a20091124.1|a20091124.1 (Private Part)]] <> ==== EOT Private Part ==== == Discovery == * Invitation to [[Events/2011-04-02-ATE-Munich|ATE-Munich 2011-04-02]] (final attendees list) had not been followed by (C) == Intermediate Ruling #2 == (C) didn't respond on any contact requests between 2010-09-04 and 2011-03-20, so willfuly and continously violating CCA 3.5 the case moved from a DoB problem reporting to an Administrative Delete Account case over (C). For preparing the final ruling, I hereby order: 1. that Support should hijack the users account 1. Please make a snapshot printout (to pdf) of the complete users account 1. Report to (A) if certs exists on user account: client certs, server certs, GPG/PGP keys and report their expire date. 1. to keep the locked account state 1. no further actions for the moment Frankfurt/Main, 2011-04-07 == Discovery II == * 2011-04-08 (Support): [s20110407.100] * 0 server certificates * 0 domains * 0 gpg/pgp certifictaes * 4 client certs, latest expires: 2011-11-22 == Ruling == === Deliberations === The dispute filing, that has initiated by (C) as a DoB problem moved into a CCA violation case of (C). CCA 3.5 violation: 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. Several attempts have been made, to get a reply from the user, that the user didn't followed. The last attempt was an invitation to the ATE-Munich 2011. Claimant didn't followed the invitation. So therefor I confirm the intermediate ruling dated 2010-12-04 to be correct to lock the users account. By continously, willfuly CCA 3.5 violation the user forfeits his membership, by not agreeing and not following the CAcert Community Agreement. So therefor I hereby order the administrative Delete Account request over Claimant. As this Delete Account request is of the state ''Is Assurer'' and the tasks to protect the WoT cannot be handled in an appropiate way, the default Delete Account procedure should be modified: Steps 1-3 handled with intermediate ruling #2 1. I hereby order, that Support should hijack the users account 1. Please make a snapshot printout (to pdf) of the complete users account 1. Report to (A) if certs exists on user account: client certs, server certs, GPG/PGP keys === Order to Claimant === 1. to contact (A) by email with request for address, to send-in 9 CAP forms from assurances given === Order to Support === 1. to re-hijack users account for execute the next steps 1. to add the arbitration number as primary email address, but to keep the current users primary email address as secondary email address, so user cannot create another account. 1. to revoke all client certs 1. to reset flags: a. Is Assurer - to prevent adding further Assurances a. Code Signing a. all announcements flags - to block mailings to user a. fill the lost password details with junk - to prevent recovery of account a. my listing - to clear the Assurers listing 1. entries not to modify a. email addresses (except adding the arbitration case number mask email address as primary address) a. domains listed a. flags not listed before === CCA Termination date === CCA termination date to set, calculated by following the procedure [[Arbitrations/Training/Lesson20#CCATermCalc|CCA Termination Calculation]] a. latest expire date of certs + 3 months, date discovered: 2011-11-22 a. Is-Assurer - last Assurance date + 7 years, date discovered: 2009-12-11 . Calculated CCA termination date set fixed to: 2016-12-10 === Orders in advance === ==== Claimant sends-in CAP forms ==== If the user sends in the requested CAP forms, the anonymize users data and the default delete account procedure can be followed. So therefor, if this requirement is fullfilled before the CCA termination date is reached, I order in advance Support to execute the [[Arbitrations/Training/Lesson20/DeleteAccountProcSEv2|Delete my Account for SE's procedure v2]] started with a post arbitration note by the Arbitrator of this case to support. This does not change the fixed CCA termination date set to: 2016-12-10 In the event Claimant sends in the requested 9 CAP forms, I order Arbitrator by following the deliberations of Arbitration cases [[Arbitrations/a20080702.1|a20080702.1]], [[Arbitrations/a20090618.3|a20090618.3]] and [[Arbitrations/a20090328.1|a20090328.1]] After the CAP forms have arrived, the account of the claimant shall be anonymised by following the Delete Account procedure by a SE 1. The arbitrator shall print this case-file to paper 1. The arbitrator shall put the print-out of this case-file, the print-out of the account status as well as the CAP forms into an opaque envelope and seal that envelope. 1. The arbitrator shall designate that envelope with the arbitration number and retain this envelope for 7 years, after which time it shall be destroyed. 1. The sealed envelope may be opened only * if one of the included CAP forms is requested during an Arbitration, or * if a dispute is filed against the Claimant and an Arbitrator rules that the Claimant's personal data is needed. 1. If the envelope is opened the ruling Arbitrator or the archiving Arbitrator shall send a mail to the Claimant's archived primary email adress about the circumstances. No further efforts will be made if this email adress is unreachable for any reasons. 1. The opening of the sealed envelope does not by default prolong the retention period. 1. An Arbitrator may rule that specific CAP forms shall be removed from the envelope and be archived otherwise (usually with another case, maybe for longer period). 1. The retention period is 7 years from the date of the ruling since the Claimant's personal data have to be archived for this period (see also Paragraph 5.5 of the CPS DRAFT p20091108). It is not sensible to open the envelope every time one of the CAP forms reaches the end of its individual retention period. 1. The envelope may be forwarded to another Arbitrator if the archiving Arbitrator resigns from CAcert or is not able to keep it save any longer. Of course the retention period is not modified by such a forwarding. ==== CCA termination date expires ==== If the CCA termination date expires, claimant can request the Delete my Account with anonymizing users data following the [[Arbitrations/Training/Lesson20/DeleteAccountProcSEv2|Delete-Account-Procedure-for-SE's-v2]] to Support, I hereby order Support in advance to execute the [[Arbitrations/Training/Lesson20/DeleteAccountProcSEv2|Delete my Account for SE's procedure v2]] w/o further passing this case thru arbitration, by reference to this Arbitration case #. Frankfurt/Main, 2011-04-08 == Execution == * 2011-04-08 (A): sending ruling to (C), (CM) * 2011-04-08 (A): exec request to (Support) to execute the ruling over (C)'s account * 2011-04-08 (Support): [s20110408.2] Ruling Exec Report * 2011-04-08 (A): sending exec report to (C), (CM), including postal address to send in the requested CAP forms. Case closed. == Similiar 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 || || [[Arbitrations/a20090701.1|a20090701.1]] || Wrong DoB || || [[Arbitrations/a20100317.1|a20100317.1]] || [[Arbitrations/a20100317.1|DoB correction request by the user, rcvd Assurance Points]] || || [[Arbitrations/a20080702.1|a20080702.1]] || [[Arbitrations/a20080702.1|User requests to delete account with Assurance Points]] || || [[Arbitrations/a20090618.3|a20090618.3]] || [[Arbitrations/a20090618.3|Assurer requests to delete account]] || || [[Arbitrations/a20090618.5|a20090618.5]] || [[Arbitrations/a20090618.5|User requests to delete account with no Assurance Points]] || || [[Arbitrations/a20090826.1|a20090826.1]] || [[Arbitrations/a20090826.1|User wants account deleted, no Assurance Points, no certificates]] || || [[Arbitrations/a20090926.1|a20090926.1]] || [[Arbitrations/a20090926.1|User wants account deleted, no Assurance Points, no certificates]] || ||[[Arbitrations/a20110120.2|a20110120.2]] ||[[Arbitrations/a20110120.2|Account Removal w/ intermediate ruling]] || ||[[Arbitrations/a20110110.1|a20110110.1]] ||[[Arbitrations/a20110110.1|Please Delete my Account (Is Assurer)]] || ||[[Arbitrations/a20110131.1|a20110131.1]] ||[[Arbitrations/a20110131.1|Account Removal Olivier F (Is Assurer)]] || see also: [[Arbitrations/Training/Lesson20|Arbitrations Training Lesson 20 - Arbitration Case - Delete Account Request]] ---- . CategoryArbitration . CategoryArbCaseAccountDelAssurer . [[CategoryArbCaseCCAViolation]]