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:

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: