= Arbitration / Training = The Training Course for Case Managers and Arbitrators [[Arbitrations/Training|Training Home]] / [[Arbitrations/Training/Lesson19|back]] == Lesson 20 - Arbitration Case - Delete Account Request == Normal delete account requests are generally treated by Support. The only regular exception are cases where an assurer already has agreed to hand over the CAP forms when leaving CAcert. This is, because the Assurance Policy only allowes CAP forms to be seen by the assurer, the assuree, or an Arbitrator or a person authorised by Arbitration. Such an authorisation cannot be given in general without checking each case and knowing which person this would be. There may be other reasons why a case is handed over to Arbitraiton by Support. For example when there the member who wants to leave has additional roles that have to be treated (revoke of access rights), or is involved in an arbitration case. == Basic Checklist for Arbitrators == When an unusual delete account case On Delete my Account request, the following points may be relevant: || '''Topic''' || '''Sensible Action''' || || Wants to hand over CAP forms? || organise handover || || Open/running disputes? || hold termination process until other cases are closed || || Is Organisation Admin? || consult with OrganisationAssuranceOfficer || || Is Organisation Assurer? || consult with OrganisationAssuranceOfficer || || Is TTP Assurer? || transfer TTP paperwork to CAcert || || Other roles? || check with team leads / board about pending issues and access rights || || CCA Termination When? || define CCA termination date || == In Detail == === References === ==== Relevant cases ==== There is a long history of how delete accounts were handled. Even as most of them are not active anymore, they may contain helpful information. The most relevant ones for Arbitration are: * [[Arbitrations/a20090618.3|a20090618.3]] gives some clarifications about data retention * [[Arbitrations/a20110110.1|a20110110.1]] description of how to collect CAP forms (some of this parts probably have to be updated because of the new processes * [[Arbitrations/a20111128.3|a20111128.3]] basic and first real precedents case (was replaced later, because of CCA change but is referenced in new precedents, also deletion list ist maintained here) * [[Arbitrations/a20140713.1|a20140713.1]] former precedents case for assurer accounts with only assurances of 7 years old * [[Arbitrations/a20141231.1|a20141231.1]] basis case for current precedents case * [[Arbitrations/a20141024.1|a20141024.1]] '''current precedens case for delete accounts''' ==== Policies ==== The following policies are relevant in the context of delte account caeses: * CAcert Community Agreement (CCA) - allows for termination, since changes in 2014 allows for termination with a process defined by an Arbitration without the direct involvement of an Arbitrator . https://www.cacert.org/policy/CAcertCommunityAgreement.html - 3.3 Termination * Assurance Policy (AP) - handing over CAP forms requires an Arbitrator . https://www.cacert.org/policy/AssurancePolicy.html - 7. Privacy * Certification Practice Statement (CPS) - about certificate handling and their termination . https://www.cacert.org/policy/CertificationPracticeStatement.html - 4., especially 4.9. Certificate revocation and suspension ==== Wiki Links ==== * [[https://wiki.cacert.org/FAQ/HowToTerminate]] (reference from new CCA) . description for members how termination affects WoT * [[Arbitraitons/Training/Lession20|old version]] of the delete account lesson === Actions for a Support Engineer === The required actions of the process defined in current process 1. The support case has to be marked as a delete-account request. 2. The Support-Engineer checks the users account for * certificates that are valid * certificates that are not expired/revoked for 3 months * assurances given within last 7 years * assurances given over 7 years ago 3. The Support-Engineer writes a mail to the user to explain the process and to make sure that the request to get the account delete request is genuine. The mail should contain the following elements (based on the results of Step 2) in a sensible order: [ see below ] 4. Wait until either the user confirms the deletion request or the deadline expires 5. If the user was an assurer and did not confirm the point about the CAP forms * step 3 and 4 should be repeated 2 more times by the Support-Engineer * not all points from step 3 have to be repeated explicitely in the new mails, if it can be assumed that the member is informed about them [for example by a quote] * in the last repetition the request for confirmation should be re-worded so that getting no answer can be interpreted as a confirmation 6. If the user is an assurer and has decided to hand over the CAP forms, the case has to be moved to Arbitration - the automatic Support activity ends in this case 7. The Support-Engineer revokes any valid certificates 8. If the user has agreed or requested to an account block the Support-Engineer should block the account 9. Wait until all certificates are revoked or expired for at least 3 month 10. Document the deletion of the account as described below as "Documentation" 11. Close the account as described below at "Account closure" 12. immediately inform the user about the successful account closure, stating the date of the closure of the account as the CCA termination date for the user. General: * If the user decides to keep the account the process should be stopped. * If the user changes the mind about the blocking of the account before the account is finally deleted, the Support-Engineer has to set or reset the block accordingly. In the context of the process defined here, an account may only be blocked with the explicit agreement of the affected user. This does not affect account blocks that are done for other reasons. If a sensible way would be found so that it could be easily checked if the user who requests termination of the account is involved in an arbitration case, so that the membership should not be ended before the case is finished according, this should be checked as step 0. In the case that the Support-Engineer knows that the user is involed in such an Arbitration case the Arbitrator or (i)CM of that case should be addressed before the process of closing the account is continued, if no Arbitrator or CM could be identified or responds, the DRO should be addressed instead. The user should be informed about this. One possible way to proceed would be to allow the closure of the account without terminating the membership. Currently there is no way for Support-Engineer to know for sure that a user is not involved in an arbitration case, so this check cannot be done in a clearly defined manner. ==== Contents of the Mail ==== * information when delete request was received * request to respond if the deletion of the account is not the wish of the user, with the information that else the account will be closed * optional: option to confirm delete request to fasten the process * deadline of about 2-3 weeks for the response * short explanation of the delete process * information that some risks, liabilities and obligations for the time of the membership, may continue even when the membership has ended * optional: information of alternative activities for common issues like lost passwords * optional: proposal to block the account * if this is added the wording has to be clear that it is optional and no requirement for the closure of the account * if valid certificates were found: * information that they will be revoked after the deadline has passed, if the user does not intervene * if certificates were found that are not expired/revoked for 3 months: * information that account has to be kept open until 3 months after the last certificate has expired/was revoked * date when this will presumably be the case * if any given assurances were found: * reminder that CAP forms have to be kept safely for 7 years after the assurance and that they have to be safely destroyed, afterwards * request to confirm that this has be done and/or will be done for remaining CAP forms * if given assurances within the last 7 years were found: * information that if the assurances given by the assurer are questioned (for whatever reason) they have to be revoked, if CAcert cannot reach the CAP forms * favoured option by CAcert that the user hands over the CAP forms to another assurer defined by an Arbitrator * information that the user may name such an assurer * information that if CAP forms have to change hands, the case will have to be handled by Arbitration * statement that the user may change any of the above decision until the account is deleted ==== Documentation ==== Document the delete account issue by adding it to the [[Arbitrations/Audit/a20111128.3|table]] at the end of the Audit Section linked into the precedent case a20111128.3 with: * Support ticket number * Arbitration number + consecutive number => a20111128.3.# * CCA termination date (this is the SE's execution date) * "A" if the user is an assurer with all given assurances older than 7 years * "AC" if the user is an assurer with given assurances that are not 7 years old and were the case was not handled by Arbitration * The table should explain the usage of "A" and "AC". ==== If an account is to be killed ... ==== <> Previous working versions ('''depreciated''') * [[Arbitrations/Training/Lesson20/DeleteAccountProcSEv1]] (depreciated) * [[Arbitrations/Training/Lesson20/DeleteAccountProcSEv2a]] (depreciated) * [[Arbitrations/Training/Lesson20/DeleteAccountProcSEv2]] (depreciated) * [[Arbitrations/Training/Lesson20/DeleteAccountProcSEv3]] referenced in current precedents ruling, however done automised via support console since Patch #749 ==== Hijacking accounts ==== Sometimes, in very special cases - not in the regular process - it is necessary to hijack an account. Hijacking accounts is a workaround to get informations in special cases. It indeed is a dirty workaround, so the support engineer needs explicit authorisation to do so by an Arbitrator, and an Arbitrator should only give this authorisation if the account is due to deletion or deactivation anyway. See https://wiki.cacert.org/Support/SE/Manual#About_Deleting_and_Deactivating_Accounts on how to hijack an account. <> === Calculating of CCA termination date === * Calculate CCA termination date (referenced to [[https://wiki.cacert.org/Arbitrations/Meetings/Transcripts/transcript-meeting-100104|Arbitration team meeting 2010-01-04]] 22:09:05) * practical view: on account close request, SE walks through the list of Certs, searches the Cert with the longest expiry time, returns this info to arbitrator, arbitrator notice this, SE revokes certs, CCA ends after the date + 3 month Arbitrator noticed * .... (or ruling if this is later) * Sample: today = 2010-10-21 is the date the last cert expires * day: 21 - 1 = 20 => calculated CCA termination day: 20 * month: 10 + 3 => calculated CCA termination month: January * calculated CCA termination date: 2011-01-20 * if the decision (e.g. ruling) date is after the calculated termination date, the actual termination date will be the decision date, else the calculated ruling date ---- [[Arbitrations/Training/Lesson21|next]] ---- . CategoryArbitration . CategoryArbitrationsTraining