Page 1

This document offers Smart Card Alliance comments on the "Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance" document content and perspectives on the challenges in the next step of developing detailed Part B implementation guidance.

The Smart Card Alliance Identity Council and Physical Access Council have provided these comments on the FICAM document in support of the Identity, Credential and Access Management Steering Committee's (ICAMSC) efforts in finalizing Part B, Implementation Guidance. Comments range from privacy implications, unique identifier objects, and standards and certifications to authentication factors and assurance levels, with use case examples. Finally, comments relative to improving physical access control system (PACS) operational efficiency and ease of use are provided, along with recommendations for the development of a design reference model that would facilitate greater PACS interoperability.

1 Specific Comments on the "Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance" Document

The following are general comments on the full document, "Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance," and comments on specific document sections.

General Comment - Privacy

The FICAM roadmap for identity and credentialing requires changes to agency processes that collect and/or use personally identifiable information (PII). The FICAM implementation guidance addresses security and can address privacy concerns. However, the ICAMSC should consider and provide guidance on the privacy implications of the recommended target architecture and use cases. Privacy officers should be included in the development of implementation guidance.

General Comment - Unique Identifier and PACS

In order for interoperability with external users as depicted in the original FICAM document Section 3.2.5.2, "Target Conceptual Diagrams," Figure 13, "Federal Enterprise Target Conceptual Diagram, Citizen Access," a unique identifier must be adopted that spans internal and external “name spaces” for the federal government. FASC-N is only for internal use. PIV interoperable (PIV-I) and PIV compatible (PIV-C) cards must use the Global Unique Identifier (GUID) or similar. Physical access control systems (PACS) being deployed today don’t support GUID at reader or controller because the field is not populated on most PIV cards due to the fact that it is optional by FIPS 201.

General Comment - Applications

ICAM focuses on applications that rely on the PIV card for authentication. Physical access and network access are the predominant ones described in the document. It is important to recognize the other applications, as grouped in the FICAM document Chapter 3, "ICAM Segment Architecture." The description of applications should be expanded so that the reader understands that “applications” include PACS, logical access control systems (LACS) and all other applications that can use PIV for authentication.

General Comment - Facility Security and ICAM

Physical security systems go beyond the segment architecture described in ICAM. In particular, ICAM should consider an overall approach to facility security, including integrated video, access, intrusion and communications management. ICAM should point to other authoritative sources for facility security design guidance.

Smart Card Alliance Comments and Considerations on Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance

Page 2

General Comment - Non-Person Entities

ICAM references the concept of non-person entities. Further definition of this concept and its implication for physical and logical access control are needed.

Section 4.2.1.1, "Create and Maintain Digital Identity Record for External User -- Target Analysis, Process Flow, Part 1," page 57

FICAM document states: "An Applicant for a government service requests an account and provides identity information to an application, usually accessible via the Internet."

Comment: ICAM implementation should consider leveraging existing government resources and facilities. As an example, the U.S. Postal Service can provide resources to fill the role of enrollment and issuance officers to check credentials and documents in the external user application process. This provides a means and method of verifying documents and capturing biometrics for a high assurance interoperable credential. Use of power of law and Federal prosecution are key components for validating the external user credential.

Section 4.3.2, "Perform Background Investigation for Federal Applicant -- Target Analysis," page 67

FICAM document states: "Sharing information between related databases to reduce administrative burden on Applicants, especially when updating background information or transferring between departments or agencies."

Comment: Sharing of information by and between databases is an extremely sensitive area due to the privacy laws. Legal liability issues are of concern here. Guidance should define specific data that could be shared and how it would be transitioned, stored and protected. In essence, an update is needed to the Privacy Impact Assessment (PIA) and System of Records Notices (SORN) for data sharing.

In addition, ICAM implementation should make use of standards (such as the National Information Exchange Model (NIEM)) for data exchange among departments and agencies.

