title

teaching

exercises

questions

objectives

keypoints

The COPerson Object

Question here

List the objectives

List the key takeaways for the episode

1. The CO Person

People are represented in COmanage by a CO Person⚙️ object. Some information is stored in this object, and it is connected to several other types of useful objects.

The attributes (information) stored in the CO Person⚙️ object typically includes

The virtual organization or collaboration of which the person is a part (in the form of an identifier sort of, but it's really in the form of a CO Person Role)
The person's status within that organization or collaboration
Minimal information about the person including the person's (preferred time zone is really a technical thing, time zone is ordinarily automatically determined) date of birth, list of physical addresses.
List of names
List of identifiers
List of email addresses
(list of physical addresses duplicate)

This object also is connected to several other structural items that we will talk about in this lesson, including

External Representations - representations of the person in other contexts outside of COmanage (including real life!) These representations include attributes and information about the person related to the other context. Each CO Person⚙️ must have at least one of these, though multiple are allowed.
Roles - the roles that the person assumes within your organization.
Group Memberships - membership in a specific COmanage organizational object called a :gear" CO Group. We will learn more about :gear" CO Groups in a later lesson.
Authenticators - methods for the person to sign into services

CO Person status

Each CO Person⚙️ object has a status attached to it. This status is a calculated value based on the person's status in each of the Roles that the person has assumed in your organization or collaboration. We will review the calculation method when we talk about Roles. Status can be changed manually, or can change automatically based on conditions that you may set, or by workflows that you put in place.

The status value will affect what someone is able to do, including affecting what information is shared with external systems for access and resource provisioning. We will review how status affects provisioning when we talk about provisioning in a later lesson.

Below is a table of the available statuses < NOTE: This list should be simplified somehow - some of these statuses aren't really used for CO person, but are interim status during the enrollment flow - should include only the 'stable' status that a CO Person remains in for longer durations. For the others, we can allude to them, and explain them more fully where they are actually used. >

I think you can focus on Active/GracePeriod/Suspended/Expired

Preference	Status	Description
1	Active	Person or Role is an active member of the organization or collaboration
2	GracePeriod	Primary association with the organization has ended, but services have not yet been deprovisioned
3	Suspended	Association with the organization has been (manually) temporarily suspended
4	Expired	Valid through date has been reached
5	Approved
6	PendingApproval	The enrollment flow petition is pending approval
7	Confirmed
8	PendingConfirmation	An invitation or email confirmation was sent via an enrollment flow
9	Invited	An invitation was sent via default enrollment
10	Pending
11	Denied	The enrollment flow petition was denied
12	Declined	The invitation sent via default enrollment was declined
13	Deleted
14	Duplicate	The record is a duplicate of another

About name attributes

Each CO Person⚙️ object must include the person's name. CO Person⚙️ objects can have more than one name, but exactly one of the names must be designated as the primary name. Names can be encoded in any one of several languages / character sets.

About identifier attributes

< NOTE: Laura wrote this section, but isn't sure about her understanding of identifiers for CO Person. From the documentation it sounds like the recommendation is to have one CO Person identifier that is auto assigned, and for this identifier to be used for provisioning to at least some kinds of services rather than tying that provisioning to an org identity (like eppn) that may change if affiliation does. BUT... this may be totally wrong. >

The ultimate goal of identifiers is to faciliate application integration. Scott has a good document on this in the wiki.

Identifiers allow for unique identification. In COmanage, each CO Person⚙️ may be associated with [an?] identifier[s?]. [These identifiers | The identifier] can be important when provisioning services to CO Persons⚙️.

We recommend that you configure at least one identifier for each CO Person⚙️ to represent the person within COmanage. While it is possible to manually assign identifiers, we suggest that you allow COmanage to automatically assign these identifiers. You are able to configure what these identifiers will look like.

About email address attributes

COmanage can track email addresses, though it does very little with them directly (well we now have email list support, and we send notifications to them, but often they're provisioned - perhaps via LDAP - to downstream applications). Email addresses can be verified from within COmanage (which we will not review during this workshop). Email addresses can also be used for mailing lists using the mailman provisioner (which we will review, time allowing.)

When storing email addresses, more than one can be associated with the CO Person⚙️, and can contain a type to help distinguish the conditions under which to use each. For example,

official - the address to render in a directory entry, especially for use in a "To:" or "Cc:" field. LDAP attribute: mail
personal - Alternate addresses to accept for mail delivery or forwarding. LDAP attribute: mailAlternateAddress
delivery - the delivery location (e.g., mailbox). LDAP attribute: mailForwardingAddress
forwarding - Address to forward mail to, perhaps if there is no delivery address, or an official or personal address is not functioning. LDAP attribute: mailForwardingAddress

About physical address attributes

This information is not used by COmanage, but since it is handy (eg: to provision to your organization's directory) to have physical address information in your registry, it is included. Any number of physical addresses may be associated with a :gear" CO Person object.

Hands on - Starting our person model

As we build our understanding of how people are modeled in COmanage, we will use people in your organization as examples. In your printed packet, there are sheets for Modeling People 📝.

Think of at least three people in your organization that you can use as examples. The three that you choose should assume different roles in your organization or collaboration. Maybe they have different levels of authority, have access to different kinds of systems or services, form and manage their own groups. One of the people you choose may even work for a different organization, though collaborates with individuals in your organization.

Once you have thought about who you will use as your examples, write their names (or an alias!) on the sheets, one name per sheet. The name goes in the center circle that is labeled "CO Person".

[10 min]

Terminology & resources

COmanage Objects ⚙️

OBJECT	DESCRIPTION
`CO Person`⚙️	the representation of a person in COmanage
`CO Group`⚙️	a specific COmanage organizational structure for representing certain collections of `CO Persons`⚙️

Worksheets

WORKSHEET	DESCRIPTION
Modeling People 📝	Planning sheet used in this lesson for understanding how to model people in COmanage. This sheet is used to organize how specific people and their relationships would be expressed within COmanage

Slides

To be included

NEXT SECTION: 2. The OrgIdentity Object

LESSON OVERVIEW: CO310 - Modeling People in COmanage

WORKSHOP OVERVIEW: COmanage Workshop: Managing Identities & Collaborations

COmg-CO310-modelPeople/_episodes/01-COperson.md