ATTACHMENT_G_-_SIP_Interface_Document_v3.11.2_-_Amendment_2.docx

DRAFT

USAccess Authoritative User Data Interface Design Version 3.11 March 8, 2016

CM# GSA-DI-00000152-3.10.0

Use or disclosure of data contained on this sheet is subject to the restrictions on the cover page of this document.

CM # GSA-DI-00000818-1.0.0

ii

The information contained in this document is sensitive and may not be transmitted or disclosed to anyone outside of the Government or authorized representatives without written permission from the GSA Managed Service Office.

Revision Chart Version

1.0

1.1

Updates for added fields, corrections Added appendix for Reference Data 08/23/2007

1.2

2.0

Major update through version X

2.1

2.2

Add Card Pick Up Location Home Address optional for sponsorship CitizenshipCountryCode not required for record creation 06/23/2009

2.3

2.4

2.5

Added fields (PII-heavy) to the data structures Expanded service methods Updated information for side-by-side release 10/07/2010

2.6

Synchronize fields and validations with the USAccess Portal Preserve case for email addresses and UPN PersonalInformation, SponsorshipInformation and AdjudicationInformation structures have been modified 07/08/2011

2.7

2.8

2.9

Add AgencySpecialUse to the SponsorshipInformation data structure;

Add a method to retrieve AgencySpecialUse codes through ReferenceDataService interface.

Add data structure CreateUpdateOptions;

Add method QueryApplicantExists;

Modify CreateNewEmployeeContractor and UpdateEmployeeContractor to accept CreateUpdateOptions – this is to request a Full Term Card on Sponsorship completion.

01/31/2012

3.0

3.1

Add Issuance Validation Results to the StatusInformation data structure.

Add method RequestEftsSubmission to allow agencies to request EFTS submission to OPM.

06/15/2012

3.2

3.3

Add support for Agency Specific Criteria:

Add data fields to the bulk import file format Add data fields in the AdjudicationInformation and StatusInformation data structures Altered business rules for Adjudication 02/22/2013

3.4

Add methods and data structures to interact with the Card Action workflow Add methods to perform credential operations: Terminate, Suspend and Reactivate Add method to request a DNSync 06/30/2013

3.5

Add attributes to the ShippingAddress data structure Alter email validation to exclude terminated sponsorship records. (NOT A PUBLISHED VERSION) 02/10/2014

3.6

Add PrintMode attribute to the SponsorshipInformation data structure Add CardUuid attribute to the CredentialInformation data structure.

Changed TEDSID to EMPLID.

08/31/2014

3.7

Add NFIQ scores for fingerprints captured to the FingerprintInformation structure Add QueryList parameter to toggle PhotographInformation images from JPG to INCITS385 Added BFO and BFD as Issuance and Replacement Status.

01/23/2015

3.8

Add the SponsorshipInformation data field CredentialOption to the web service interface.

Leave PIVCardRequiredCode field for backwards compatibility and map it to the CredentialOption field in the Bulk Import file format.

09/03/2015

3.9

Removed the v2.5 instance (SIPWebServiceV2).

Alter RequestEftsSubmission to add requesting agency and requester PID; return TCN Add EftsRequestStatus to StatusInformation Add CredentialCheckInStatus to StatusInformation Add System roles (CREDENTIAL INVENTORY TOOL OPERATOR, PIV REGISTRAR, PRINT OPERATOR) to role holder information Deprecate the InPossession flag on Card Action methods (QueryCardActionState, RequestCardAction) 10/26/2015

3.10

Authoritative User Data Interface Design

Table of Contents

Figures Figure 1: Batch Import Screen 11

Tables

Introduction Homeland Security Presidential Directive 12 (HSPD-12), “Policy for a Common Identification Standard for Federal Employees and Contractors,” established the requirement for a mandatory, Government-wide standard for secure and reliable forms of identification issued by the Federal Government to its employees and contractor employees assigned to Government contracts in order to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy. As a result, the National Institute of Standards and Technology (NIST) released “Federal Information Processing Standard (FIPS) 201: Personal Identity Verification (PIV) of Federal Employees and Contractors”. FIPS establishes the requirements and business processes for the development of PIV contact/contact-less smart cards.

Purpose The purpose of this document is to identify optional methods and interfaces developed within the USAccess system for agencies to create, update, and query sponsorship and adjudication data. This document also identifies Web services developed for agencies to manually input Applicant data or to import bulk data records related to sponsorship and adjudication functions.

Scope Web service operations for agencies (AgencyService) have been developed for the USAccess system and are described in detail for the following sponsorship and adjudication functions:

· Create a new employee or contractor data record (CreateNewEmployeeContractor).

· Update an employee or contractor data record (UpdateEmployeeContractor).

· Query an existing employee or contractor information (QuerySIP, QueryCredentialStatus).

· Query for a list of modified Applicants (QueryModifiedList).

The USAccess system also allows agencies to import multiple sponsorship and adjudication records in a single request via the Security Officer portal. This functionality, available only to the Security Officer, is described in this document.

System Overview The USAccess system offers agencies three methods for creating, updating, and querying sponsorship and adjudication data.

An agency Sponsor may choose to manually enter the application information via the Assured Identity Sponsorship portal and an Adjudicator may also enter the adjudication information via the Assured Identity Adjudication portal.

The agency may choose to use bulk import existing data (create only).

The agency may choose to use Web service operations offered by the USAccess system.

The USAccess system exposes methods from the AgencyService Web service:

1. CreateNewEmployeeContractor UpdateEmployeeContractor QuerySIP QueryCredentialStatus QueryModifiedList These methods may be used by the agency to import single application records into the USAccess identity management system (IDMS).

In addition, USAccess permits the agency Security Officer to bulk import sponsorship and adjudication records via the Security Officer interface.

Business Rules Business Rules for Data Validation Data values provided in a request affect the process state of the Applicant and the following business rules are applied.

Applicant Record Uniqueness The following fields uniquely identify an Applicant record. An attempt to create a sponsorship with the same values indicates a new sponsorship for an existing Applicant.

· LastName

· DateOfBirth

· SSN or ForeignID Minimum Required Data A minimum set of data is required to create a record in the system, without which the request is rejected. The minimum set of data required to create a record is:

· SponsorOrganizationalIdentifier

· FirstName

· LastName

· DateOfBirth

· SSN or ForeignID Data Required for Complete Sponsorship A complete sponsorship record is required to allow an Applicant to enroll or, if the Applicant is already enrolled, to allow the credential issuance for the sponsorship to proceed. The following set of data is required for a complete sponsorship:

· Minimum Required Data fields (above)

· CitizenshipCountryCode

· Employment Status

· PersonOrganizationAssociationCategory

· SponsorPID

· DateofSponsorship

· PIVCardRequiredCode

· PIVCardType

· CardShipAddressCode Data Required for Adjudication To record the National Agency Check (NAC) (NCHC/FBI) results or the NAC with Inquiries (NACI) results, the minimum information required is the AdjudicationValue, AdjudicationEffectiveDate, and AdjudicatorPID. For issuance to commence, at least an approved NAC value is required. If a NACI value is provided and a NAC value does not exist, the NAC value is populated using the NACI value.

· NACAdjudicationValue

· NACAdjudicationEffectiveDate

· NACAdjudicatorPID Additionally, if the agency has opted in to use the Agency Specific Criteria, the AgencySpecificCriteria structure must be populated and the AgencyStatusCode must be set to Approved for issuance to commence.

· AgencyStatusCode

· AgencyStatusDate Data Required for Issuance For the issuance of the Applicant’s credential to be processed, the following data must be complete:

· Data Required for Complete Sponsorship

· Data Required for Adjudication

· Applicant must have enrolled

· PIVCardRequired must be TRUE

· WorkEmail (or the PIVCertificateSet must be set to 9)

· UPN

· CardShipAddressCode must be valid and within the availability window (see Specifying a Card Shipping Address Code) Data Required for OPM Submission For the Applicant data to be submitted through the USAccess system to OPM for the background investigation the following data must be complete:

· Data Required for Complete Sponsorship

· Applicant must have enrolled

· Birth City, Birth State Code (if applicable), Birth Country Code