2 Considerations for Moving Forward with ICAM Part B: Implementation Guidance

Whether planning for ICAM Part B, or making recommendations for Part A today, there remain significant issues in defining end points for commercial off-the-shelf (COTS) offerings. The following challenges and recommendations are offered for consideration in developing in FICAM Part B.

2.1 Standards and Certifications ICAM identifies a cornucopia of standards, which subtly add requirements and constraints to ICAM implementation. These standards should be read and researched. However, it is some of the more obvious standards that create the greatest questions. Below are questions and comments that need to be addressed.

• Will FIPS 201-2, expected later this year, and after ICAM Part B, change the rules?

• Will FIPS 201-2 add new restrictions or eliminate some restrictions?

• Will FIPS 201-2 change in ways that allow more freedom for the Special Publication documents to better accommodate physical access and good practice for physical access? Good practice is a broad term, but includes, for example, concepts that recognize the following:

- Physical access control systems and intrusion systems “converged” decades ago so that PACS can provide access and alarm point monitoring for secure access points. To do this requires distributed control and autonomy.

- Physical access control is not simply “middleware” that can reside in the cloud.

Page 3

- There are various Underwriter Laboratory (UL) listings that must be obtained by a PACS without which the fire marshal will not grant a certificate of occupancy. These listings are often systems listings.

- There are both an “attack side” and a “secure side” for each access point that is protected by the PACS or intrusion detection system, and a minimum number of components must be installed on the attack side.

- PACS readers are located outdoors and in other environments subject to weather (e.g., salt spray), environment (e.g., coke dust), vandalism (e.g., screwdrivers). This creates a need for contactless interfaces that support high security applications (which are not allowed by FIPS 201 at present for HIGH or VERY HIGH assurance)

- High throughput portals require a fast, secure authentication process, currently not available with FIPS 201.

• SP 800-73-3 established the concept that all revisions following the base publication are “options,” presumably to avoid recalling and reissuing cards. This makes it very difficult for the PACS and PACS readers to support the "not yet" published options, in addition to the published options. The current variations in PIV card implementations that resulted from optional components have created a challenge for PACS, which if not addressed, can impact security and life safety functions. These variations also make interoperability a challenge.

• The Federal Information Security Management Act (FISMA) now includes PACS as part of the information technology (IT) inventory and, therefore, requires certification and accreditation for PACS prior to official use. This may require additional work and investment prior to granting approval for official use and may contribute to the need to upgrade existing PACS.

• UL 2050 and other existing regulations continue to be required of security management systems. This topic is not included in ICAM.

• The Security Industry Association (SIA) has recently introduced the Open, Systems Integration and Performance Standards (OSIPS) for PACS. It will take time before OSIPS standards are applied to all new PACS.

• FIPS 140-2/3 will place new cost burdens on PACS components implementing cryptography for certificate processing.

FICAM Part B development must consider the changes that are expected to impact standards and remain flexible to accommodate future changes to standards such as FIPS 201-2 (which is expected to be published months after ICAM Part B).

2.2 Authentication Factors and Assurance Levels There is a lot of confusion on authentication factors and assurance levels. FIPS 201 and SP 800-116 need to provide examples of use cases with the different authentication factors and should consider allowing and acknowledging other non-card-related authentication mechanisms (e.g., PACS PIN where the PIN is kept private). In addition, the GSA FIPS 201 Evaluation Program test procedures should specifically state the authentication factors and levels of assurance that are being tested.

Page 4

Figure 1: Access, Authentication Factors and Authentication Mechanisms1

Figure 1 shows the four areas defined in SP800-116 regarding controlled access2. Controlled access goes from open (uncontrolled) to very restricted (exclusion). The figure also shows how many independent authentication factors (what you have, what you know and who you are) are provided by the various PIV authentication methods. It does not explicitly mention the OMB assurance levels (NONE, SOME, HIGH and VERY HIGH) but a parallel between the areas to control and the assurance level is drawn easily. Instead of defining an assurance level for each factor (for example BIO is HIGH but Bio-A is VERY HIGH), SP 800-116 assumes the physical area access rule is mapped on the identity assurance level, which can be a combination of one, two or three factors, each of which may have a different individual assurance level.

