• Arbitrations
• a20110610.1

• Case Number: a20110610.1
• Status: closed
• Claimants: Marc L
• Respondents: CAcert

• Case Manager: BernhardFröhlich

• Arbitrator: UlrichSchroeter

• Date of arbitration start: 2011-06-11
• Date of ruling: 2011-06-15
• Case closed: 2011-06-15
• Complaint: Removal of suffix
• Relief: TBD

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

History Log

• 2011-06-10 (issue.c.o) case [s20110610.12]
• 2011-06-10 (Support): addtl. infos about this case
• 2011-06-11 (A): added to wiki, request for CM / A
• 2011-06-11 (A): I'll take care about this case as (A)

• 2011-06-11 (A): I appoint the (CM) as per Arbitration Team meeting 2011-04-05 decision

• 2011-06-11 (A): sending initmailing to (C)
• 2011-06-11 (C): acceptance to CCA is given in original dispute filing
• 2011-06-11 (C): as requested I confrim the arbitration and accept the Arbitration under the CAcert Community Agreement and the Dispute Resolution Policy.

Original Dispute, Discovery (Private Part) (optional)

• Link to Arbitration case a20110610.1 (Private Part)

EOT Private Part

Deliberations

• "Mr." is a suffix that cannot be found in IDdocs

• Advice on how to add a suffix in the join form is not realy helpful and has been marked as inproper with a ruling in case a20100207.2, so errors made by new members is a regular occuring request for name changes

• Currently there are at least 4 suffix removal request arbitration cases running that fills the arbitration queue

• Why not handle this case under precedent case a20100207.2?

  • a20100207.2 requests claimant for searching for 2 experienced Assurers who can confirm the name change request thru two seperate additional Assurances. The general rule "You can reduce informations, but you cannot add informations that you did not read in at least one IDdoc" does not need addtl. evidence gathering for a simple suffix removal request.

  • With enough experience within Arbitration and handling regular standard administrative name change requests, all cases follows a schema that is yet defined in the PracticeOnNames: Removal of information is possible, especialy for suffixes, adding information needs inspection

  • Later precedent rulings regarding name change requests conclude that Support can handle these cases w/o further Arbitration involvement by giving Support-Engineers the empowerement to handle similiar cases following a given procedure
  • We cannot prevent this type of error at all, so these requests (suffix removals) will continue

  • Two similiar precedent cases have been ruled: a20110119.1 and a20100227.1.

  • But these cases does not fit to the suffix removal request. Also the precedent case a20100207.2 is no longer appropriate (removal of information allowed w/o addtl. assurances)

  • 3 running cases a20100310.1, a20100312.1 and a20110417.1 tries to take care about these circumstances and tries to give a new precedent ruling, but all 3 cases stalls.

• So therefor giving a 4th try of a new precedent ruling that has to cover:

  1. a20100207.2 case needs to be overruled

  2. A simple precedent procedure that Support can follow similiar to a20110119.1 and a20100227.1 cases, that has to include the following topics:

     1. a ruling does not need to take care about remaining givennames as a20100227.1 does

     2. precedent case # to add to the support ticket for later reference

     3. has to check CPS definitions as per 2009-11-08. request from user a confirmation, that no cert includes the removed name part (-> suffix) or the certs has been revoked

     4. requests for adding suffixes aren't affected, and needs to be moved to arbitration
     5. differentiate if request for suffix removal is from assurer or from assuree itself
     6. what to do with the assurers who confirmed a wrong suffix? sending advice? or is this case a minor error?

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 names or name parts:
    * in general: its allowed to reduce information, but it is prohibited to add informations

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:

• Should get Assurers who assured a user with a wrong suffix an Assurers advise?

This opens the next question:

• does an Assurers advise increase the assurance quality over irreducible suffix errors?

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

• Support should add the precedent case number to the support ticket exec report note

• This case can be handled also under precedent in combination with precedent case a20100227.1 or other precedent cases.

  • In such a case both precedent case numbers has to be added to the support ticket as exec report note

  • In such cases (multiple name errors -and- suffix removal request), Support is empowered to check the list of assurers who assured the user with errors in his name, to send them an advise following the template Arbitration Training Lesson 51 - Advice: Assurer Name errors on a case by case basis (eg assurances added long time before AP comes in effect, Assurers that didn't attend an ATE before)

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

• 2011-06-15 (A): ruling and exec request sent to: (C), (Support), (CM)
• 2011-06-15 (Support): I excetute the ruling and removed the suffix "Mr" from the account. This tikcet is closed now.
• 2011-06-15 (A): Exec report notification to (C), (CM). Case closed.

Similiar Cases

• CategoryArbitration

• CategoryArbCaseAccountDataNameModificationsRequested