PolicyDiscussions/LegacyPolicy

Legacy Policy (WIP)

How to deal with Assurance Points and Experience Points from Old (Special) Assurance Programs and Assurance Programs under Deployment

Old Assurance Program: Face-2-Face Assurances before or without AP in effect
Old Special Assurance Programs: Trusted Third Parties, Tverify, Super-Assurances
PoJAM special points counting variations

1. Intro

By starting with the Thawte Points removal project, the question arose how to handle problem cases if points are cut off by policies and e.g. members are no longer assurers. On the one side, we shall have general rules for all, and on the other side provide exceptions for CAcert deserts, if needed.
One of the next steps, once the Thawte points clearing is finished, is the rethinking how the old assurance programs points should be counted. AP defines a maximum of 50 assurance points someone can gain in one assurance. In a common CAcert assurance the maximum is 35 points. So it needs arguments, why an old super-assurance with 150 points could have more points then a common CAcert assurance with trained CAcert assurers.
Therefore the Legacy Policy has to be written to define how the old assurance programs shall be brought in compliance with the Assurance policy.
eg. cut all assurance points down to 35 assurance points for all "old" assurance programs?
(This is an issue for the policy group)
In 2009 by Board decision all points have been cut down to a maximum of 150 Assurance and Experience Points that will count, handled by Application Engineer so there are no more then 100 Assurance points and no more then 50 Experience points in the system (150 points combined) that will count.

2. Old Assurance Programs

2.1 Thawte Transferred Points (Tverify)

Thawte Points removal have been advised by Audit, ordered by Board by a board motion.
Assurance Method: Thawte Transferred Points
Min/Max Points: 0 .. 150 (AP + EP)
Recommendations:
- revoke all Thawte Transferred Points (Tverify) as no verification is possible (Thawte server is down) and therefore cannot be verified in a dispute process opposed to every assurance documented by CAP forms.
  - keep records, skip counting (as current 15.php/new points counting schema)

2.2 Trusted Third Parties Points (old program)

The old Trusted Third Parties program is listed in the system with several types of database records.
Assurance Method(s): Trusted Third Parties, Face-2-Face (Location: TTP, TPP)
Min/Max Points: 0 .. 150 (AP + EP)
Recommendations:

AP: cut points awarded down to 35 Assurance Points maximum

EP: cut experience points based on awarded points over 35 pts (15.php experience points other ways)

There are several options possible: a. display/split points by online calculation (similar to 15.php), b. skip counting, create new records that counts with note "correction of old TTP", c. depricate points in full

In TTP assurances (old style) there was no F2F meeting (do not count as a valid F2F assurance)
No CAP forms exist by the TTP-Admin, so therefor is unverifiable through a dispute filing.
Assurees who received 150 pts in a TTP-assurance (old style) had experience in giving Thawte Assurances. But ex-Thawte assurers are warned since 2009, that Thawte points will be removed by the Thawte Points removal process. So therefor to cut Assurance points _AND_ Experience points down to 0 by a received TTP-assurance (old style) is a logical conclusion

2.3 Super-Assurances

Old Super-Assurers program pushed the points level to 200 points. Face-2-Face Assurances issued points so counted up to 150 AP+EP points
Assurance Methods:
1. to make Assurers Super-Assurers: Temporary Administrative Increase, maybe Permanent Administrative Increase.
2. Super-Assurers making Super-Assurances: Face-2-Face
Min/Max Points: 0 .. 150 (AP + EP)
Recommendations:

AP: cut points awarded down to 35 Assurance Points maximum

EP: cut experience points based on awarded points over 35 pts (15.php experience points other ways)

In Super-Assurances a F2F assurance was made (counts as a valid F2F assurance)
CAP forms exist by the Super-Assurers that are verifiable through dispute filing.
In difference to old TTP assurance program, assurees who received 150 pts in a super-assurance had no experience in giving CAcert Assurances. So therefor to cut experience points down to 0 by a received super-assurance is a logical conclusion

2.4 PoJAM before/between/after deployment period

Software implementation regarding PoJAM restrictions was slow. The question is, how to count assurance points entered into the online system for several pre-software-implementation periods:

2.4.1. PoJAM in effect, Checkboxes added to Software