The figure also shows how it is possible to combine "independent" authentication factors to get a higher assurance level. For example, VIS or CHUID individually are very low assurance, but combined they provide an acceptable single factor (what you have). BIO-A is considered two factor because the attendant is able to verify that a card (and not a bogus device) is present and a real live biometric scan is made; therefore, BIO-A provides what you have and who you are. Combining BIO (one factor) and PKI (two factors) provides a three factor authentication level, which can be done in two separate steps (one zone entered at a time) or in one step (if the subject goes directly from unrestricted to exclusion).

Finally, the figure shows the possible use of the PACS PIN as one of three authentication factors (what you know), in addition to the card authentication factors. For example, a scenario not shown in this figure could be three factors combining a CAK (what you have), BIO (who you are) and PACS PIN (what you know). In order for the PACS PIN factor to provide an acceptable level of assurance, the length of the PIN should be large enough, the PIN should be protected in the PACS independently of any other secrets the user may know, and the PIN should be different from the PIN used to protect the PIV card private keys.

1 Figure1 was provided by Identification Technology Partners. 2 See Table 7-1 in NIST SP 800-116, "A Recommendation for the Use of PIV Credentials in Physical Access Control

Systems (PACS)."

Page 5

The following discusses detailed use cases that are derived from the SP 800-116 definitions. These define alternative authentication factors that a PACS could use that are not documented in current specifications.

Use Case 1: Read user's picture from PIV card with authentication by a remote attendant. One factor authentication not in SP 800-116 (who you are - photo) For a genuine PIV card, the terminal needs to get the PIN from the user and present it to the card before being able to read the user's picture. The picture information is signed by the issuer. The terminal can verify the digital signatures attached to the picture and to the identifier (FASC-N or UUID) come from a trusted source (the card issuer). If the picture matches the user, the biometric verification is done. This is one factor. This provides only one factor because the terminal cannot determine that the information comes from a true PIV card. A false PIV card could be presented which does not verify the PIN and which has a copy of the correct user's information. Since the terminal cannot verify the PIN was presented correctly, the PIN does not count as a factor. In this case, the PIN only provides privacy protection for the user, and cannot be used as an authentication factor for the terminal. The card also does not count as a factor since there is no way for the terminal to verify that the information comes from a card. IFor example, if a cell phone uses the Near Field Communication (NFC) protocol, the terminal would not see a difference from the card's contactless interface. For a contact interface, the person attempting access could have a paddle connected to a mobile device which is emulating a card; an unattended terminal would not be able to verify this situation. However, if a PIN had been presented to be verified by the PACS, the PIN would be considered another authentication factor in addition to the picture. Also, if the terminal is attended, the VIS + CHUID authentication mechanisms would count as a (weak assurance level) factor. This could result in three factors: the picture coming from the card, the PIN presented to the PACS, and the attendant verifying the transaction is from a PIV card that looks valid. Since PACS PIN is not included in SP800-116, this use case is not taken into account.

If the attendant is local and can verify that the PIN was presented to the card, the use case would provide two factor authentication similar to BIO-A. Use Case 2: Read fingerprints and read CHUID with unattended biometric reader verification. One factor authentication (who you are - fingerprint)

This use case is similar to Use Case 1 since it only verifies that the token provided (which could be anything since it is not authenticated) contains two pieces of information, both correctly signed and containing the same identifier (FASC-N or UUID). Since the CHUID is public information that can be read on any interface with or without the user's consent, the CHUID alone provides no authentication factor. The CHUID is only required to verify that the signature on the other elements comes from a trusted source. As in Use Case 1, there is no cryptographic proof that the card is genuine so the presentation of the PIN is not a trusted authentication factor. Even though a PIN is presented to the card, the card could be counterfeit, accepting any PIN and providing correct cardholder information (which could have been copied from the genuine card in previous transactions).