· SON, SOI and OPAC codes Specifying Citizenship The IsUSCitizen flag and the CitizenshipCountryCode are validated together. If the IsUSCitizen is TRUE, the CitizenshipCountryCode must be ‘US’ – it defaults to ‘US’ if one is not supplied. If the IsUSCitizen value is FALSE, CitizenshipCountryCode must not be ‘US’.

Additionally, if the SSN is not specified, the CitizenshipCountryCode must not be ‘US’.

Any non-US CitizenshipCountryCode results in a BLUE color name bar on the Applicant PIV credential.

Specifying a Card Shipping Address Code A Shipping site in USAccess is configured with a begin date and end date. The site is available for assignment if the request date is on or after the begin date and the request date is at least 21 days prior to the end date.

If the request date falls outside the begin-date and end-date window, the system returns a validation message that indicates that the specified site is inactive. The CardShipAddressCode is then set to null.

If the request date falls within the begin-date and end-date window but is less than 21 days from the end-date, the system returns a validation message that indicates that the specified site is not available. The CardShipAddressCode is then set to null.

Business Rules for Data Updates Creating a Sponsorship for an Existing Applicant An Applicant record may exist in the system without a Sponsorship in the requesting agency. When this occurs the request only creates a sponsorship (if one does not already exist) and does not modify any Applicant data.

Updating an Existing Applicant The UpdateEmployeeContractor service method must be used to update an existing Applicant or sponsorship record.

If the Applicant is in the issuance process for any sponsorship – i.e. a credential is being produced – the Applicant data cannot be modified and the request is rejected.

If the Applicant is in the issuance process for the sponsorship being updated the request is rejected.

Partial Updates In an update request not all values need to be provided. If the value of the field is left null – i.e. no value provided (distinct from the string null and an empty string) – the existing value of the corresponding field in the system is left unchanged.

If an empty string is passed as input, the existing value is removed (or replaced with any default value as defined).

Updating the Birth Date The birth date of an Applicant can be modified. If the modification to the birth date causes a conflict with an existing Applicant with the same Last Name, SSN, and Birth Date a validation message is returned indicating that a unique key would be violated. The BirthDate remains unchanged.

Updates for SSN or ForeignID The SSN or ForeignID fields of an Applicant can be modified. If the modification to the SSN causes a conflict with an existing Applicant with the same Last Name, SSN, and Birth Date a validation message is returned indicating that a unique key would be violated. The SSN remains unchanged. If the SSN is in use by another record (but does not violate the unique key) a warning message is returned. If the modification to the ForeignID causes a conflict with an existing Applicant with the same Last Name, ForeignID, and Birth Date a validation message is returned indicating that a unique key would be violated. The ForeignID remains unchanged. If the ForeignID is in use by another record (but does not violate the unique key) a warning message is returned.

Business Rules for Card Actions The process to request a new card or a biometric update is to submit a request for a card action. Each card action request requires the reason to be specified.

Depending on the state of the Applicant issuance and sponsorship record the set of available reasons for a card action changes. A request made with an incompatible reason code is rejected.

Additionally, each reason enforces a minimum card action. The minimum action is driven by the business rules for the reason and the rules for any outstanding data changes on the Applicant’s record.

The request can specify the minimum card action or ‘upgrade’ the request to one of the higher card actions.

Card Action State Information To identify the card action reasons that are available, a call to request the card action state for the Applicant should be made prior to the call to request a card action.

The card action state response contains details on any pending card action, the set of available card action reasons and their corresponding minimum actions along with details of any pending data changes.

Sponsorship Record State for Card Actions Before a card action can be requested for an Applicant, the record should be Sponsorship-complete, the Applicant should have completed enrollment and must have an Active or Future employment status.

Card Actions for Renewals The Renewal card action reason is only available when the current credential is within the card renewal window (this is at present defined as one year prior to the Card Expiry Date.)

Pending Card Actions There can be only one pending card action for an Applicant. Before a new card action can be requested any pending card action must first be cancelled.

Card Actions for Lost or Stolen Reasons If a card action request is submitted with a Lost or Stolen reason and the current credential has not already been terminated, the credential is terminated as soon as the request is created.

