This document serves as a collection of the W3C Credentials Community Group responses to Digital Identity Guidelines (NIST-800-63) Request for Comments. Please note that this is not an official W3C position, but the compendium of feedback from the Credentials Community Group, which is a group consisting of W3C members, W3C working group participants, industry, and the general public.
Comments regarding this document are welcome. Please file issues directly on GitHub, or send them to firstname.lastname@example.org (subscribe, archives).
This collection of comments is by no means comprehensive, but represents select perspectives from the community that we hope NIST will consider in its Digital Identity Guidelines. Many of the comments are synthesized from the artifacts and comments in the following GitHub issue thread:https://github.com/w3c-ccg/community/issues/145
Most of all, these comments are meant to begin dialog and discussion with respect to the NIST Digital Identity Guidelines. They are not meant to be a final and definitive community stance, but an opportunity to begin engagement with government technologists and state-sponsored standards developing organizations including NIST and its affiliates.
Privacy enhancements and considerations for identity proofing, authentication, and federation, including new developments in techniques to limit linkability and observability for federation.
Continued use of short message service (SMS) and public switched telephone networks (PSTN) as restricted authentication channels for out-of-band authenticators.
Security and performance capabilities (e.g., presentation attack detection/liveness testing) for biometric characteristic collection to support Identity Assurance Level 2 remote identity proofing in the areas of identity evidence verification (physical/biometric comparison) or binding of authenticators.
Capabilities and innovative approaches for remote identity proofing to achieve equivalent assurance as in-person identity proofing.
Security and privacy considerations and performance metrics for the use of behavioral characteristics as an authentication factor.
Use of dynamic knowledge-based information for identity verification.
Capabilities to meet Federation Assurance Level 3 (see SP 800-63C FAQ C03).
Capabilities and security considerations for verifier impersonation resistance (see SP 800-63B FAQ B04).
Additional controls and mitigation to address the ongoing evolution of threats such as phishing and automated attacks.
This recommendation also provides guidelines for credential service providers (CSPs), verifiers, and relying parties (RPs)
The framing throughout the rules (for example, the roles) fits/assumes the traditional IdM system model. IdM system models are undergoing a variety of changes and experimentation, raising concerns that using this list of obligations is based on an old model, that may not fit newer IdM systems and/or may unduly inhibit further experimentation.Section 4.1
The digital identity model used in these guidelines reflects technologies and architectures currently available in the market
Some SSI technologies are in market – are the guidelines intended to cover SSI technologies?
When a claimant successfully demonstrates possession and control of one or more authenticators to a verifier through an authentication protocol, the verifier can verify that the claimant is a valid subscriber. The verifier passes on an assertion about the subscriber, who maybe either pseudonymous or non-pseudonymous, to the RP
In SSI, the role of the verifier is not required – or rather it is replaced by digital wallet component that acts on behalf of the subject.Section 4.1 Figure 4-1
This is only one type of digital identity model – it is not representative of non-federated models.Section 4.3.2
A credential is stored and maintained by the CSP, though the claimant may possess it
Why isn’t the credential is stored where the user chooses – eg in the user’s digital wallet and backed up.Section 4.4
Overall, SP 800-63 does not presuppose a federated identity architecture
The roles depicted and language used do predicate a federated model. It would be difficult to adopt an SSI model AND adhere to the NIST digital identity guidelines.
The section sets out the benefits of a federated architecture over a siloed one, but there is no reference to or comparison to a decentralised model.Section 4.4.1 Assertions
An RP trusts an assertion based on the source, the time of creation, how long the assertion is valid from time of creation, and the corresponding trust framework that governs the policies and processes of CSPs and RPs.
NIST could clarify how trust frameworks interface with these guidelines.
Examples of assertions include: (SAML, OIDC, Kerberos tickets)
Verifiable credentials can also be containers for assertions.Table 5.3 Federation Assurance Levels
FAL1: permits the RP to receive a bearer assertion from an identity provider (IdP). The IdP must sign the assertion using approved cryptography.
Can the digital wallet be the IdP in this context?Section 6.1
...more information on whether an agency can federate is provided in section 7
What about more information on self-federation?
The CSP validates the information by checking an authoritative source
What if the information an applicant receives from the authoritative source is already signed by them? Eg. in SSI where a credential is cryptographically signed by the issuer and does not need to be validated by a CSP for a relying party to rely on it.Section 4.4 Identity Assurance Level 2
The framing assumes that a CSP is present, when this role is not always necessary – eg. if the individual has their credentials issued to them directly by the issuer, they can present these to a relying party without the need for a CSP to be involved.Section 22.214.171.124 Address Confirmation
If a utilities company provided a proof of address credentials (eg. because internet was connected at the address and paid for by the applicant), would this be an acceptable form of address confirmation?Section 5.3.2
Large focus on Knowledge Based Verification requirements – what about guidelines for “something you have”?Section 8.1.1 Social Security Numbers
...Overreliance on the SSN can contribute to misuse and place the applicant at risk of harm, such as through identity theft. Nonetheless, ....
For some use cases, when Privacy concern is high, one time use of Decentralized Identifiers or derivative artifacts may be considered for use as unique alternative identifiers to the SSN. For further privacy, the pairwise DID identifiers can be used. The DID is meaningless by itself, but globally unique. It has the potential to mitigate correlation risks.
Furthermore, DID-based systems should prevent DIDs from being used for authentication, so the harm in public exposure is reduced. The same DID has the potential to be used across systems, agencies, and organizations without compromising its security and privacy properties.
We refer to the following item:
...CSPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for other purposes than those specified at collection can create privacy risks when individuals are not expecting or comfortable with the additional processing.
In some use cases, Selective Disclosure and Zero-Knowledge Proofs with Verifiable Credentials can be leveraged when individuals wish to utilize information minimization.
Figure 5 talks about federation as a three party relationship which includes an IdP – again, the guidelines should clarify the terminology on what amounts to an IdP and whether this could be a digital wallet/software agent acting on behalf of the user.5.1
Assumes a centralized approach, could benefit from a web of trust federation model?