This use case is similar to the BIO case from SP 800-116. However, doing the path validation using the CHUID provides the correct level of assurance for the use case.

Use Case 3: PIV PKI key verification. Two factor authentication (what you know - PIN, what you have - valid PIV authentication key).

In order to execute a PIV PKI authentication response challenge, the user must present the PIN to the card. The terminal then executes the response challenge and verifies the card is indeed genuine. This provides two authentication factors since the card is verified as being genuine and this happens only when a good PIN is presented to a good card. No false PIN presentation will

Page 6

make this work with a good or bad card, and no bad card will be authenticated. In this use case, the terminal can indeed verify that the card is genuine and that the PIN was good (indirect proof that the PIN was good, transferred by a trusted element, the card).

Use Case 4: PIV PKI key verification plus PACS PIN. Two independent factors (what you have - card; what you know - PACS PIN, PIV PIN)

This use case is not in SP800-116 since the PACS PIN is not included in the current version. The use case illustrates the impact of factors on level of assurance. In this situation, the two factors from the card (PIN + PKI) are the same as the previous use case. The PIN PACS, however, provides another independent factor. Since the card PIN to card verification already provides the "what you know" factor, the use case still only has two factors (what you know + what you have). However, the PACS PIN verification provides a higher level of assurance in the "what you know" factor. This use case illustrates a scenario that is equivalent to increasing the number of digits required on a PIN, but not providing a new factor.

Use Case 5: Card Authentication Key (CAK) + BIO attended. Three factors according to SP800-116 (what you have - CAK; what you know - card PIN; who you are - BIO)

The SP800-116 position on this use case is unclear. The use and verification of the CAK mean that the card is genuine. The CAK can be verified by the terminal and provides one factor. The fact that the terminal is attended means the guard is able to verify that the cardholder is using a true physical PIV card (visual verification) and that the user presents the PIN to that specific card. The card then responds with biometric information which can be verified by the terminal, providing the "who you are" second factor.

The assumption made in this use case is that SP 800-116 assumes that the PIN is considered as a factor. The terminal has no real proof that the PIN was indeed presented but, as the card has been authenticated (with the CAK), an attendant is able to verify that the card was not replaced by a counterfeit card between exchanges. Because the PIN is required to access the BIO information on the card, SP 800-116 must consider use of the PIN as providing three factors.

Further clarification from NIST on how CAK + BIO-A achieve three authentication factors is needed.

Use Case 6: Bio attended. Two factors according to SP800-116 (what you have - visually-validated card; who you are - BIO)

This use case has similar logic to Use Case 5. The attendant is able to verify that the card is indeed a PIV card (using visual verification), counting as the "what you have" factor. This may be a weak assurance level, but it is a factor. However, the PIV card chip is not challenged and, as such, whatever comes from the card may not be what the guard verified. For example, the chip of one PIV card could have been attached to another card; in this scenario, even though the PIN needs to be presented to a good PIV card, the chip on this "good looking" card may not be the valid PIV card chip. As a result, PIN presentation does not count as a factor, since there is no cryptographic proof that the PIN was correctly presented. (In Use Case 5, the CAK had provided trusted proof that the chip was valid.) As the biometric is verified, the guard is able to verify the user is not using a gummy finger or other artifacts to fake the verification, providing a high level of trust in the biometric verification. As a result, this use case supports only two factors.

Use Case 7: BIO only (unattended). One factor (who you are - BIO)