Business Rules for Credential Operations The credential operation methods provide a means to programmatically terminate, suspend or reactivate an Applicant’s credential without altering the Applicant’s employment status.

Terminate Credential A request to terminate a credential requires the caller to specify the termination reason code. The selected reason affects the business rules that are applied for the next card action.

Suspend Credential A request to suspend a credential requires the caller to specify the suspension reason code. A suspended credential can be reactivated at a later time.

Reactivate Credential A request to reactivate a credential requires the Applicant’s credential to be in a suspended state. Additionally, the Applicant’s employment status must be Active.

Data Types and Formats The data fields, for which values can be provided, are organized into the following categories:

· Person Identifier

· Personal Information

· Sponsorship Information

· Adjudication Information Input Data Values String Most of the input values to the system are strings. The exceptions are Date values and Boolean values which are special strings. Strings can have the following values:

· A non-empty string

· An empty string (indicates that the default, as specified, to be used)

· No value provided (null: in a create request is treated as an empty string; in an update it indicates that the existing value be left unchanged) Leading and trailing spaces in string values are removed.

Boolean Boolean values must have one of the following values:

· TRUE

· FALSE

· An empty string (indicates that the default as specified to be used)

· No value provided (null: only in an update indicating that the existing value be left unchanged) Date All date values must be in the following format in a bulk import file:

· YYYY-MM-DD

Date values in the Web Service must be in the DateTime format. A null date is specified by sending a value of 0001-01-01; in a create request, this indicates that no value is supplied and in an update that the existing value be left unchanged.

In an update, to reset an existing date field to null, send in a value of 9999-12-31 (Next Card Expire Date field only).

Field Format Restrictions Certain data fields only accept values according to particular formats. These field format definitions are described below.

Names All name fields accept only the following characters:

· Letters A through Z

· Hyphen (-)

· Single-quote (‘)

· Period (.)

· Space ( ) Values are converted to upper case when stored.

The fields enforcing this validation:

· PersonalInformation: FirstName, MiddleName, LastName Email Addresses All email addresses must comply with the email address format as defined in the standard (IETF RFC 5321 and RFC 5322). The length of email addresses in the system is restricted to 70 characters.

Email addresses are stored in the case provided by the user; however lookups and uniqueness checks perform a case-insensitive comparison.

UPNs All UPNs must comply with the email address format as defined in the standard (IETF RFC5321 and RFC 5322). The length of UPNs in the system is restricted to 100 characters.

UPNs are stored in the case provided by the user; however lookups and uniqueness checks perform a case-insensitive comparison.

Address Lines All address line fields accept only the following characters:

· Letters A through Z

· Numerals 0 through 9

· Hyphen (-)

· Single-quote (‘)

· Period (.)

· Comma (,)

· Space ( ) Values are converted to upper case when stored.

The fields enforcing this validation:

· PersonalInformation: HomeAddressLine1, HomeAddressLine2, HomeAddressLine3 Agency-Specific Codes Some of the data fields require the use of agency-specific codes. The list of codes that can be used is available in the Bulk Import Information Report through the USAccess Reports Interface.

The codes are also available through the Reference Data Service. For details of the fields available through this service see Appendix R – Reference Data Service.

Web Service Operations The Agency Service is based on the Architecture Working Group (AWG) Agency-SIP service specification. Details of the methods exposed are covered in this section.

The web service operations are available over two service endpoints. The web service conforms to the OASIS WS-Security standard and requires the use of message encryption over a mutually authenticated HTTPS channel.

This version of the SIP web service is being made available on the following URLs:

https://wsgsa.usaccess.gsa.gov/SIPWebService2015/AgencyService.svc https://wsgsa.usaccess.gsa.gov/SIPWebService2015/ReferenceDataService.svc CreateNewEmployeeContractor The CreateNewEmployeeContractor web service operation allows agencies to create sponsorship data for a new employee or contractor. See Appendix B – Create New Employee Contractor Parameters.

At a minimum, the following data elements must be provided for a sponsorship record to be created:

· SponsorOrganizationalIdentifier

· FirstName

