Actors

This page collects who are the actors (abstract people) involved in the processes of CAcert.org, and what things (use cases) they need to do.

Personas for Roles

We can also use placeholder names to reference the different actors in our search for functional requirements.

• Alice is a registered Member of CAcert.org
• Bob is an Assurer, a Member with 100 or more trust points and with the CATS approved.
• Nona is someone else who is not necessarily registered in CAcert.org. It derives from from Grandma in Italian, and Non-related person.
• Stephanie is the girl from Support, assisted by Stephan, the guy from Support.
• Justine is an Arbitrator for a given case (from "Justice") perhaps.
• Carol - might be someone engaged in a four eyes or dual control process, such as the CAse Manager?
• Trent - the trusted third party, often used as a description of the CA. The problem with this is that Trent / the CA isn't a person in the protocols, because we are disassembling the CA and looking in deeper.
• Organisations Admins
• Org assurers
• External Application
• Special verifiers/administrators?
  • (TTP, Tverify...)
• Board people
  • has tokens to give out.

NRP / Nona / NYRP "nerp"

• Join, become Alice.
• Contact Support
  • without needing to use HTTPS
• File a dispute as a non-member.
• Download CRL / OCSP (this is not reliance)
• (Inform self about CAcert)
• donate to CAcert
  • (anonymous donations are problematic)
• do things permitted under NRP-DaL:
  • get the root certificates installed?
  • verify a certificate is still valid?

Members

Alice

Alice is the registered Member who agrees to the CCA and is part of the Community. Alice can do:

• All things that a Nona / nerp can do.
  • (as far as the system is concerned, the Member cannot re-login / or re-join)
• login
• Contact support
  • (securely)
  • using multiple methods of authentication
• certificates:
  • get a certificate (according to points)
  • client / server / code-signing
  • choose a root to sign the cert
  • revoke her certs
• get a PGP signature
  • upload public key
  • download it signed
  • (server cannot make publically available / will not be a keyserver)
• Assurance
  • Enter the Assurance Points that she allocates over Bob (mutual assurance)
  • see who has assured her
  • see how many Assurance Points she has
  • see who she has (mutually) assured
    • See the details of each of her assurances
    • correct an assurance
    • adjust an assurance?
  • add a reliance data (domain, email, Name) also delete
    • maybe not delete the name with maximum points
    • initiate a ping, anytime
    • change the primary (CCA) email address.
  • Authorise an Assurer to do an Assurance
    • or, confirm an assurance done on her by Bob.
    • or dispute the Assurance.
    • or, confirm that Bob can see her Names and DoB. Bob in particular or all Assurers.
  • Confirm that Bob is an Assurer
  • Contact an Assurer who is engaged in an Assurance over her
• changeing account information
  • DoB -- can change by Arbitration, but can only be one
  • preferred language
• See other status information
  • Challenge results
  • various support fields as documented in Support section.
• authentication
  • change passwords
  • change & view questions
  • change her credentials methods
• engage in different password recovery protocols
• authorise an Assurer to view account details
  • this is how Thawte is doing it
  • Member can perhaps control how Assurers can see the data???
  • (implementation)
• Member can view event log over account
  • includes whenever a person gets access to the account,
  • everything should be there.
• file a Dispute
  • about known and standard things:
    • domain and email address?
    • Name changes?
    • Assurances, Points?
    • request to terminate the CCA / close the account
  • on open things

Things Alice doesn't get

• make her certs & keys available for the public to download
  • secure system will not provide key server features.
• upload photo is currently not offered
  • we are not a social network :)
• upload scans
  • this can be in an issue tracking system if needed.
  • TTP, photoID and Organisation Documents
• Assurance:
  • Take the Assurer Challenge.
  • Any hint that intends to become an Assurer? Which would be useful for Event Notifications, changes, etc.
  • Find an Assurer
  • Contact a random Assurer
  • Contact another Member

Assurer / Bob

Bob, an Assurer, can do everything Alice can do, and:

• Assurance:
  • authorise a Member to do a mutual Assurance over him
    • Alice needs to see his Names and DoB.
    • this should not be generally available to her, should be authorised directly by Bob.
  • Practically everything else is the same for Alice, as she can do Assurances under supervision.
• file a dispute
  • a name
  • a DoB
  • email address?
  • same as with Alice on herself?
  • but Bob is more likely to want to do this on Alice.
• help those he has assured to reset their passphrase
  • discussion in progress
• access a random Member's data
  • sends the log message to Alice when she is looked at

Things outside:

• Notify the person if an account is not created.
  • could be in system for recording processes.
  • or could be in email sent manually

Organisations

An Organisation-as-Member has the following:

• should have an account, can login, set & remove O-Admins.
• includes a log of events, identified by O-Admins.
• organisation account itself is incapable of doing things itself so the O-Admin must do it for logging / purposes.
• Organisation is a Member
  • May have an account?
  • Cannot do an Assurance, cannot be assured under AP, cannot be an Assurer
  • Is an Org a group or an Account?????
  • Org account always belongs in Group of O-Admins
• Org is a "profile" of information,
  • Org IS NOT an Account.
  • Org may have an account, that can be delegated the control of the profile.
    • (must be blocked from individual assurance process)
  • All Members have access to one Profile: "the CAcert Community Profile"
  • Orgs cannot go to jails, they cannot be "Member accounts"