This use case provides only one factor, but does not have a high confidence level. As stated in previous use cases, PIN presentation cannot be verified by the terminal. Since the biometric terminal is not attended, there is no verification by the terminal that the live biometric scan is really from a live person. The terminal could be verifying a gummy finger, or even a photocopy of a fingerprint. If the biometric industry were able to guarantee verification of the subject's "liveness," this use case would provide a higher level of assurance, but still only one factor. The PIN is a privacy tool in this scenario, rather than an available terminal authentication tool.

Page 7

Use Case 8: PIV Auth + BIO unattended. Three factors (what you have - PIV PKI key verification; what you know - PIN; who you are - BIO)

This combination is not explicitly described in the SP800-116, but should not be controversial. BIO is a one factor (see Use Case 6) and PIV Auth is two factors, as indicated in Use Case 3. They both require the PIN to be presented to the card, but as described before, the PIN counts as one factor for two reasons: it is the same PIN presented in both cases and, in the case of PIN protection of the BIO, there is no transfer of trust for the PIN presentation.

Use Case 9: PIV Auth + BIO unattended (fingerprint + picture). Three factors (what you have - PIV PKI key verification; what you know - PIN; who you are - two BIOs) This use case is clear. It clearly provides three factor authentication, just as before, even though there are two biometric verifications. Fingerprint and picture are both biometric authentication methods and they count as one factor (who you are). This use case provides a higher level of assurance, because it uses multi-modal biometric verification for that specific factor, but still results in only three factors.

Use Case 10: PIV Auth + BIO attended. Three factors according to SP800-116 (what you have - PIV PKI key verification; what you know - PIN; who you are - BIO)

This use case once again provides three factors. The PIN (what you know) is accepted because of the PIV Auth verification (second factor). The fact the verification is attended provides a higher level of assurance (not another factor) that the card is genuine (which was already very high because of the PIV Auth), and also provides higher assurance for the biometric factor.

If the picture is added to the fingerprint for this last use case (as in Use Case 9), the level of assurance is increased for the "who you are" factor, but the use case still results in three factors.

Note for all use cases: All signed data objects must be validated (signature and trusted origin validation); otherwise there is no trust anchor. The validation method could be by validating individual objects or by using the security data object (SDO). Using the SDO is much faster when multiple data objects must be validated at the same time.

Note for use cases using the card PIN: Use cases involving card PIN presentation use the contact interface only.

2.3 Leveraging Registered Cards in PACS for Operational Efficiency An aspect to consider for PACS implementation is the difference in the level of assurance when the physical access control system sees a PIV card the first time versus subsequent times. PACS do register cards. They store card information in the secure area of the system (for example, in the PACS database) when it is first presented. For example, during the registration phase (on a specific registration terminal), it would be normal to store card information and verify all signatures and the trust validation path for the card. This process could add the CAK, BIO or other factor or store any other information that needs to be collected once, such as writing the expiration date of the credential in the PACS.

After a card is registered with the PACS, the next time the card is presented on a "normal" access control terminal, all signatures on the card may not need to be verified if the card number (FASC-N or UUID) has been stored in a secure PACS "white list." White list information is functionally equivalent to information with a verified digital signature and path. Using this process would save time, not change the level of assurance, and not require a sophisticated terminal to be used all of the time. It is also perfectly acceptable for the PACS, at time of card registration, to store the hash of the various containers/data objects in the card in addition to the card identifier. The hash is not personally identifiable information and, as such, does not create any privacy issues. Hash values are found in the security data object or could be recalculated for the data objects at the time the card is registered or enrolled.

The following use case illustrates this process. When a registered card is used with a biometric terminal that does not have any cryptographic functions (i.e., not tested to FIPS 140 specifications), a high level of assurance is still possible provided that the hash of the information used by the terminal has been previously stored in the PACS database (e.g., on the white list).

Page 8

Use Case Example. (One factor - BIO) The following exchange shows the benefits of this scenario.

When the PACS sees a card for the first time, the PACS verifies the card and registers it:

• Read CHUID + verification signature + path validation + expiration date. Extract FASC-N (or UUID) and expiration date.