· LastName

· DateOfBirth

· SSN or ForeignID If other data elements required in the business rules are missing or invalid, default values are used instead, the transaction status is set to ‘Success – Conditional’, and details on the invalid or missing elements are returned in the status message. If values for all the fields required for sponsorship have not been provided, the sponsorship record is marked as Incomplete.

If sponsorship is complete and the Applicant has not already enrolled, the Applicant is notified to proceed to enrollment. If enrollment is complete and all other requirements for credential issuance are met, the production of the card commences.

UpdateEmployeeContractor The UpdateEmployeeContractor web service operation allows agencies to update existing sponsorship data for an employee or contractor. See Appendix C – Update Employee Contractor Parameters.

At a minimum, the following data elements must be provided for a sponsorship to be updated:

· SponsorOrganizationalIdentifier

· PersonID

Values not provided (the XML tag for the element is not in the request) indicate that the existing values on the record are to be left unchanged.

If other data elements marked as required in the business rules are missing or invalid, default values are used instead, the transaction status is set to ‘Success – Conditional’, and details on the invalid or missing elements are passed in the status message. The sponsorship record is marked as Incomplete and requires the Sponsor to use the Sponsorship Interface to complete the sponsorship.

QuerySIP The QuerySIP web service operation allows agencies to query existing employee and contractor information. See Appendix D – QuerySIP Parameters.

QueryCredentialStatus The QueryCredentialStatus web service operation allows agencies to query existing employee and contractor credential status information. See Appendix E - QueryCredentialStatus Parameters.

QueryCredentialStatusByCardNumber The QueryCredentialStatusByCardNumber web service operation allows agencies to query existing employee and contractor credential status information. See Appendix F – QueryCredentialStatusByCardNumber Parameters.

QueryModifiedList The QueryModifiedList web service operation allows agencies to retrieve a list of any Applicants sponsored by that agency and whose data has been modified in the time range specified. The results are returned for the agency code provided. If an agency is configured to use sub-agencies, each sub-agency must be queried separately. See Appendix G – QueryModifiedList Parameters.

QueryRoleholders The QueryRoleholders web service operation allows agencies to retrieve the list of role-holders configured in the system. If an agency is configured to use sub-agencies, each sub-agency must be queried separately. See Appendix H – QueryRoleholders Parameters.

QueryApplicantExists The QueryApplicantExists web service operation allows agencies to check if an Applicant already exists in the system and if that Applicant has already enrolled. See Appendix I – QueryApplicantExists Parameters.

RequestEftsSubmission The RequestEftsSubmission web service operation allows agencies to make an EFTS submission request. If the Applicant has enrolled and meets the business requirements a request for EFTS submission to OPM is queued. See Appendix J – RequestEftsSubmission Parameters.

QueryCardActionState The QueryCardActionState web service operation provides details on any pending card action, the set of available card action reasons and their corresponding minimum actions. It also returns a list of any pending data changes on the Applicant’s record. See Appendix K – QueryCardActionState Parameters.

RequestCardAction The RequestCardAction web service operation allows agencies to request a new card action for an Applicant. See Appendix L – RequestCardAction Parameters.

CancelCardAction The CancelCardAction web service operation allows agencies to cancel an existing card action for an Applicant. See Appendix M – CancelCardAction Parameters.

TerminateIssuance The TerminateIssuance web service operation allows agencies to terminate an Applicant’s credential. This is an operation that only affects the credential and not the Applicant’s employment status. See Appendix N – TerminateIssuance Parameters.

SuspendIssuance The SuspendIssuance web service operation allows agencies to suspend an Applicant’s credential. This is an operation that only affects the credential and not the Applicant’s employment status. See Appendix O – SuspendIssuance Parameters.

ReactivateIssuance The ReactivateIssuance web service operation allows agencies to reactivate an Applicant’s credential. This is an operation that only affects the credential and not the Applicant’s employment status. See Appendix P – ReactivateIssuance Parameters.

RequestDNSync The RequestDNSync web service operation allows agencies to populate the fully qualified distinguished name (FQDN) for an Applicant. This is an operation only for Applicants with a sponsorship in the Department of the Treasury. See Appendix Q – RequestDNSync Parameters.

