usnistgov / nistir-8149

Home to public draft NISTIR-8149: Developing Trust Frameworks to Support Identity Federations

NISTIR-8149

Developing Trust Frameworks to Support Identity Federations

https://pages.nist.gov/NISTIR-8149/

nistir-8149's Issues

Give greater prominence to a bullet list of identity federation benefits

The draft does a good job of identifying business benefits of identity federation, and provides a bullet list of them in Section 9. Conclusion & Other Considerations:

• The ability to consistently manage and understand risk across multiple organizations,
• The ability to limit organizational costs associated with managing individual identities,
• Streamlined user experience due to fewer credentials,
• The ability to scale and expand customer bases,
• The ability to provide more online services, and
• Increased ease of access to shared resources.

It might be more hard-hitting to move this list to the front of the draft.

Also, suggest a couple of additions to the list:

• Minimize the replication of users' PII across the Internet, reducing risk to users and liability of RPs
• Improve security by providing more-current access information (user attributes) to RPs and limiting risk of use of revoked or obsolete access privileges
• Federated SSO improves incentives for users to acquire a single high-quality credential to replace multiple passwords
• Improve the economics of ABAC by enabling re-use of user attribute data

Training and certification of independent third party assessors

Organization: VASCO Data Security

Type: 2 - Industry

Reference: section "7.2. 3rd-Party Assessment"

Comment: a statement could be added about how and by who independent entities need to be trained and certified. The text could also suggest that every trust framework provider needs to defined this for himself.

Clarify whether the draft is intended to describe how existing federations work, or to provide a recommended standard approach

The draft is unclear as to whether it is based on collected actual practices of operational identity federations, or whether it is proposing a standard approach (that may or may not be implemented anywhere currently.)

For example, this text from the draft seems to imply that existing federations have defined federated identity management -- "communities and organizations that share a common user base and transaction type have built the means to allow users to sign on and access multiple services through common login and authentication processes. This is known as federated identity management." But later on the draft discusses the possibility of a broad identity ecosystem, bound neither by pre-existing community affiliation nor by common transaction type (whatever that is. )

I suggest the best approach would be to state that the practices of existing federations have been examined and taken as input, but that this document is proposing a complete and coherent high-level structure and standard vocabulary/ontology for trust frameworks (that may or may not be found in any operating identity framework.)

Authentication options of already proofed users to a CSP to obtain credentials again

Organization: VASCO Data Security

Type: 2 - Industry

Reference: Section "5. System Rules"

Comment: The text focuses on Identity Proofing and on the subsequent issuance of credentials. However it does happen that users who have already performed the identity proofing need to obtain their credentials again from the CSP, without having to go through the identity proofing process again. In such a case the user needs to authenticate (log on) to the CSP. This is currently not addressed in the text.

Suggested Change: (The following could be added as a new subsection "User authentication, based on risk" under section 5.3. Credential Management) At a minimum, a trust framework’s systems rules should define methods for authenticating already-proofed users to CSP’s. The rules can contain which authentication methods or authentication factors can or cannot be accepted (e.g. Should the CSP accept password-only authentication? May one-time passwords be distributed via SMS?), with how many factors a user has to authenticate, which combination of factors can or cannot be accepted (e.g. Is it allowed to use fingerprint authentication to a mobile app that provides a one-time password) based on the level of risk.

Virtual In-person identity proofing

Organization: VASCO Data Security

Type: 2 - Industry

Reference: Section "5.2. Identity Proofing", subsection "ID proofing options, based on risk"

Comment: The text can be expanded with the concept of Virtual In-person identity proofing whereby the in-person identity proofing is done over the internet through a webcam conference between the applicant and the authorized agent.

Remote Identity Proofing

Current section 5.2 Identity Proofing talks about "Remote identity proofing" can we add additional context that it is ok to add identity service providers who remotely take a picture of the driver's license, authenticate that it is real and takes a 5 second selfie video and does a facial match of the picture of the person ID to the 5 second video selfie. This is more accurate than KBA and matches a government issued ID to the person using facial recognition software or remote human verification.

Section current reads:
Remote identity proofing: Remote identity proofing is appropriate for moderate-risk environments and requires a User to provide additional evidence in support of their asserted identity. Options for remote proofing include knowledge-based challenges, which involve checking information provided by an applicant against an authoritative data source, and sending one-time codes to an applicant’s email address or cell phone. Additional option Identity Service Providers who can remotely match a citizen's government issued ID to be authentic with a selfie video of the person's face and confirm a facial match of the ID to the selfie.

