CAcert Code Development list.

[<ulrich AT cacert.org>]

Hi,

hot stuff ;)

Ok, one point to keep in mind:

following scenario:

A user (Harrold) creates his account with (Harold) in the Givenname field.
The account receives 4 assurances, each with 35 points by assurers.
The 5th Assurer detects a name problem: Harrold <> Harold
Enters 0 points, writes down description: Harrold <> Harold

The dispute is filed by Assurer #5
The arbitrator now sees
4 times successful given statements: Givenname is Harold
1 times: there is a name mismatch: Harrold <> Harold
So now, who is wrong, who is right ?

Following possible scenarios may happen:
1. User enters "Harrold" onto the CAP, but enters "Harold"
   into the account. ID docs states "Harrold"
   -> #5 is right

2. User enters "Harrold" onto the CAP, but enters "Harold"
   into the account. ID docs states "Harold"
   -> #1-4 are right

what does this mean ?
on scenario #1, 4 Assurers made false CARS statements
on scenario #2, 1 Assurer didn't made a false CARS statement
                  but covers a problem ...

The Arbitrator can only get the correct result in this
question, which scenario is right, by asking for a ID doc
scan from the user or he have to ask addtl. assurers
to confirm the correct name from ID docs.

This scenario did happen at Froscon 2008 and
also at Cebit 2010
Both results in scenario #2 was right.

So what we have in the records?
scenario #1:
4 assurances, 4 times 35 pts
1 assurance, 1 times 0 pts
Arbitration result: 0 pts wrong

scenario #2:
4 assurances, 4 times 35 pts
1 assurance, 1 times 0 pts
Arbitration result: 4 times 35 pts are wrong

The question now, are the assurers allowed in scenario #2
to re-enter the assurances ?
What is with the one 0 pts assurance from assurer #5
in scenario #1. Have this to be removed from the records?

> Then, when the Arbitrator sees a filed dispute about a Name error, she
> can get the SE to print out the last Assurances, and check the comment
> fields.  She only needs one comment field (CARS) to support the member's

> request ... and then she has the evidence needed to make the ruling.  No

> contact to user or assurer required!

by only print out the last line of the assurances rcvd
with the disputed Name error, this doesn't work ...


regards, uli   ;-)


-----Original Message-----
From: Ian G 
[mailto:iang AT cacert.org]
Sent: Tuesday, March 16, 2010 2:52 AM
To: CAcert Code Development list.
Subject: strawman proposal: add a comment field to the Assurer's entry
into WoT


I was looking at this dispute filed today ("my account name has a G in
it and the docs do not;  the assurers won't assure me") and it occurred
to me that problems like this are hard disputes.

They are hard because the Arbitrator can't easily assemble the evidence.
  Partly because the refusal to assure doesn't create any reliable or
callable evidence [1].

But also because a zero point assurance does not state what the reason
is for lack of confidence.

What we could do is have the Assurer add in a comment into his entry
that specifies the rough reason why no confidence established.  Then, we
could provide some guidance to the Assurer in the Handbook, like this:

   * if there is a name clash, describe the documented name in the
comment field.
   * if the documents are unfamiliar, put "UD - country" in the comment
field.
   * if the DoB doesn't match, put "DoB = 10/10/10" in the comment field.

etc etc.

Then, when the Arbitrator sees a filed dispute about a Name error, she
can get the SE to print out the last Assurances, and check the comment
fields.  She only needs one comment field (CARS) to support the member's
request ... and then she has the evidence needed to make the ruling.  No
contact to user or assurer required!

How does that sound?

I think it is a bit of a change to the way CAP forms are treated ... as
before, only verifications are done.  This is a bit more like the
location field;  the Assurer is entering in new information about the
assurance.

iang

[1] AP tries to rectify this because it suggests that the Assurance
should be completed with 0 points.  at least then we have the evidence
that something happened, which added zero confidence.

Attachment: smime.p7s
Description: S/MIME cryptographic signature