Before: EvaStöwe (A), Respondent: CAcert (R), Claimants: Laurent O. (C1), Case: a20140327.1

Former parties: Martin G. (C2), Werner D. for Support (C3).

Contents

  1. History Log
  2. Original Dispute
  3. Initial Arbitrator decision about parties in this case
  4. Discovery
  5. Elaboration
  6. Ruling
  7. Execution
  8. Similiar Cases

History Log

Link to Arbitration case a20140327.1 (Private Part), Access for (CM) + (A) only

EOT Private Part

Original Dispute

Hi,

I've made a mistake on assurance #ZZZZ for Bertrand J.

We meet us in <.A.> the 20XX-XX-XX
And I've write on the form <.B.> the 20YY-YY-YY

Bad Values :
 - location of meeting : <.B.>
 - date : 20YY-YY-YY

Good Values :
 - location of meeting : <.A.>
 - date : 20XX-XX-XX

Regards

Statement of Support (summary): 

I ask Arbitration to give Support the order and the authorisation to do all
the required steps to revoke that assurance. The reasons are given in the
following informal mail exchange. The essential point is, that the required
time span to apply the precedence case a20100210.2 is far exceeded. So
arbitration has to authorize it.

Initial Arbitrator decision about parties in this case

This case was by Laurent (C). Martin (as possible Case ManageR) and Werner (for Support) were handling the case file as it was not quite sure if it was a dispute or should be support action. But this does not qualify to have them to be claimants of this case as well. Because of this Martin and Werner and Support should not be party in this case at least at this stage. They are dropped as claimants. The only remaining claimant is Laurent.

Laurent O. (C1), Martin G. (C2), Werner D. for Support (C3) were informed about this in the init mail by the Case Manager.

Discovery

History of case prior to start of arbitration

This case was "lost" between support and arbitration for some while:

Case details

The assurance in question was entered for over 1 day but less than 1 week

Elaboration

Reasons for looking up data about assurance status of assurer and assuree

The reason why this data is requested for the decision in this case is that the case was "lost" between support and arbitration for quite a long time, which was a failure on the side of CAcert. Neither party should be hurt because of this.

If the issue would have been addressed directly, neither the assurer nor the assuree would have trusted on the assurance to be "stable". But they now probably expect it to be there.

Also the assurance in question was not incorrect in the relevant part. So the CARS given by the assurer, that the assured data belongs to the assuree is not affected by the mistake of the assurer. So the core of the assurance as such was reliable all the time for both and for everybody else. A mistake in the place and date of the assurance does not change this.

So if one of the parties would be hurt by a revocation we should be careful to do it in a situation like this, which was caused because of mistakes on CAcert side. In that case we only should revoke if it is necessary OR if we can ensure that the re-assurance is done quite soon. And maybe some other alternatives should be considered.

But if a revocation would not hurt the assurer or assuree it could be in the interest of the membership as such to ensure that the data is corrected.

Basis of ruling

A. Relevance of assurance data and revocation of assurances

During an assurance three kinds of data is entered on the CAP-form: - data about/from the assuree (names, date of birth, email address, signature) - data about/from the assurer (name, signature) - data about the assurance (date of assurance, place of assurance, documents used, points awarded) Further some statements are noted on the CAP form (assurance request, CCA acceptance, assurance performed according to AP)

Overview about the usage/relevance of that data (simplified): While all those details are relevant for the assurance as such, the parts that are later used by the web of trust (WoT) are - the data regarding the identity of the assuree - the awarded points as a measure of trust into the correctness of that data

To enable the WoT to rely on the assurance it's also relevant - that CAcert knows who the assurer is - that the assurer gives an CAcert Assurer Reliable Statement (CARS) that everything else was covered and the Assurance Policy was followed.

The further details of the assurance as such (date, place, documents used) are noted down as a reference for the specific assurance, but are not essential for the reliability of the assurance as such. They could be of relevance if the assurance is challenged to enable the assurer to remember relevant details about the assurance for answering that challenge.

While it is possible to create examples where that assurance data can have an effect on the validity of the assurance, it always only would remain evidence regarding the correctness of the assurance. It is not part of the identity of the assuree. (At least not in a technical sense.)

The interest of all involved - other members, assuree, assurer - is to enable the community to rely on the identity/data of the assurer. The reliance is done on the fact that there are "enough" assurances with "enough" awarded points so that "enough" assurer provided "enough" trust into the data presented by the assure.

But the specifics, the details are not of relevance, in general. The other members are not meant to learn about that kind of data, so they don't rely on that data in detail. (Only on the fact that it exists.)

At least as long as there is no reason provided to question the respective assurance(s). Then and only then, the additional data may become relevant. If and only if the Arbitrator of a case decides so, that data may be looked at and used to evaluate the assurance. In that case the data is used for clarification between the assurer, the assuree and the Arbitrator. Only then and only for those three the specific details are of relevance.

As the details of that assurances data are of no relevance for the reliability of the assured data (the data of the assuree), while the fact that this data exists and can be checked may have some relevance), the interest of all involved - other members, assurer assuree - is again that the community can rely on the assurance regardless of those details at least after the community has started to rely on that data (e.g. a certificate was issued).

Because of this the interest of the community is that assurances remain as long as there is no reason to doubt the core message of that assurance which is about the identity of the assuree. (Or technically about the correctness of the data of the assuree.)

It is not in the interest of the community or the assuree or the assurer, that assurances are revoked later, if there is no reason that the assurance statement as such - the one about the identity of the assurer - is not challenged.

