Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: Marc L (C), Case: a20110610.1

History Log

Original Dispute, Discovery (Private Part) (optional)

EOT Private Part

Deliberations

Ruling

Part I - Overruling precedent case a20100207.2

Suffix removal requests falls under the general rule, that is also given by precedent case a20110119.1 for transitions in names and a20100227.1 that handles reduction of middlenames, as long satisfying the requirements of Assurance Policy, Assurance Handbook and Practice on Names. This is also given by the Assurance Handbook general rule for suffixes:

For the removal request to execute: addtl. evidence gathering eg. by addtl. assurers is not needed in this case whether the suffix was written correctly before and can be found in the users IDdoc or not.

So therefor I hereby overrule precedent case a20100207.2 that requests for addtl. evidence gathering by two experienced assurers from the user is no longer needed.

Part II - New execution steps for suffix removals

By following a20110119.1 for transitions in names and a20100227.1 that handles reduction of middlenames ruling, I hereby rule that Support is empowered to process suffix removal requests satisfying the requirements of Assurance Policy, Assurance Handbook and Practice on Names. If a suffix is removed the resulting full name is in compliance with the definition given under PoN Practice on Suffix.

  1. if request is from assurer, request name change request confirmation from user (if confirmation by the user cannot be read from the dispute filing) (-> template email) else continue next step

  2. change name as requested (suffix removal)
  3. request confirmation from user, that:
    1. no certs issued after 2009-11-08 exists (thats the date when CPS comes to DRAFT) that includes the removed suffix -or-

    2. that user has revoked existing certs that includes the requested removed suffix (-> template email)

Part III - Training purpose or not?

The topic "training purpose" results in the question:

This opens the next question:

The simple answer is No.

From ATE experiences, the Assurers who received a training, just running into the same problem with the addtl. suffix. As shorter the suffix is, as more likely it is that Assurers do oversee the suffix in the 2nd of the double check.

An Assurers advise makes only sense in a case, where multiple name errors are detected. Eg Suffix wrong and Givenname wrong or Suffix wrong and names switched around.

If there is only the suffix problem, an assurers advise is to read that we want to blame our assurers for everything (-> nitpickering)

Suffix problems are like a typo, caused by incomplete or missleading instructions given in the join form. So everyone who is new to CAcert thinks something about what to enter into the suffix field, but do not receive all the needed infos about this topic to deccide which infos to enter at the time the user enters his data into the online form.

The next step is the Assurers part, to take care about this issue, to detect wrong suffixes and bring them to notice. The main goal here is, to ban the suffix problems out of the database. So every detected suffix problem should be handled as simple as possible, without further blaming of our Assurers. This changes in another issue if there are also other errors in names (see above: multiple name errors)

I hereby came to the following ruling:
Suffix removal requests can be seen as minor excusable errors. An additional check over assurances received by the user account with a suffix that is not in compliance with the PoN definition and that has been requested to be removed is not neccessary. The original request by Support-Engineer within Arbitration case a20110417.1 where Support is currently handling a case in which a user is involved with an invalid additional suffix, that Support is authorized to lookup assurances over a user -and- to contact the assurers who assured the user for training purposes by sending them an assurer advise, needs to be handled fine graded, its overwhelming the suffix problem only case. This doesn't cover cases about Givenname, Middlename or Surname errors that can be handled eg under precedent case a20100227.1

Part IV - Precedent case

This case is to be set to the new precedent case for suffix removal requests

Part V - Proactive action by SE ?

Current running case araised out of an ATE by discussion between assurers and an assurer. So the assurer adviced claimant, to file a dispute.

There also might be a possible situation, where Support-Engineers handle a case and get aware of a suffix in the users name that is not in conpliance to PoN definition eg. within a password reset procedure. Should now a Support-Engineer to be allowed to get in contact with the user, to talk with him about a potential suffix problem so in the end the user starts a request for suffix removal?

As our Support-Engineers are all Assurers with experience in name handling in user accounts, it can be assumed, that a user who started a support ticket that results in checking the users account by a Support-Engineer, gives the Support-Engineer the access permission to the users account and the Support-Engineer can easily detect a potential suffix problem. If, and only if such an access permission is given by the user, Support-Engineer can contact the user also about a potential suffix problem. By doing so, Support-Engineer has to open a new ticket number, that does not relate to the original Support request by the user, so a potential suffix removal request becomes handled within its own support ticket.

I suggest, but this is not a requirement, that the following suffix removal request by the user is handled by another Support-Engineer then the SE who started the suffix removal request thread with the user.

Frankfurt/Main, 2011-06-15

Execution

Similiar Cases

a20090823.1

Assurance with an additional Suffix

a20090618.8

User has non-validated middle name in account

a20100207.2

suffix removal from account - Precedent Case

a20110119.1

Changing transliteration (diacritics) in my first name (Lukasz K) - Precedent Case

a20100227.1

Small modification in username + Account Cleanup (Dirk R) - Precedents Case

a20100310.1

Need suffix to be removed

a20100312.1

Name with addtl. Suffix

a20110417.1

Suffix in Name (DA/PZ)