• TTP

• česky | english

TTP-Assisted Assurance Program (Subpolicy)

TTP-Assisted Assurance Subpolicy

This is the top-level page for the TTP-Assisted Assurance (sub)programme. TTP-Assisted Assurance Subpolicy is a subsidiary policy of Assurance Policy

• The TTP-Assisted Assurance Policy is now approved to DRAFT

  This new policy now has to be implemented.

Steps & tasks

Assurance Team! Start your engines . . .

Glossary: {+} finished - {0} happening, allocated, planned - {-} warning, needs attention! - deffered to later

Informations for TTP-Users (Assuree's)

If seeking TTP-Assisted Assurance, this is your page:

• TTP-Users {g}

Informations for TTPs or Trusted Third Parties

This is for people who might be asked to check ID documents for CAcert Assurance purposes:

• TTP/TrustedThirdParty {g}

  • If seeking TTP-Assisted Assurance, point your chosen TTPs at that page.

Informations for TTP-Assurer (TTP-Admins I, Senior-Assurers)

• TTP-Admins {g}

Informations for TTP-TOPUP-Assurer (TTP-Admins II)

• TTP-TOPUP program

Administrative Tasks

• TTP Support tasks

• Assurance Officer (AO)
  • Maintain the TTP-Assisted-Assurance program
    • Documentation
    • Processes

    • Deployment from Policy to Practice TTP/TTPprogram TTP/TTPprogram/Deployment

TTP CAP form deployment

First draft CAP forms for TTP-Assisted-Assurances (WIP) of a TTP-CAP form. As there is a actual TTP CAP available you have to request it via support.

Draft

1. You have to request a TTP-CAP-Form with an email to support.
2. TTPadmin sends prefilled TTP CAP form to TTP user

references

For more information about Trusted Third Parties see

• AssuranceHandbook2 - Your primary source for all general information about getting Assured (meaning of programmes and terms: CAP, WOT, TTP, ...)

• FAQ/AssuranceByTTP - Getting Assured by a Trusted Third Party (TTP) (information for the Member)

• FAQ/AssuranceInformationForTTP - How to conduct an Assurance as a Trusted Third Parties (TTP) (information for the accountant, notary, etc)

• Availability by countries - those countries that do not have TTP available in them any more

• TTP Assurance Policy (wip) - work-in-progress policy document covering TTP Assurance

• Remote Assurance Policy (wip) - work-in-progess policy document replacing TTP Assurances. See also the http://svn.cacert.org/CAcert/Policies/RemoteAssurancePolicy.html WiP RA policy document. Suspended

• Matrix of Roles - who can be a TTP Assurer, by official qualification in each country Suspended

Pink Box Procedure

• Iang this section is the Pink Box that was in the policy document, intended to be placed in the handbook at some point.

These steps are taken.

3.1 Preliminaries

1. The Member creates her account and attempts to be assured by the routine face-to-face process.
2. Once determining that none are conveniently located, the Member contacts an Assurer who is enabled to conduct TTP-assisted assurances in the region.
3. The Assurer confirms that the Member agrees to the CAcert Community Agreement (CCA), including the Dispute Resolution Policy (DRP).
4. The Assurer confirms that standard Assurances do not meet the needs of the Member. This is only likely in areas not well-served with Assurers.
5. The Member and Assurer must negotiate the selection of TTPs and the provision of adequate identification documents to the TTP. Each TTP can only be used once (within one assurance for this Member).

   • Iang: this may suggest a Patch required to the system that permits the Assurer to check other TTP Assurances of the member.

6. Assurer agrees to conduct the TTP-assisted Assurance, and gives the Member a Token.

3.2 Face-to-face meeting with the TTP

1. The TTP and the Member meet face-to-face.
2. The TTP shall confirm that:
   1. The Member agrees to the CCA.
   2. The Name and Date of Birth details recorded on the form are matched by those in the identity documents.
   3. The method (document type and issuer, not numbers) by which the Name and DoB details are matched is stated on the form.
   4. Location of the meeting.
   5. Contact details for the TTP
   6. Assurer's Name and Token.
3. The TTP shall use either the local form of document (on CAcert's approved list), or a CAcert-provided form.
4. The TTP shall log the event by their customary means, including the Assurer's Name and Verification Token.

   • Old: leaving a Remote Assurance Form and copies of identity documents with the TTP for at least 60 days

5. The paperwork is sent to the Assurer by the TTP.

   • Old: sending a Remote Assurance Form and copies of identity documents to the Assurer by mutually agreed medium (eg post, web form or encrypted email).

   • iang: this requirement was informed by DRCi C.9.b:

     • "RAs provide the CA with complete documentation on each verified applicant for a certificate."

   • RA is registration authority which is a verifier of people who is outside the CA. For us, Assurers are our RAs.

   • What is different? In the old version of TTP, the TTP was the RA. Thus the criteria would require the TTP to send the form, not the Member.

   • However in the new TTP-assisted version of assurance, the Assurer is the RA, and the existing arrangement of the RA's documentation process (forms provided to Arbitrator) are workable. Also note responsibility laid out in 3.d, the TTP-assist assurer makes a CARS of the Assurance Statement over the subject member. Ergo the Assurer is the RA, and is the responsible party.

   • Hence, the above point 5. is likely going to change.

3.3 Completion of the Assurance

1. The Assurer must confirm the assurance using the paperwork,
2. The Assurer must be satisfied as to the identity and competency of the TTP in identification procedures, as though they were to be conducting the assurance themselves

   • Iang: this clause would probably meet DRC C.9.a:

     • "When the CA uses an external registration authority (RA), each RA is positively identified by CA personnel before being authorized to verify identities of subscribers and authorizations of individuals to represent organizational subscribers (see §A.2.v)."

   • For that reason, the above clause should be considered strongly, and either discussed further in the Handbook, or include these other Older suggestions:

   • RA MUST authenticate the TTP to their satisfaction by:

     1. searching for their details in an appropriate, official public registry (eg government site, association registry, telephone book)

     2. contacting the TTP using these details to verify their identity

     3. verifying that the TTP is suitable in terms of meeting the requirements of this policy

     4. verifying that the meeting did indeed take place and that the Assuree was adequately identified

3. The Assurer may contact the TTP, quoting Name and Verification Token.
4. On completion of the assurance, the Assurer allocates standard full Assurance Points (35 at time of writing) to the Member. Given the work involved, the Assurer should strive to ensure that full points are allocated by for example requesting any rework required.

   • Iang: this clause might be better off in the Handbook.

   • Dominik+1
5. The assurance must be entered into the system using the TTP flag/method.
6. The paperwork is held by the Assurer according to the normal Assurance Policy rules (at time of writing, for 7 years, and available to Arbitrators only).

Old TTP programme

Note that the TTP programme is effectively was frozen because it was knocked out by AP rules.

Proposal 2011-06-30: workflow User -> TTP -> TTP Assurer

1. user sends TTP Assurance request to support@c.o

2. triage moves request to TTPadmins pool
3. 1st TTPadmin picks up the request, ackknowledges the users primary email address

4. TTP admin triggers pre-TTP-assurance process thru the webdb (-> similiar to assure someone (to get the users data) + print a cap form (to add TTPadmins postal address)) with users primary email address, pre-filled ttp cap, and adds the TTPadmins postal address, prints the form to pdf, and sends the prefilled pdf to the requesting users primary email (see Bug #988)

5. user prints out the pdf and go to the next accepted TTP and brings in a pre-stamped envelope
6. TTP sends the prefilled and filled document back to the TTPadmins postal address as printed on the TTPCAP
7. TTP admin enters the TTP assurance into the system and sends topup request if checked in ttp-assurance to the TTPadmin pool

8. user sends 2nd TTP assurance request to support@c.o

9. similiar to steps 2-7
10. after 2nd TTP-assisted-assurance 3rd TTPadmin picks up the topup request and contacts user for the topup procedure

Glossary

• TTP	Trusted Thrird Party	relaible person to assist the Face to Face process of an assurance to prove identity of an Assuree
  TTP User		Person who would like to get assured with the TTP program
  TTP Assurer		CAcert Senior Assurer who enters the assurance into the CAcert system and checks the information provided by TTPuser and TTP
  TTP Admin		CAcert Senior Assuer who conducts the TTP TOPUP process

• TTP-assisted-assurance subpolicy defines:

  • TTP	Trusted Thrird Party	relaible person to assist the Face to Face process of an assurance to prove identity of an Assuree
    TTP User		Person who would like to get assured with the TTP program
    TTP Assurer / TTP Admin		CAcert Senior Assurer who enters the assurance into the CAcert system and checks the information provided by TTPuser and TTP
    TOPUP Assurer		CAcert Senior Assuer who conducts the TTP TOPUP process

For more terms and translations in other languages, see the glossary.

• CategoryAudit

• CategoryPolicy

• CategoryAssurance

• CategoryAssuranceTTP