• Arbitrations
• a20101016.1

• Case Number: a20101016.1
• Status: closed

• Claimants: DominikGeorge

• Respondents: CAcert

• Initial Case Manager: UlrichSchroeter

• Case Manager: AlexanderPrinsier

• Arbitrator: UlrichSchroeter

• Date of arbitration start: 2010-10-16
• Date of ruling: 2010-10-16
• Case closed: 2010-10-16
• Complaint: Remove assurance
• Relief: TBD

Before: Arbitrator name arbitor (A), Respondent: CAcert (R), Claimant: DominikGeorge (C), Case: a20101016.1

History Log

• 2010-10-16 (issue.c.o) case [s20101016.28]
• 2010-10-16 (iCM): added to wiki, request for CM / A
• 2010-10-16 (C): accepts CCA / DRP under this arbitration
• 2010-10-16 (A): forwarding of all OTRS ticket notes + irc#se chat between SE Joost and (A) to (CM)
• 2010-10-16 (C): asks, can handle support this case by precedents case a20100210.2?
• 2010-10-16 (C): states, assurance take place close before dispute filing

Discovery

• There was a pre-communication about this case with dismissed for the moment and forth/back between Support and Arbitration channels regarding using a20100210.2 for this case

• SE has no option within Support console to identify Assurance-when date/time

• Dispute filing has been sent 2010-10-16 14:10, SE action is authorized by a20100210.2 by precedent, SE cannot identify the exact entering date/time of the assurance into the system and requests support by arbitration for further clarification to a20100210.2

• (C) states that assurance did happen close before dispute filing

Ruling

• The original precedents case ruling a20100210.2 includes two sections regarding "revoke an assurance"

Part I

• I hereby order, that Support can act on DoB errors and naming mismatches by request from an user as authorized by SP 8.1 under the following conditions by revoking assurances, so the user account gets 0 assurance points and the user can correct the error himself.
• SE has to check the user account:
  • the request for revoking an assurance has to meet the following conditions:
    1. 1. assurance points in total less than 50 assurance points (3 x 15 points or 35+10+4 points, less than 50) not more than 49 assurance points, otherwise the user enters the level of 50 assurance points with the option to create client certificates with name in it, so an addtl. check needs to be done. this cannot be handled thru SE right now w/o further patching the system)

          => or

       2. no certs created by the user (must be verifiable by the SE thru admin console w/o hijacking the account)
    2. assurance points are added as a result from the last assurance event / big event
       1. Events within 3 d or 7 d after an event
          1. big events (GT 1 day events, including weekend days) i.e. CeBIT, Fosdem, Froscon, Linuxtag. delays in trying to transfer points is upto 1 week (7 days), so errors probably cannot be seen and so therefor identified before the 6th or 7th day.

             • short time frame => less then 7 days (including), within 7 x 24 hours after an event = 168 hours

          2. small events (1 day events) upto a 72 hours delay (from experiences with events from one year)

             • short time frame => less then 3 days (including), within 3 x 24 hours after an event = 72 hours

          => or

       2. 24 hours rule
          • the assurance has been added within 24 hours while the request was received

          • current system state as per Feb 11th 2010 doesn't display assurance-when field from the database to SE, so this may be available someday

    3. all false assurances have to be from the same event (location info of assurance) and must meet the assurance in question. No older assurances from individual or other assurance events are accepted.
    4. no assurances done by the user
    5. (if a+b+c+d doesn't apply) otherwise the case must be transfered to arbitration
    6. procedure for support:
       • if single false assurance: proceed
       • if multiple assurances: contact assurers and ask, wait 2 days for reply
         • all agree: proceed
         • NOT(all agree): send to arbitration
  • SE has no permission to change data on his own
  • SE needs a confirmation by email from (C) to revoke the assurance

Part II

If an Assurer request for removal of an assurance, because he has made a mistake, this assurance can be revoked from SE by request from the assurer within 24 hours after assurance is added to an account.

• SE has to follow these rules:
  1. send notification to Assuree that the assurance has been revoked by Assurers request by an email
  2. inform Assurer that the assurance has been revoked by an email

• Clarifications to ruling on Precedents case a20100210.2
• Part I lists several requirements on when a request can be handled by support.
• Part II is the default 24 hours rule, suggested by Alejandro into SM, and authorized by Arbitration precedents case a20100210.2

  • there is a definition under Security Manual (Support) 8.2.1. Support Engineers to revoke an assurance, so the user can correct an error

    • revoke an assurance
      • on request of the Assurer, suggested by Alejandro, now filed as dispute. either Assurer + Support, in a short time frame
• Part II has no restriction when an event did happen. It relates onto the action by an Assurer, when he enters the Assurance into the online system.
  • eg. entering assurances into the system after a big event like Cebit, the user didn't created his account. After 3 months, the user created his account. Assurer enters the assurance into the system, and becomes aware about the missing date field at the moment he enters the send button, so he can request the revocation of the assurance within 24 hours, 3 months after the face-2-face meeting did happen, but within the 24 hours timeslot the Assurer has to send the "revoke my assurance" request to support.
• The default ruling in Part II is expanded under the conditions listed under Part I upto 3 or 7 days.
• One question that has been answered in precedents case a20100210.2 has a 24 hours "limitation".
  • This limitation is about to say, that the "short time frame" that is spotted on in SM means
    • not 1 month
    • not 1 week
    • it means about a dayrange
    • as there are listed exceptions under Part I of the precedents case ruling, thus means, that this time has to be less than 3 days. 1 hour is also not applicable, but about 1 day (24 hours) its acceptable.

    • As SE's support console doesn't display the users assurance-when entering into the online system (as also discovered under Discovery of precedents case a20100210.2) (a bug report was filed in the meanwhile Bug#882), Support Engineer has to read the dispute filing probably also between the lines. If there are indications, that the assurance has been entered into the system within the last 24 hours, all is ok. If the user writes, he entered last monday the assurance into the system, and today its Saturday, the 24 hours are long gone. Hint: Since Monday, the assurance was long online in the system. The user may have created certs regarding this assurance in the meanwhile, 'cause he received the last missing points to enter the 50 points level, and the Assurer reenters the Assurance with less points, 'cause he made an error on the points level, the system becomes probably broken. If the Assurance has been entered yesterday afternoon, and the user sends the mail today evening, by writing the request, its also ok. The 24 hours is no fixed 24 hours timestamp, so if its 24 hours and 1 minute, its not too late ... it only signals 24 hours or about 1 day range +/- minutes/hours

• As the current dispute filing falls under this precedents case, I hereby dismiss this case and send it back to Support to handle this case under the precedents case a20100210.2

Frankfurt/M., 2010-10-16

Execution

• 2010-10-16 (A): case dismissed regarding precedents case a20100210.2, to be handled under a20100210.2

• 2010-10-16 (A): sends info to (C), (Support), case closed

Similiar Cases

• CategoryArbitration

• CategoryArbCaseOtherAssurerErrors