• Read the Security Data Object. Verify its signature. Get the biometric hash information from the Security Data Object.

• Store the following in the PACS data base:

- Card identifier (FASC-N or UUID)

- Expiration date

- The hash of the biometric information read from the Security Data Object or calculated from the data object itself.

It is important to note that this process does require the PACS, or the terminal on which these verifications are done, to be able to do some cryptography (i.e., verification of signatures and path validation).

When the card is later presented to a PACS terminal without any cryptographic functions (except hash), the following process would be used:

• Read the CHUID and send the identifier (FASC-N or UUID) to the PACS. If the identifier is in the PACS database (e.g., on the white list), this can be considered as good as a signature validation. The identifier is valid and has been verified before. (It could be cloned, but it is the same risk as with the signature attached.)

• The user is then asked to present the PIN in order for the terminal to get the biometric information. (This is not a factor since the terminal cannot verify that the result of the PIN presentation is from a trusted card.)

• The terminal reads the biometric information from the card and verifies it matches the live scan from the user (but is not able to verify the signature).

• The terminal calculates the hash of the biometric information it used (not requiring any cryptographic key) and sends it to the PACS database along with the result of the live scan verification (good or bad).

• The PACS can verify that the hash is correct, resulting in two factor authentication (even if the CHUID provides a low level of assurance) without any cryptography involved (except hashing).

This process should be acceptable because the card identifier and the biometric hash that were stored in the PACS database are verified as being good. This provides a white list verification and is equivalent digital signature verification (which was done during registration).

This scenario shows that one-factor biometric assurance is possible even with a terminal that is not able to execute any cryptography (except hash functions). Of course the scenario may be clumsy to implement since the biometric is only accessible from the PIV card's contact interface; nevertheless, the use case is valid and provides biometric support from simple terminals.

2.4 Transformation of PACS A FIPS 201 end-point PACS may well be one that implements all traditional physical access control system functions, plus leverages the public key infrastructure for strong authentication introduced by FIPS 201 and identity assurance levels defined in OMB M04-04. The revised PACS architecture resides in the ICAM segment workflow (which includes automated provisioning and deprovisioning). As a result, the end-point PACS becomes part of the broader ICAM solution and must support an overall end-to-end FIPS 201/ICAM implementation.

Page 9

Accomplishing this expanded role within the overall enterprise target architecture and thus become an “end-point PACS” to an “end-point enterprise ICAM solution” will require a different physical access architecture development process than current PACS deployments employ. Understanding the technology changes, subsequent guidance needs to consider the impact that such PKI and strong authentication/assurance processes and associated technical requirements will have on the overall effort to transition from a traditional PACS to the more complex end-point PACS.

ICAM guidance should build on the progress that has been made in FIPS 201 deployments so far, and consider the architectural implications of new requirements for PACS.

2.5 Suggestions for Easier Use of PIV with PACS Education will be key to proper implementation. As suggested in Section 3.2, additional use cases should be included in the guidance document. Guidance should also consider alternative authentication mechanisms and combinations and expanded use of the contactless interface.

• PACS PIN is essential to and required by the intelligence community. It has previously been out of scope for FIPS 201, but not specifically disallowed. This needs to be addressed for proper guidance. PACS PIN should be allowed as a trusted factor.

• Transparent or "CHUID readers" provide low assurance and the risk of using them should be carefully considered unless used with other components that provide authentication methods that support higher assurance.

• There is no contactless, interoperable authentication method that can be used for PACS in a FIPS 201 implementation. ICAM will struggle with good practice physical access usage until a contactless, mandatory HIGH and/or VERY HIGH assurance requirement emerges. HIGH assurance currently requires the PIN to be presented over the contact interface, which presents challenges for PACS systems in many environments (e.g., weather, throughput, hackers). BIO is also only available from the contact interface.