Clarify that the purpose of creating trust frameworks is to manage the risk of sharing information

Specifically, in the Introduction, as reads:

" the internet presents its own particular challenges, not the least of which is being able to identify with whom they are interacting. "

Suggest alternatively:

" the internet presents its own particular challenges, not the least of which is being able to manage the risks associated with accepting credentials of users not vetted and managed directly by the relying-party organization. "

Why equate "Credential Service Provider" to "Identity Service Provider"?

This publication seems to indicate that "Credential Service Provider" is analogous with "Identity Service Provider", but the definition provided for CSP doesn't align 1:1 with the ITU definition for IdSP [1]. The former assigns credentials, the latter may or may not assign credentials to individuals associated with such identities. A CSP seems to be an IdSP that only assigns identities to individuals whom have also been credentialed.

Where is User Authentication?

The guidance talks about determining acceptable Identity Proofing levels within your Trust Framework, but leaves out determination of appropriate transaction time Authentication levels.

A Trust Framework based solely on 800-63-63, for instance, would want to specify both that IAL1-3 are the requirements for proofing an identity in order to grant a credential, AND that AAL1-3 are the appropriate authentication requirements for transaction time. After assessing risk, an RP in that TF would then screen for CSPs having met the IAL that they need for the transaction, and request an interaction with the user at the AAL they need for the transaction (that interaction being an authentication).

Should you not also define and discuss User Authentication and that a TF should determine these levels ahead of time as part of their Identity Policies?

Thanks for the document, I'll keep reviewing. :)

User profiling

Organization: VASCO Data Security

Type: 2 - Industry

Reference: section "5.4. Privacy Requirements"

Comment: One of the goals of the document is to standardize on wording. In the first paragraph: "Through federated technologies, an IDP could have insight into a range of transactions a user is conducting online across a variety of RPs, building a narrative about a user that she never anticipated, or wanted, the IDP to have." is known as "user profiling" in the EU’s GDPR.

Suggested Change: Through federated technologies, an IDP could have insight into a range of transactions a user is conducting online across a variety of RPs, building a narrative about a user that she never anticipated, or wanted, the IDP to have. This is known as user profiling.

Client equipment - The #1 hurdle

The document doesn't go into this subject which I guess is because this topic has generally been improperly addressed by the IT industry. Smart cards (including PIV) was once the hope but since they are incompatible with mobile computing devices they appear to be a dead-end. TEEs shipped with mobile devices are also fairly useless since there is no standard for credential provisioning and management.

That is, I don't think the world needs yet another "policy" document. BTW, haven't NIST already done that years ago with the LOA stuff?

Liability of the 3rd party assessor

Organization: VASCO Data Security

Type: 2 - Industry

Reference: section "6.2. Risk and Liability Allocation" and section "7.2. 3rd-Party Assessment"

Comment: the text can be expanded with rules about the possible liability of a 3rd party assessor. For example, if an incident happens at a member that was assessed by means of a 3rd party assessment, is it possible to put liability to the 3rd party assessor?

Clarify the differences and similarities between federation within an organization vs. across multiple organizations

The draft identifies benefits of and considerations about federated identity management in the context of cross- or multi-organizational federation. Several of the benefits cited can be obtained by using federation technology within a single enterprise or other organization.

For example, the user convenience of single sign-on can be delivered to employees within the enterprise, as can the benefit of relieving multiple internal resource managers of the burden of maintaining separate user accounts.

These benefits can be obtained within an enterprise without the need for formal "trust framework" agreements because all participants are within a single legal entity with a single hierarchical management control structure to provide recourse and accountability.

However, identity federation within an enterprise does not provide for the large and growing number of business scenarios that require secure information sharing among participants who are not all employees (or otherwise under the legal control) of a single organization. For those scenarios--including sharing among supply-chain partners and interaction with customers, citizens, or government agencies--the benefits of identity federation require agreement on a common trust framework.

The most challenging aspect of a multi-organizational identity federation or a broader "ecosystem" arrangement is governance among legal peers. Technology governance is required to set standards to assure interoperability and end-to-end information security, but most critical is legal governance to manage and allocate risk and liability.

I suggest the above discussion or something like it be included in the draft, perhaps in a sidebar or text box.