add PoJAM checkbox in case of current Junior assurance (checkbox "parental consent established" enabled)
- High Risk Applications check:
  - check in case -> (DoB assuree > current date - 18 years)
    - ```
    sample:
     DoB 1997-05-01
     today 2013-05-09
     => today - 18 years = 1995-05-09
     => compare 1997-05-01 > 1995-05-09
     => True
```
- -> calculate points based on:
  1. assurance date (notary assurance date) > patch install date + required checkbox is set => accept
  2. assurance date (notary assurance date) <= patch install date, ignore checkbox setting => accept
    comment: The "notary table" is a data base structure that records the assurances received and given. If assurance date (notary assurance date) is greater than patch install date and checkbox is not set, it will not become a notary record, since when entering the assurance into the online system, an assurance without the parental consent established (case is not available in check condition) must be rejected.
    Process flow: 1. A Junior (PoJAM case) undergoes an assurance. 2. The assurer checks that Parental Consent has been established 3. The assurer enters this assurance into our online form, then the Online form adds automatically the "Parental consent established" checkbox in case DoB is greater than today - 18 years 4. If the assurer didn't check the Parental consent, he cannot finish this current assurance ( -> assurance rejected and no notary record created) 5. If the assurer has verified the Parental consent, he ticks the checkbox for "Parental consent established" and this info will be saved together with the other informations to the notary record
- check is required by actions started:
  1. create certs
  2. giving assurances

2.4.2. PoJAM in effect, Checkboxes not implemented to production

Handle "old" received assurance points like every other "old" assurance points handling (except tverify program) (handling of "old" points is subject to Policy Group decision -> Legacy Policy -or- a board motion -or- Arbitration)
for received assurance points (notary.date) since PoJAM came in effect (p20100119 PoJAM to DRAFT).
- handle as "Parental consent established" - removal of assurance points/non-counting of assurance points is subject to legacy policy.
- Event reports received since that date reports assurances under PoJAM were in compliance to AP (including PoJAM), so there is no reason to generally revoke such points.
- PoJAM 3.3 delegates the duty to be compliant with PoJAM to the Assurer (this includes entering PoJAM cases into the online system) so therefore entered assurances have to count as if checkboxes had been set by the assurer, cases are verifiable via dispute (CAP form includes a note about parental consent established by parental signature or an Assurers note: parental consent established, assurers signature CARS) x¹)
  - x¹) Tverify points cannot be verified through disputes as the verification system check, the running Thawte server is offline. In case of "old" PoJAM cases, these cases can be verified starting a dispute

2.4.3. PoJAM WIP period, AP in effect, Checkboxes not implemented to production

for received assurance points (notary.date) between 2009-04-01 and PoJAM came in effect (p20100119 PoJAM to DRAFT)
- these points are questionable as AP prevents entering assurances without parental consent into the online system
- But there are some known cases from 2009 2nd half around PoJAM deployment period, that assurances has been given for Junior and entered according to PoJAM WIP into the online system, that did follow the "parental consent established" requirements
- in case of question, the cases are disputable, parental consent verification through dispute filing, Arbitrator to request information from Assurer, that parental consent has been established in assurance process by note on the CAP form or signature by parents
proposal:
- Ignore these cases (as consent has been established), handle assurance points according to other fade out rules, eg. General Assurance Points fade out (see below)
- In case of question, a dispute filing can be started to be checked by arbitration

2.4.4. PoJAM cases before AP in effect (Checkboxes not implemented to production)

for assurances before AP did come in effect (effective date ~2009-04-01)
- Motions
  1. AP to DRAFT: p20080712.1
  2. AP to POLICY: p20090105.2
  3. Assurance under AP only: m20090912.1
  4. Confirm motion m20090912.1: m20090914.2
  5. AP rollout by ATE's: since April 2009
- handle points according to Policy Group decision (currently undefined, Policy not yet written, therefore points counting unchanged)
proposal:
- handle assurance points according to General Assurance Points fade out (see below)
  - reason: today, now more then 4 years after Assurance Policy comes to effect, Assurees have reached age of 18. Revocation or cutting assurance points to follow other rules (eg more then 35 Assurance points to cut, General Assurance Points cut), the requirements for a parental consent faded out.

3. Weak Notary Database Records

3.1 Unknown

Datebase contains an unknown count of assurance records with Assurance Method "Unknown"
The source of these records can be prior first database structure upgrade assurance records, that have been flagged "Unknown" (unverified assumption)
Recommendations:
1. Method 1
  - revoke "Unknown" assurances records.
