PIV Card Request and Lifecycle Management Use Cases

The following sections describe common use cases for PIV Personal Identity Verification (technical standard of "HSPD-12") cards.

Use Case: Card Production Request

The following use case describes a typical IDPRS interaction with ActivID CMS to submit a Card Production Request (CPR) for the purpose of issuance. The actor involved is the IDPRS. This use case applies to both issuance models. A CPR is submitted when the issuance occurs in person or at an external card production The process of producing a full or partially personalized card that results in the card being bound to a cardholder and put into a locked state. facility.

System Components

The system in this use case consists of:

• The ActivID CMS Card and Credential Management (CCM) Service and CCM API integrated by the IDPRS

• The ActivID CMS enrollment plug-in that handles the CPR.

• The PIV Personal Identity Verification (technical standard of "HSPD-12") repository that stores the CPR.

Basic Flow of Events

Basic Flow of Events for Card Production Requests

Alternate Flows

• User already exists:

  Creation of user is optional depending on whether the IDPRS is managing user creation in the ActivID CMS user repository or ActivID CMS is using an existing corporate directory with existing users.

• CPR already exists:

  In cases where a CPR already exists for a user, the system deletes the existing user attributes from the repository and replaces them with the newly received ones.

• Issuance request already exists:

  In cases where an issuance request already exists, the system returns an exception and a message to the IDPRS. The IDPRS is responsible for deleting the existing issuance request and submitting a new one.

• Invalid CPR:

  In cases where the CPR signature cannot be verified or the CPR cannot be stored in the repository, the system returns an exception and a message to the IDPRS. The IDPRS is responsible for deleting the invalid CPR and submitting a new one.

• PIV Card Renewal:

  In case of a card renewal, the flow is as follows:

  • IDMS A collection of systems, processes, procedures, applications, database management systems, and interfaces that work together to manage and protect the identity information of PIV card applicants. The IDMS generally falls within the IDPRS domain. submits a CPR and an unapproved action with PRODUCE/EXPIRED state.

  • ActivID BMS denies the unapproved action.

  • ActivID BMS exports an SBOD containing the action.

  • Service Bureau prints a card for the action.

  • ActivID BMS imports an SBDD containing the information on the card for the action.

  • ActivID BMS cancels the original denied action.

  • ActivID BMS binds the new card to the user.

  • ActivID BMS submits a new action with an approved PRODUCE/EXPIRED state.

  • ActivID CMS Operator Portal is used to activate/synchronize the card.

  • The termination of the initial card and its credentials occurs during the new card’s synchronization. The initial card is fully active until then.

Use Case: Card Revocation/Suspension/Resumption

In this use case, the IDPRS is responsible for card revocation submission to the system. This use case accommodates logical termination of the card in case, for example, when immediate termination of a card/cardholder is required or a cardholder reports a PIV Personal Identity Verification (technical standard of "HSPD-12") card lost, stolen, or damaged.

This use case is also applicable to card suspension and card resumption.

System Components

The system in this use case consists of:

• The ActivID CMS CCM Service and CCM API integrated by the IDPRS.

• ActivID CMS Notification plug-in to that notifies the IDPRS.

Basic Flow of Events

Basic Flow of Events for Card Revocation/Suspension/Resumption