• A profile has rights:
  • Usage: create a certificate
  • View: look at logs
  • Manage: set the fields (corporate name)
• A Profile contains:
  • The Name -- corporate name as assured by Org Assurer
    • A single department field, optional.
    • or a set of names, no rules.
  • relationships:
    • the Org Assurer who has as management,
    • the O-Admins who can use it, others who can view it.
• Org Assurer manages Org Profiles.
  • create, modify and delete
  • delegate "usage" to an O-Admin for certs
  • delegate "management" including to an Org Account
  • delegate "view" to the Org Account, and CEO account.
• Profiles are distinct lists
  • there are no subsets in current design

Org Admins

• sign into their account
• switch into the organisation context
• maybe every Member has a single organisation context
  • with "CAcert Community" as the org.
  • access to community.cacert.org domain
  • or, every Assurer, because this is same requirement as O-Admin.
• Org-Admins have access to 1++ orgs, may be many.

Org Assurers

• Board can set and remove an Org-Assurer

Others related to Organisations

• Nonas-within-Orgs-with-certs
  • no relationship with them, no interface provided
• Members-within-Orgs
  • add an option to PD's account to add the company line
  • maybe also for code-signing
• O-Admin can add a code-signing
  • Code-signing should be a line in the CPS.
  • Anyone can ask for it.

Special and Powerful Roles on the Inside

Support Wing includes Arbitrators, Support Engineer, and Case Manager. Although all these people are Members, they are also "inside" the CA and are powerful. in special ways.

Arbitrator

Justine is an experienced Assurer (so he can do everything Bob can do) who was appointed as Arbitrator for a given case.

Sometimes this one is known as Trent for the Trusted Third Party. However, this is normally expected to be the CA itself, so it is confusing. We should probably choose a persona to do resolution of disputes. RODney?

The Token system

The token system is an interface to request information from whoever has that inf* Arbitrator has no access to the account, just a cut&paste of the data.

Getting the info; Has to get the information from somewhere could be support, could be one support person only pass authorisation to the person, cannot see it by self

Principle:

Arbitrator can order anything ... but must not get access.

• Arbitrator requests Case Manager from the Support team.
  • CM is enabled to see the data.
  • Case Manager can see the data
  • Arb passes token to CM, CM passes the data back to Arb.
  • At end of dispute, CM is revoked.

• Token access is logged.
• Arb can see what the token allows.
• Tokens
  • get, display, do.
• Internal messaging system for sending the token?
  • Optional extra.

Off-system:

The Arbitrator is presented with a decision to make (asked a question).

• collecting facts, evidence
• read only view of the participants, claimant and respondent
• acquired by 4 eyes
• make a decision, determine ruling, results
  Arbitration is a Black box, the things happening inside are opaque to outsiders, delivered in the Ruling.

He needs:

• Present an interface on how to ask the question.
  • is this "file a dispute" ?
• Arbitrator needs a way to publish the ruling/results/outcome
  • (to cause further actions)
• Write a case file.
  • wiki is not uncontrolled enough.
  • need a case management system:
  • start, follow through, control the publication of info.
  • not part of the core services.
• see information about disputes (will be off-system)
  • see the summary of the closed disputes.
  • see the disputes without an Arbitrator appointed.
  • see the disputes to which he has been appointed as arbitrator.
  • see the disputes he was Arbitrator or he has been authorized to see.

Case Manager

• is a "temporary" support role.
  • Support allocates the role for support.
  • Maybe a list of Case Managers.
  • Attached to a case just like an Arbitrator.
• The CMs are support roles?
  • The Arb and CM cannot be the same person on a given case.
• CM is a superset of support.
  • CMs are background checked.

Support / Stephan and Stephanie

Stephanie works for CAcert.org as Support Engineer.

• provide the dual control over Alice to change her password (according to various systems)
• do queries on system related to disputes - Arbitration
  • see the details (names, DoB, points, assurances received and assurances made) for the members he has been authorized to see.
  • request access to the details of an account.
  • view the logs?
  • interface with Arbitrators
  • act as Case Manager
  • act on the rulings (as Plod)
• facilitate special requests to access the data?
• needs a token to do these actions

Support has capability to do a lot of stuff. Support needs an authorisation for each action, called an Authorisation Token. Hence the Principle:

Every support action should be authorised by a token.

Perhaps call this as an Action Authorising Token... AAT

This follows from another Principle:

There is no direct database query access provided to anyone.

• Any Assurer can be support?
• Need an issue tracker system, outside scope.
• Need a set of buttons/switches to set roles, etc.
  • Need a set roles which identify the buttons which are switched on.
  • Some type of ACL.
• Assurances:
  • add a negative assurance
  • add a positive assurance (outside AP)
• Search
  • for email addresses
  • domains
  • Names
• Change Names:
  • One way is to add names, member can do that.

Sysadm - The Ultimate Override

The sysadm has to do the stuff that is too hard / emergencies. There is no defined method for this in the system. It is simply recorded here as the place where s**t gets cleaned up.

Miscellaneous

Statistics

There is a need for statistics on a group / person basis

• (add a list of stats pages with control mechanism)