2. Method 2
  - skip counting "Unknown" assurances records (current 15.php/new points counting handling)
3. Method 3
  - keep "Unknown" assurances records, skip counting, add new record with note "arb# correction Unknown"

3.2 <empty>

Datebase contains an unknown count of assurance records with Assurance Method "" (<empty> field)
One source of these records is a bug in TTP assurances that results in an <empty> Assurance Method. The 2nd source is a bug doing assurances by an assurer who has the Board flag set (sometimes).
Recommendations:
1. Method 1
  - revoke "<empty>" assurances records.
2. Method 2
  - skip counting "<empty>" assurances records (current 15.php/new points counting handling)
3. Method 3
  - keep "<empty>" assurances records, skip counting, add new record with note "arb# correction <empty>"

3.3 Method: Face-2-Face and Location field note(s): TTP, TPP

These records have been entered as TTP assurances as a workaround while the TTP bug results in <empty> assurance method records (see above)
Recommendations:
1. Method 1
  1. F2F, TTP: correct assurance method with "Trusted 3rd Parties" and Locations field "TTP"
  2. F2F, TPP: correct assurance method with "Trusted 3rd Parties" and Locations field "TTP"
    - TPP was a typing error, that have been entered probably in a bulk process several times into the webdb !!! so therefor counts as addtl. issue here
    - Infos from: a20091118.1 discovery "TTP variants" and a20110221.1
2. Method 2
  1. keep old weak notary records, but skip in counting points
  2. create new notary records with note "arb# correction to F2F TTP case" -or- "arb# correction to F2F TPP case"

4. General Points fade out

Assurance Points fade out
- Ongoing discussions about a general Assurance Points fade out requires a definition by Policy Group
- i.e. by latest Baseline_Requirements_V1_1 (effective 14 September, 2012) specifications:
  1. 11.3 Age of Certificate Data
    - "that the CA obtained the data or document from a source specified under Section 11 no more than thirty-nine (39) months prior to issuing the Certificate"
  2. 11.6 Data Source Accuracy
- By following Baseline Requirements Assurance Points have to fade out after 39 months, this effects the Community by giving assurances every 39 months to every assuree. This is a burden to CAcert deserts, were we just started with the new TTP-assisted-assurance program (under deployment). Assuming, that there exist no assurer nearby, the assuree requires a re-assurance by the same assureres as 39 months before (clashes with current AP definition! assurance can be only made once ... With the new points counting schema, this restriction can be lowered, by a new definition, that re-assurance from one assurer over one assuree replaces previous assurance
Experience Points fade out
- While active in Assurance area, every assurer has the experience required, to do assurances under current set of policy framework. After a sabbatical, assurer requires some update, what have changed in the meanwhile. So it can be assumed, that the assurers experience decreased. To take into account about experience in the assurance area, the count of experience points requires a dynamic update. Eg. vacating assurances for longer then 2 years, requires doing some new assurances, to gain experience again or to recover the experience state as before vacation.
- Possible measurements are:
  1. time of assurances given
    - Assurances given by the time AP was not in effect, has to count less, as all the requirements by AP aren't in effect (eg check CCA agreement)
    - given assurances in 2009 as AP has been rolled out varies in strength. In the meantime, several changes in Assurance area requires more knowledge by the assurers, a refreshment by training (new CATS test, attending an ATE) makes an experience update prudent
  2. total count of experience points received
    - decreasing 10 EP per year, requires at least 5 new assurances per year to be uptodate with total count of assurances. In CAcert desert areas, this probably can become difficult, as one assurer can only assure the 5 existing assurees again (this may be an option, if AP fade out is also decided)
    - Current AP definition allows only one assurance over one assuree (to meet the requirements, that at least 3 different assurers are required to reach the 100 Assurance Points level).
    - We still have cases, where its practicle, to have a re-assurance over one assuree by an assurer, who assured the member before. That is the Password reset w/ assurance case. Its better to do a re-assurance that a member can recover his account then any other processes. The limitation, you can only assure someone once, needs to be changed to: your assurance over one assuree only counts once - so the newer assurance overwrites older assurances in counting (the assurance records are still in the database, but skipped in counting, similar to the Thawte points removal, the records are still kept in the database, but the points are no longer counted).

CategoryPolicy