This use case introduces the concept of Non-Authenticating Participants (NAPs): those who wish to engage with a CO without authenticating (either due to lack of suitable credentials or lack of desire to use suitable credentials). A NAP will typically not utilize a CO's full set of services, but only those that can reasonably be used without authenticating, such as mailing lists.

NAPs are handled in much the same way as old listserv software: the use of tokens sent through email provides "good enough" authentication for specific actions. Admins can take actions on behalf of NAPs when this method is insufficient or inaccessible.

By enrolling NAPs through COmanage rather than directly through the mailing list software, it becomes easier to manage and report on these participants in the same way as "regular" Authenticating Participants (APs). For example, NAPs and APs can be members of the same group, allowing for easy visibility into memberships.

  1. A new enrollment flow is defined for NAPs.
    1. Authentication is not required.
    2. Approval should be required.
    3. Name and email address are required, other attributes may be required or optional.
    4. The group associated with the mailing list the NAP wishes to join is specified as a hidden or selectable attribute.
    5. An affiliation (perhaps an extended affiliation such as List-Only (CO-526)) is specified as a hidden attribute.
    6. It maybe desirable to place all NAPs in their own COU.
  2. The NAP enrollee completes the form, confirms their email address, and (upon approval) is added to the requested list.
  3. If the NAP wishes to join an additional list, the NAP completes an appropriate additional enrollment flow. COmanage will detect that the email address is already in use (CO-298) and add the NAP to the new group without creating a new person record.
  4. Unsubscription is handled via a non-authenticating controller or plugin, using an email token to confirm the action (NEW).
  • No labels