• The Card Authentication Key (Certificate) should be mandatory on the PIV card and asymmetric to provide interoperability for both the contact and contactless interfaces (especially for PACS use since it doesn't require the card PIN). This also aligns with new PIV-interoperable specifications, which require an asymmetric CAK.

• For the agency issuing the card, a second, symmetric CAK should be allowed by the specification (as an option) to enable fast operation in their PACS (but not intended for interoperable use).

• Additional use cases combining PACS PIN and other authentication factors should be provided for guidance. For example, PACS PIN + CAK is equivalent in terms of assurance level to a PKI PIV Card Auth verification. This would provide two factor authentication over the contactless interface for physical access.

• Additional use cases combining BIO and other authentication factors should be provided for guidance. For example, BIO + PKI clearly make the most sense for VERY HIGH assurance as only BIO will bind the person to the card.

• If FIPS 140-2 Level 2 certification is required for PACS components, implementation cost will increase and time-to-market will be lengthened for compliant readers. Future specifications and guidance should take this into strong consideration.

• Requiring all terminals to provide all algorithms allowed by FIPS 201 is expensive and will create a problem when a future document release introduces a new algorithm. The system architecture design should allow a minimum set for interoperable implementation. A layered system architecture approach could significantly reduce cost and improve overall security implementation for high assurance processes.

• PACS architectures need to be able to support the continuous changes to standards without having to visit readers for upgrades. Interoperability is difficult to achieve because of the variety of options and the continuous changes in the multitude of standards.

Page 10

2.6 Suggestion for Easier PACS Architecture Design and Implementation PACS and supporting infrastructure have typically been designed for 10-15 year operation and should now be able to evolve instead of being replaced. This requires a layered approach with stable end-point design for each layer. An approach defining each component individually is not viable as they are part of a complex, dynamic system. Defining clear use cases is important for education, understanding and correct implementation.

The Smart Card Alliance suggests a design model that builds on previous work with growing maturity and one that can be referenced over an extended period of time and that anticipates continuous development and advancement in both technology and data handling. Taking into consideration that PACS are now considered information systems and implementation is becoming more IT-centric, it bears noting that a standard model for networking protocols and distributed applications is already in place for IT systems. This may be worth considering as a possible guide to the development of a similar model for next generation PACS designs. This IT reference model is commonly known as the OSI Model and stands for the Open Systems Interconnection Reference Model. It is an abstract seven-layered computer network protocol design of network communications. The model was designed to create common network interconnection standards and its primary purpose was to facilitate multi-vendor interoperability among various network devices and software communication systems. The model was created by the International Organization for Standardization (ISO) and was intended to help vendors create interoperable network devices and software in the form of protocols. It is a conceptual blueprint of how communication should take place and provides a great tool for investigating network errors.

As the OSI Reference Model was introduced in 1984 by ISO in order to provide a reference model to ensure products of different vendors would interoperate in the network communications world, so too comes the need to establish a set of reference models that can address the PAC systems of today and tomorrow. Current and future PACS need to work in the context of identity, credential and access management along with the stringent standards governing e-Authentication and HSPD-12 / FIPS 201 compliance. Such a model could include layers governing card-to-reader communications, reader-to-access control panel communications, reader/control panel PKI communications, and PACS-to-IDMS communications. The OSI model has been a resounding success and drives manufacturing and implementation designs to the level of industry-wide acceptance and interoperability never before experienced.

Part B should consider the benefits to the expanded use and interoperability of networks that came about with the adoption of this model. As PACS become enterprise IT applications, the benefits of this approach could be leveraged. If the growing adoption of ICAM is to lead to the tight integration and use of more PACS that leverage smart cards and the digital identity objects created and provisioned by third party systems, then it is imperative that future PACS architectures also follow a systems architecture design driven by reference models that can foster interoperability.

2.7 Summary The Smart Card Alliance has provided these comments on the “Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance” document in support of the committee’s efforts in finalizing Part B, Implementation Guidance. Comments range from privacy implications, unique identifier objects, standards and certifications to authentication factors and assurance levels, with use case examples. Finally, comments relative to improving PACS operational efficiency and ease of use are provided, along with recommendations for the development of a design reference model that would facilitate greater PACS interoperability.

This document is submitted with the desired goal of helping to achieve an overall set of interoperable solutions that supports an integrated physical and logical access framework that can operate effectively and efficiently within the Federal ICAM environment.

Page 11

3 Acknowledgements

This commentary was developed by the Smart Card Alliance Identity Council and Physical Access Council to support the ICAMSC's efforts in finalizing Part B, Implementation Guidance. Publication of this document by the Smart Card Alliance does not imply the endorsement of any of the member organizations of the Alliance.

The Smart Card Alliance wishes to thank the Identity Council and Physical Access Council members for their contributions. Participants involved in the development of this summary included: AMAG Technology; Booz Allen Hamilton; Datawatch; Deloitte; Diebold; GSA; HID Global; Hirsch Electronics; HP Enterprise Services; Identification Technology Partners; IDmachines; IQ Devices: Nagra ID; Northrop Grumman Corporation; Probaris; Technica; U.S. Department of State; XTec, Inc.

Special thanks go to Tony Damalas, Diebold, who led the project, and to the following Identity Council and Physical Access Council members who developed draft content and who participated in reviewing and commenting on the document:

• Dave Adams, HID Global • LJ Neve, Booz Allen Hamilton • Ben Black, Deloitte • Dwayne Pfeiffer, Northrop Grumman • Sal D'Agostino, IDmachines • Rod Pieper, HP Enterprise Services • Mark Dale, HP Enterprise Systems • Rick Pratt, XTec, Inc. • Tony Damalas, Diebold • Kenneth Reed, Datawatch • Marty Frary, Independent Consultant • Steve Rogers, IQ Devices • Daryl Hendricks, GSA • Dan Schleifer, IDmachines • Russ Kent, HP Enterprise Services • Adam Shane, AMAG Technology • Lolie Kull, HP Enterprise Services • Mike Sulak, U.S. Dept. of State • LaChelle LeVan, Probaris • Lars Suneborn, Hirsch Electronics • Gilles Lisimaque, ID Technology Partners • Rick Uhrig, XTec, Inc. • Don Malloy, Nagra ID • Robert Wilberger, Technica • Cathy Medich, Smart Card Alliance • Rob Zivney, Hirsch Electronics

About the Smart Card Alliance Identity Council The Smart Card Alliance Identity Council is focused on promoting the need for technologies and usage solutions regarding human identity information to address the challenges of securing identity information and reducing identity fraud and to help organizations realize the benefits that secure identity information delivers. The Council engages a broad set of participants and takes an industry perspective, bringing careful thought, joint planning, and multiple organization resources to bear on addressing the challenges of securing identity information for proper use.

About the Smart Card Alliance Physical Access Council The Smart Card Alliance Physical Access Council is focused on accelerating widespread acceptance, use, and application of smart card technology for physical access control. The Council brings together leading users and technologists from both the public and private sectors in an open forum and works on activities that are important to the physical access industry and address key issues that end user organizations have in deploying new physical access system technology. The Physical Access Council includes participants from across the smart card and physical access control system industry, including end users; smart card chip, card, software, and reader vendors; physical access control system vendors; and integration service providers.

About the Smart Card Alliance The Smart Card Alliance is a not-for-profit, multi-industry association working to stimulate the understanding, adoption, use and widespread application of smart card technology. Through specific projects such as education programs, market research, advocacy, industry relations and open forums, the Alliance keeps its members connected to industry leaders and innovative thought. The Alliance is the

Page 12

single industry voice for smart cards, leading industry discussion on the impact and value of smart cards in the U.S. and Latin America. For more information please visit http://www.smartcardalliance.org.