Bulk Import The USAccess system allows agencies to import multiple sponsorship and adjudication records in a single request via the Security Officer Interface. This functionality is only available to the Security Officer.

There is a report available on the USAccess Report Interface called Bulk Upload Information. This should be referenced by the creator of the file prior to submitting to USAccess for data creation. Various codes used by USAccess and available within the scope of the Security Officer are listed in the Bulk Upload Information Report, including the site code (for shipment of the credential); SponsorPID (the sponsor of record for the Applicant) and NACAdjudicatorPersonID (the NAC adjudicator of record for the Applicant) can be found on this report. This information must be correctly provided or the record could be rejected outright (depending on the issue) or only partially loaded (requiring a Sponsor or Adjudicator to enter the Web interface and complete the missing data elements).

Figure 1: Batch Import Screen The validation used for Bulk Import is identical to the Web service operations described in this document. Table 1: Batch Import Page Fields lists the various functions of the bulk import process within the batch import Web service.

Table 1: Batch Import Page Fields

Bulk Import Confirmation Bulk import is an asynchronous process. Therefore, USAccess e-mails the Security Officer who performed the bulk import when the process has completed. This e-mail contains three attachments: (1) records successfully added to the IDMS, (2) records that failed to be added to the IDMS due to validation errors, and (3) records that were unreadable due to parsing errors.

The Batch Import Success attachment contains tab-delimited values: row ID, last name, first name, Person ID, Person Global User Identifier (GUID), success or warning, and message.

The Batch Import Failure attachment contains tab-delimited values: row ID, last name, first name, Person GUID, and failure reason.

The Batch Import Parsing Failure attachment contains tab-delimited values: row ID and parser error message.

IMPORTANT: Even if the import process reports that records were successfully imported, it is necessary to inspect the attachments for any warnings. It is possible for a record to be imported successfully with the minimum data although other invalid fields keep it from being sponsorship complete.

Bulk Import File Format Bulk Import supports both comma-delimited and tab-delimited files. If the file extension is .txt, the file must be tab-delimited. If the file extension is .csv, the file must be comma-delimited.

If the file extension is .xml, the file must be an XML file and conform to the bulk import schema defined in Appendix S – Bulk Import XML Schema.

The maximum number of records accepted per upload file is 5,000.

At a minimum, the following data elements must be provided for a sponsorship record to be created:

· SponsorOrganizationalIdentifier

· FirstName

· LastName

· DateOfBirth

· SSN

If other data elements marked as required are missing or invalid, default values are used instead, a sponsorship record is created, and details on the invalid or missing elements are passed in the status message. The sponsorship record is marked as Incomplete and requires the Sponsor to use the portal to complete the sponsorship.

Data updates cannot be executed through the bulk import process. Any changes to data that has already been imported must be modified manually through the portal or using the SIP Web Service.

The bulk import file format is described below.

Note: In the following table, conditional elements with a value of “C” indicate that business rules apply. Elements in bold represent the minimum required elements to create a sponsorship record.

Table 2: Bulk Import File Format

Optional/ Cond.

Data Type

Data Definition

Personal Information

SSN or ForeignID must be populated.

SSN or ForeignID must be populated. Format: First 3-characters must be one of the Document Type Codes below followed by 1 - 29 character document number Document Type Codes: ARR: Alien Registration Receipt Card (Form I -551) EAD: Employment Authorization Document with photo (I-766) FPI: Foreign passport with I-94 FPS: Foreign passport with I-551 stamp

Default: None

Default: US Length must be two characters (as per FIPS 10-4). Any non-US CitizenshipCountryCode results in a BLUE color name bar on the Applicant PIV cred.

Required for sponsorship

Person Identifier

Must be unique within the agency.

Sponsorship Information

S: Suspended T: Terminated F: Future Default: None Required for sponsorship

2: Civil 3: Executive Staff 4: Uniformed Service 5: Contractor 6: Associate Or Dignitary 7: Service Provider 8: Press Corps

