diff --git a/TVerifyAssurancePolicy.html b/TVerifyAssurancePolicy.html new file mode 100644 index 0000000..f31b47b --- /dev/null +++ b/TVerifyAssurancePolicy.html @@ -0,0 +1,240 @@ + +
++This is a subsidiary policy under Assurance Policy (COD13). +It documents the acceptance of Thawte-issued certificates +and disclosers as inputs into the assurance process. +
+ ++The CAs listed in Appendix A are approved to "this system". +
+ ++If a certificate is examined by an Assurer (e.g., signed email) +and determined to provide evidence of a Name and email address that +matches the Name stored in the CAcert system, +the Assurer may allocate 25 (???) Assurance Points +(or as determined in the Appendix A). +
+ ++This is only available to Assurers who are: +
+ ++This may be only awarded once per Member. +
+ ++This may be done automatically by the existing +Tverify system. +
+ + ++Webs of Trust listed in Appendix B are approved for this system. +
+ ++If evidence of full "assurer status" in the other Web of Trust +is provided to an Assurer, +then the Assurer may award 25 Assurance Points, +in addition to the above 25 points from the certificate. +
+ +
+The Assurer must go to the other system and verify the +Name. +And DoB??? But the user has to enable each Assurer to +check the DoB by means of the permitting an assurance in the +other system. +
+ ++Assurers enabled for this system must be: +
+ ++This may be only awarded once per Member. +
+ ++What about voting system.... +
+ + + + ++ Agreed that experience as TN is not useful for CAcert Experience Points. +So Maximum is 100. +
+ ++ If the user completes only step 1, the users get 50 points if the + Thawte name matches the CAcert name : The process is fully automated and + the user still can do later the optional steps. +
+ ++ In case the user completes steps 2 or 3, a Tverify-authorised Assurer does the following manual checks : +
+ + ++the CAcert Tverify community member votes Aye or Nay on the request +(faithfullness) and optionally adds a comment on the reason why they reject +the request. +
+ ++If the requests gets 4 Naye, the requests is rejected, the user has to +restart the process. +
+ ++if the request gets 4 Aye, the requests is completed and the appropriate +amount of Assurance points are added to the account, logged as an Tverify +assurance. +BY WHOM? +
+ ++Each user step can granted points only once. The maximum is 150 points. +BLECH +
+ ++To be a Tverify Assurer, an Assurer must have: +
+ ++Authorisation is done by .... + the Support Officer (and confirmed by ??? Assurance Officer). +
+ ++Currently there are 7+ Assurers who are authorised to conduct the +Tverify additional procedure. +
+ ++An online system is run to accept the certificate. +This is located at https://tverify.cacert.org/ +This is a critical / non-critical system ???? +
+ ++WHat do the Thawte docs say about reliance, etc. +Is there a possibility to do this? +What is the liability position? +Chances are, there is no liability and no reliance permitted. +Which means ... there is no reliance on the Name in the cert. +
+ + + +OLD: +++ mandatory : the users provides a + Thawte assured certificate including the user name. + If the name and email address in the certificate matches + the name and email address recorded by CAcert exactly, + the user is given 50 Assurance Points automatically + by the online system. +
++ +
- +no checking of date of birth, +
- +no alignment of these 50 points with AP (statement, checking of date of birth, +there may be some rules about middle names and extracting the name fields out of FirstName and LastName... this is in the system. +should check Thwarte doco to make a judgement call on what it is worth. +
- +Probably this should be 25 points? +