Credential Issuance Use Case

From IDESG Wiki
Revision as of 03:51, 28 June 2018 by Omaerz (talk | contribs) (22 revisions imported: Initial Upload of old pages from IDESG Wiki)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Template:Comment

Use Case Metadata

Title

Credential Issuance

Status

Use Case Lifecycle Status

Contributed Working Draft Committee Review Compilation Approval Publication
This use case has been approved in version 1.2. This page may have been updated since the 1.2 document was approved.

Use Case Category

Identity Management

Contributor

Standards Committee Use Cases Ad Hoc Group

Use Case Content

Use Case Description

The use case pertains to the issuance of a credential during the registration process, after identity proofing has optionally occurred.

Below are some non-normative examples of issuance of particular forms of authentication factors for credentials.

Example: Linux passwords

On Linux systems passwords are selected by the Claimant and a hash of the password is recorded in /etc/passwd associated with the Claimant’s username.

Example: Asymmetric Crypto

Asymmetric cryptography with user-generated keys allows the CSP to record the public key of the Claimant without having knowledge of the associate private key. In a PKI model, the CSP can issue X.509 certificates that associate the public key with the Claimant’s unique identifier; alternatively in a non-PKI model, the CSP can record the Claimant’s public keys in a trusted identity store associated with the Claimant’s unique identifiers.

Example: On Time Password to Mobile Phone

Authentication tokens based on sending One Time Passwords (OTP) to a mobile device, so credentials might consist of mobile phone numbers associated with the Claimant’s unique identifier.

Actors

  • Entity (a Person or Non-Person Entity) has enrolled for credentials from Credential Service Provider
  • Credential Service Provider has the goal of issuing credentials to Entity.
  • Registration Authority provides verified information about an entity so as to issue credentials.
  • Applicant or Sponsor presents verifiable information about the entity in order to obtain credentials.

Assumptions

  • The Registration Authority can provide verified identity attributes for the Entity.

Process Flow

  1. In the case of credential issuance to a Person, the Claimant is the Person to whom credentials are being issued. In the case of credential issuance to the Non Person Entity (NPE), the Claimant is the NPE and the Sponsor is the individual requesting credentials on behalf of the NPE. The process flow sometimes refers to “Claimant/Sponsor”, this indicates the human in the process.
  2. Credentials consist of one or more authentication factors linked to the Claimant’s unique identifier.
  3. During the credential issuance process, each authentication factor must be collected or generated and recorded in such a way as to support subsequent authentication operations.
  4. When a sufficient number of authentication tokens have been generated and recorded, the Credential Issuance process is complete and the Applicant becomes a Subscriber.

NB. The credential issuance process may require publication of information.

Success Scenario

  • All authentication tokens are successfully generated although this may not be fully accepted as a successful outcome.

Error Conditions

  • An authentication token cannot be generated
  • Storage of authentication factor information fails.

Relationships

References and Citations

NIST Special Publication 800-63

NSTIC Guiding Principles Considerations

Privacy Considerations

User knowledge with regard to what information is carried with the credential and how that information is released should be communicated to the user. In addition, other considerations with regard to implementation should be explored to prevent correlation of user data among applicable parties to the transaction.

Security Considerations

User Experience/Usability Considerations

Interoperability Considerations

Domain Expert Working Group Considerations

Financial

Health Care

Derived Requirements