Default: None Required for sponsorship [If CitizenshipCountryCode is not US, the PIV card has a BLUE color bar.

If the CitizenshipCountryCode is US, all values (other than Contractor) result in a WHITE color bar on the PIV card. A value of Contractor results in a GREEN color bar.]

Required for sponsorship

Internally mapped to the CredentialOption.

Required for issuance.

Must be unique in the system if Digital Signature and Encryption certificates are requested.

Default: None The combination of SON and SOI and OPAC must be valid

Must be unique in the system.

User specified value cannot end in @fedidcard.gov

Default: USG

Adjudication Information

· APPROVED or TRUE

· REJECTED or FALSE

Ignored

· APPROVED or TRUE

· REJECTED or FALSE

All three NACI values must be supplied together

9: Only PIV Auth and Card Auth certificates 15: All four certificates Default: 15 Required for Issuance if no work email is provided and issuance is required.

Ignored

Ignored

Default: FED-STD

USER: User specified UPN

FAUF: Federal Agency User Fee NFUF: Non-Federal User Fee

· APPROVED

· REJECTED

Required for Issuance if agency opts in to use Agency Specific Criteria and AgencySpecificCriteriaStatusCode is specified.

DPR: Distributed (Local) Printing Default: CPB DPR is only available if the sub-agency is configured for Local Printing.

Appendix A – Terms and Acronyms

Appendix B – Create New Employee Contractor Parameters The USAccess system exposes the Web service method CreateNewEmployeeContractor to enable the agency to import a single record into the IDMS. The table below represents the INPUT Parameters for the Web service.

NOTE: In the following table Required/Optional elements with a value of “R/O*” indicate that business rules apply (see section 2.1.1.3 Data Required for Complete Sponsorship for more information).

Table 3: Create New Employee Input Parameters

Data Elements Required/ Optional

Enumeration Values

Max Data Length

CreateNewEmployeeContractor

TRUE/FALSE

2: Civil 3: Executive Staff 4: Uniformed Service 5: Contractor 6: Associate or Dignitary 7: Service Provider 8: Press Corps Default: None

Default: TRUE, if the option is available to the agency. Otherwise, FALSE

TRUE/FALSE

PIV: PIV credential to be issued

Default: PIV, if the option is available to the agency. Otherwise, NONE

Default: FED-STD

<=10

USER: User specified UPN value

S: Suspended T: Terminated F: Future Default: None

<= 5 chars

<= 25 chars

<= 12 chars

15: All four certificates (Default) <= 2 chars

DPR: Distributed (Local) Printing Default: CPB

APPROVED (TRUE)

REJECTED (FALSE)

Default: PENDING

APPROVED (TRUE)

REJECTED (FALSE)

Default: PENDING

FAUF: Federal Agency User Fee NFUF: Non-Federal User Fee Default: None

APPROVED

REJECTED

The table below represents the OUTPUT Parameters for the Web service method.

Table 4: Create New Employee Output Parameters

Data Elements Required/ Optional

Enumeration Values

Max Data Length

CreateNewEmployeeContractorResponse

Appendix C – Update Employee Contractor Parameters The USAccess system exposes the Web service method UpdateEmployeeContractor to enable the agency to import a single record into the IDMS. The table below represents the INPUT Parameters for the Web service.

In the following table Required/Optional elements with a value of “R/O*” indicate that business rules apply (see Section 2.1.2.2 Update an Existing Applicant for more information).

Table 5: Update Employee Input Parameters

Data Elements Required/ Optional

Enumeration Values

Max Data Length

UpdateEmployeeContractor

TRUE/FALSE

2: Civil 3: Executive Staff 4: Uniformed Service 5: Contractor 6: Associate or Dignitary 7: Service Provider 8: Press Corps

TRUE/FALSE

Default: TRUE, if the option is available to the agency. Otherwise, FALSE

TRUE/FALSE

PIV: PIV credential to be issued

Default: PIV, if the option is available to the agency. Otherwise, NONE

TRUE/FALSE

<=10

USER: User specified UPN value

S: Suspended T: Terminated F:Future

<= 5 chars

<= 25 chars

<= 12 chars

15: All four certificates <= 2 chars

DPR: Distributed (Local) Printing Default: CPB