This is the reason why there so far is only a short time frame when the revocation of assurances because of the assurance details can be done by support. Even this practice an be against the interests of the involved parties as the revocation may affect the validity of certificates or the number of assurance points that can be provided by the assurer or even the assuree.

After such a time frame, revoking assurances should only be done if necessary. Only if the existence of one specific assurance would not have any such effects this assurance may be revoked later for "minor" reasons (= not about the reliabilty of the assurance) without the explicit authorisation of the Arbitrator of a case (or a policy / policy group decision). But even this would weaken the web of trust slightly and should not be done lightly. (This is even the case if the assurance is entered later, again, especially if the awarded poins are changed.)

At least in all other cases the interest in the reliability of an assurance is of more relevance than the complete correctness of the data regarding the assurance. This is even the case when assurer or assuree ask for this.

Especially if the details about the assurance data could be changed, noted or covered by other means.

B. interrest of Assurer to correct CARS

On the other hand, if the assurer has entered incorrect assurance details into the database, he has a relevant interest to address this and to give a statement about the correct data. The reason is that by entering the assurance, the CARS of the assurer that all the data is correct is given. Even as others do not rely on all details, the assurer gives a reliability statement and is by this liable for it. Which in general is the idea behind this CARS.

If the assurer later discoveres minor discrepancies in the "additional" data about the assurance as such he gets aware about an incorrect CARS and by this some possible liability, if he does not address this.

The interest to eliminate possible liabilities in such as situation is also an interest of the community as such.

There has to be the possibility for the assurer to update the CARS, if the assurer discovers a mistake that is not about the core of the assurance (assurer data, awarded points).

This would be best done with an option for the assurer within the software to later change the assurance data (date, location) if it was entered incorrectly by the assurer. As long this is not possible at the moment, CAcert has to provide other ways to address the relevant wish to note done an updated CARS about the assurance details.

In theory it is enough that the assurer provides the according updated statement before CAcert.

But as it is relevant that such a statement will be seen, considered and respected if it is relevant in a possible later arbitration case, it is relevant, that the Arbitrator would be able to learn about this updated statement. As long as it is not visible in the respective account/assurance data in the data base, this has to be ensured by other means.

Ruling

1. If support is addressed by an assurer or assuree about a mistake done by entering the date or location of the assurance in the database, after the time frame covered by a20100210.2 is over, support should do the following (assuming that the assurer is not able to update the assurance via the software itself):

a) Inform assurer and assuree about the situation and how it is addressed (including process, and reasoning) as far as sensible for that situation.

b) Ask the assurer to give a CARS about the update of the assurance, including the correct data about date or place of the assurance, if the assurer has not already given such a CARS.

c) Document the update for Arbitration.

Where it is necessary the assurance data and accounts of the assurer and assuree may be looked up.

2. The specific details how the update is documented for Arbitration lies in the hands of the support team as long 
 * as the privacy of this involved data is covered and
 * Arbitration is able to look up the fact that there was an update to an assurance, on their own.

As default the following could be done: Noting the assurance id and the support case number in a wiki page that is only visible for support engineers and arbitrators.

Another solution could be to maintain the updates via a software solution where it is possible to look up the new values by entering the respective assurance id.

What may not be done is the creation of a list where someone is able to look up the new data for every assurance at once. It should only be possible to look up the updates for specific assurances ids (or a list of specific assurance ids).

3. For any lookup of the specific updates to assurance details, a policy or Arbitration authorisation is necessary.

Any (successful) lookup of the updates themselves should be documented with a reference to the arbitration case number which provides the authorisation for the look-up. Again the details of that documentation is left to support. (Default could be a list with assurance id, support-ticket-number and arbitration case number.)

4. This ruling provides the authorisation to look up the updated data on request of either the assuree or the assurer.

5. If the software provides the option for the assurer to update the according data directly, the above ruled process becomes obsolete, while the provisions of how the updated data may be accessed and how updates are documented, should be covered in a corresponding manner.

This ruling does not state how such a software solution could look like. But if there is such a solution, it has to be the assurer, who would have to enter the updated data, as the assurer has to have the control over the CARS that is noted in the database.

If such a solution exists and if it is possible and sensible, the collected updates may then be migrated to the database. Such a migration could be done by other means then re-entering by the assurer.

6. Only under the following conditions support may revoke an assurance because the assurer wants to update the assurance details data after the time frame given in a20100210.2 is over:
 * the assurer and assuree both declare their wish that the data itself is updated
 * the assuree already is assured up to 100 points without the assurance in question
 * the assurer already is able to issue 35 assurance points without the assurance in question
 * the assurer provides a CARS in advance that the assurance will be re-entered within a month after revocation with the same amount of awarded points as before (the assurer should do any necessary checks regarding the assurance points at this time)
 * the time of revocation is coordinated with the assurer.
 * the earlier values are documented in the support case
 * the fact that there was an update is documented in a likewise manner, for Arbitration as described above.
This should only be done as an exception if both assurer and assuree insist in such a solution.

7. The specific assurance that was addressed by the dispute of this case should be handled as above. For this the Case Manager should provide support with the original support ticket number and any other necessary information. The assurance should not be revoked as 6. does not apply.

This ruling can be understood as necessary information of the assurer and assuree.

Eva Stöwe - 2016-09-16

Execution

Similiar Cases

a20100210.2

Birthdate error (with assurance points), existing Precedent Case

a20140129.1

Accidentially assured wrong DoB in account, potential new Precedent Case

Arbitrations/a20140327.1 (last edited 2016-11-01 08:54:12 by PietStarreveld)