ABCDEFGHIJKLMNOPQRST
1
Overall themes for feedback
2
3
Scope and narative nature of documentThe focus on the mission fulfilment and equity concerns are much appreciated and the OpenID Foundation wholly supports that.
The scope of the 800-63-4 document set is quite clearly defined yet there are quite a numer of areas that it deviates from that scope. Both readers and authors would be better served if the scope were stuck to more rigorously and the resulting set of documents was shorter overall.
There should also be focus on whether the document is intended to be guidance in a general sense or if it is intended to contain a large amount of direct and measurable requirements that implementers must use.
In this draft there are conversational narative sections, normative sections and normative language that in several cases lack specifics about what must be done in order to comply, this interleving of normative sections and flexible use of normative language will make it a lot harder than necessary for implementers to meet the requirements.
4
5
Scope of communities, use cases and solutions coveredWith the increasing digitisation of services the communities of applicants and subscribers that need to be taken account of has significantly grown since previous iterations of this document set. It seems that some of the normative requirements are only considering "Single-Sign-On" use cases. Federation has wider utility than that so the requirements should be reviewed in the context of a much wider set of subscribers (including citizens and foreign nationals) and a much wider set of use cases than it appears have been considered.
6
7
Privacy In this set of documents privacy is mentioned in a number of sections. Unfortunately the topic of privacy is highly complex and the current draft falls short of addressing that complexity fully and does not highlight for implementers that there are difficult trade-offs to be made around privacy.
One important step to take is to enhance the threat modelling to directly include threats to individuals privacy across the full range of communities served, this would then naturally lead to those threats being more directly addressed.
We would propose one of two options be taken to resolve this issue:
1. Strengthen the coverage of privacy related matters to the extent that privacy concerns are much more thoroughly addressed for all communities of subscribers than seem to have been addressed so far
OR
2. Address privacy concerns in a separate set of documentation that addresses the full range of privacy concernns and refer to that from these documents, minimising as far as possible privacy issues dealt with within the digital identity guidelines

We believe that option 2 is the better option to take
8
9
InteroperabilityWhen federation is used in between larger groups of IdPs and RPs the challenges of interoperability become more significant. This concern does not seem to have been covered in much detail in this document set and we believe it to be an important consideration that deserves some additional guidance in order to avoid scalability issues.
With the increase in digitization of systems the number of parties involved has dramatically increased and if services are to remain, available, cost effecticve interoperability needs to be made easier to deliver. The following list are suggested requirements that should be integrated into the guidance somehow:

1. Requirements to implement standardised and interoperale interfaces
2. Conformance testing of the technical interfaces of IDPs and RPs
3. Monitoring of services to be alert to any standards conformance issues that cause failures in order that those issues can be identified and resolved quickly
10
11
Risk based approachA risk based approach to Digital Identity is a good starting point, unfortunately there are significant portions of the document that define requirements without linking those requirements to the wide variety of risks that should be mitigated. An expression of the key goals for the Digital Identity Guidelines followed by a thorough expression of the risks to the delivery of those goals which then is directly referenced by each section where normative requirements are defined would provide a much richer understanding of why certain normative requirements are there. This would then enable implementers to better meet the intent of the guidelines rather than blindly following the requirements as they are currently defined.

The 800-63-base-4 document describes a risk based approach to xALs and tailoring of same and there are two issues with that directly:
1. It is unclear whether the tailoring involves stepping the xAL in question to a different xAL in some circumstances or that tailoring relates to flexibility of some specific component requirement of the Initial Assurance Level selected
2. If it is the latter then the consequence would be that additional details of how the xAL was achieved would need to be taken into account by the RP when making access decisions necessitating communication of the underlying xAL metadata from IDP to RP in context with the transaction.
12
13
Decentralised architecturesThere seems to be some work to address decentralised federation architectures as part of this draft. it is not clear whether the intent is to include decentralised digital identity architectures within the definition of federation provided. The current entry in the "definitions and abbreviations" appendix actually includes all decentralised architectures yet the 800-63C-4 does not obviously address these approaches. The OIDF is of the view that All decentralized models are forms of federation.
Suggestion would be to leave "federation" as a term that covers all architectures and then use a description that more clearly describes the features of decentralised architectures to define the different requirements. As part of that expand 800-63C-4 to cover other relatively mature digital identity models (perhaps mDL 18013-5) and define requirements for each of the models.
14
15
ConsentThere is no clear definition of consent in the document and it would be helpful to define that. In some other contexts it has proved useful to separate "consent" (to process data) from "authorization" (to share data). Whatever terms are used by NIST, the separation is a real one for end users and not having clarity on that separation risks mis-communication and lack of clarity with all of the attendant issues for consumer confidence that arise.
16
17
18
Questions from "Notes to reviewers"
19
QuestionComment
(Include rationale for comment)
20
Identity Proofing and Enrollment
21
NIST sees a need for inclusion of an unattended, fully remote Identity Assurance Level (IAL) 2 identity proofing workflow that provides security and convenience, but does not require face recognition. Accordingly, NIST seeks input on the following questions:no response
22
What technologies or methods can be applied to develop a remote, unattended IAL2 identity proofing process that demonstrably mitigates the same risks as the current IAL2 process?no response
23
Are these technologies supported by existing or emerging technical standards?no response
24
Do these technologies have established metrics and testing methodologies to allow for assessment of performance and understanding of impacts across user populations (e.g., bias in artificial intelligence)?no response
25
What methods exist for integrating digital evidence (e.g., Mobile Driver’s Licenses, Verifiable Credentials) into identity proofing at various identity assurance levels?The processes that are used in identity proofing could readily integrate digital evidence. Assuming an mDL or VC was available in the end-user's wallet then it could be presented via the one of several credential presentation protocols such as ISO mdoc or OpenID for Verifiable Presentation. These credentials could then be used to feed into the Resolution, Validation and Verification stages of identity proofing.
https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
26
What are the impacts, benefits, and risks of specifying a set of requirements for CSPs to establish and maintain fraud detection, response, and notification capabilities?Impacts:
- Complexity will be increased
- Implementation and maintenance costs will increase
Benefits:
- There may be a measurable reduction in fraud related to the mis-use of digital identity provided by CSPs
Risks:
- False negatives - Some legitimate usage of CSP delivered digital identities my be prevented due to incorrect triggering of fraud detection, response and notifications. It could also result in real information and incorrect information being uincorrectly circulated about an honest subscriber and that subscriber having significant difficulties accessing all manner of downstream services.
- False positives - Some fraudulent activity may still continue despite the requirements for fraud detection, response and notification and this may continue in the context of a false sense of security
- The necessity of increased complexity of systems resulting from the implementation of fraud detection, response and notification will increase the attack surface of the overall system increasing the risk of a bad actor finding a weakness that grants them unauthorised access to sensitive information.
- A practical implementation of fraud detection, response and notification capabilities will need to maintain persistent "suspect" or "known bad" indicators of fraud that can be used to spot re-presentation of fraudulent artefacts..
- Fraud systems will need access to a persistent store of data relating to fraud and necessarily that will contain PII. There will eb risk to suscriber privacy associated with that persisting data store.
- Many fraud response systems operate in an automated "rules based" fashion and there is an attendant risk that legitimate subscribers could experience algorithmic exclusion or significantly higher friction journeys if they happen to trigger certain rules.
27
Are there existing fraud checks (e.g., date of death) or fraud prevention techniques (e.g., device fingerprinting) that should be incorporated as baseline normative requirements? If so, at what assurance levels could these be applied?There are some standardised events defined in the the "Shared Signals Framework" produced by the "Shared Signals" Working Group at the OpenID Foundation - https://openid.net/wg/sharedsignals/. This would work enables interoperable implementations to emerge that communicate various events that may indicate fraudulent activity.
28
How might emerging methods such as fraud analytics and risk scoring be further researched, standardized, measured, and integrated into the guidance in the future?no response
29
What accompanying privacy and equity considerations should be addressed alongside these methods?The OpenID Foundation has commissioned and published a draft that relates to this question: https://openid.net/2023/04/05/open-for-comment-privacy-landscape-whitepaper/
30
Are current testing programs for liveness detection and presentation attack detection sufficient for evaluating the performance of implementations and technologies?no response
31
What impacts would the proposed biometric performance requirements for identity proofing have on real-world implementations of biometric technologies?no response
32
Risk Management
33
What additional guidance or direction can be provided to integrate digital identity risk with enterprise risk management?The objective of risk management is to drive a set of outcomes and reduce the likliiehood and impact of things that detract from meeting those outcomes.
We would suggest definition of a set of measurable outcomes, that include desirable outcomes for all stakeholders, including government agencies, businesses and people from a range of communities. From that a threat model should be developed and provided to implementers to use when undertaking risk assessments. Perhaps that could be an additional document in this set?
Following on from that structured model the technical guidance should emerge thus ensuring that threats to the outcome are managed and that risks to all classes of stakeholders are appropriately managed and documented.
34
How might equity, privacy, and usability impacts be integrated into the assurance level selection process and digital identity risk management model?Clear measurable definition of outcomes relating to equity, privacy and usability should be included in the digital identity risk management framework described in the answer to the previous question
35
How might risk analytics and fraud mitigation techniques be integrated into the selection of different identity assurance levels? How can we qualify or quantify their ability to mitigate overall identity risk?no response
36
Authentication and Life Cycle Management
37
Are emerging authentication models and techniques – such as FIDO passkey, Verifiable Credentials, and mobile driver’s licenses – sufficiently addressed and accommodated, as appropriate, by the guidelines? What are the potential associated security, privacy, and usability benefits and risks?no response
38
Are the controls for phishing resistance as defined in the guidelines for AAL2 and AAL3 authentication clear and sufficient?phishing resistance as a term is not defined in the guidelinesso it is somewhat dificult to address this question. Based on assumptions we have made about the intent we do not think that the wording is clear and sufficient. For example on line 541 of 63B it says "While phishing
resistance as described in Sec. 5.2.5 is not generally required for authentication at AAL2, verifiers SHOULD encourage the use of phishing-resistant authenticators at AAL2 whenever practical since phishing is a significant threat vector" That is insufficiently clear for implementers top understand whether phishing resistance is a requirement or not and for RPs there may be significant uncertainty (at AAL2) whether the authenticator used was phishing resistant.
39
How are session management thresholds and reauthentication requirements implemented by agencies and organizations? Should NIST provide thresholds or leave session lengths to agencies based on applications, users, and mission needs?Focus should be on adequate mitigation of risk in support of delivering defined outcomes rather than specific technical thresholds. It may be more valuable to discuss the risks involved in session management more thoroughly
40
What impacts would the proposed biometric performance requirements for this volume have on real-world implementations of biometric technologies?no response
41
Federation and Assertions
42
What additional privacy considerations (e.g., revocation of consent, limitations of use) may be required to account for the use of identity and provisioning APIs that had not previously been discussed in the guidelines?Management of data lifecycle - i.e. requirement that data is not retained for any longer than necessary to fulfil te agreed purpose for holding or processing the data
43
Is the updated text and introduction of “bound authenticators” sufficiently clear to allow for practical implementations of federation assurance level (FAL) 3 transactions? What complications or challenges are anticipated based on the updated guidance?No - it has led to confusion and a lack of understanding about what is meant among the reviewers. It seems very likely that implementers would need to make significant assumptions about what is meant
44
General
45
Is there an element of this guidance that you think is missing or could be expanded?We are providing feedack on many of the sections in the documents where we think specific improvements can be made. Aside from those thesre are the folloing items:-
- Token binding mechanisms seem to be absent - something like https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
- There is a lot of content on federation and assertions that is based on protocols like SAML2 and OIDC. There is little guidance on how wallet based asynchronous delivery architectures should be implemented and how they might need to be deployed in order to meet the requirements of these guidelines.
46
Is any language in the guidance confusing or hard to understand? Should we add definitions or additional context to any language?yes - tried to highlight that in the specific document feedback.
- In particular the bound authenticators area is challenging
- also the federation/non-federation split is difficult to understand the utility of from a practical sense - This appears to be trying to address decentralised architectures but it is not clear and the definition of federation provided in the "definitions and areviations" appendix actually includes all decentralised architectures. Suggestion would be to leave "federation" as a term that covers all architectures and then use a description that more clearly descries the features of decentralised/wallet based/asynchronous architectures to define the different requirements.
- there seems to be little actual guidance that can be readily applied to decentralised architectures
- The word "consent" has been an issue in the past as it has specific meaning in a legal context in some jurisdictions where "consent to process" is the meaning. This is distinct from permitting the sharing of data to another party, some communities use "authorization to share" as an alternative description.
47
Does the guidance sufficiently address privacy?In a US federal government agency context when relating to federal staff or contractors this is assumed to be covered by contractual terms and therefore privacy is not a material consideration

In the context where US Citizens are interacting with federal agencies the guidance does not seem to address the topic of privacy in sufficient depth, two eacmples:
1. The significant variability of data protection and legislation across states is not mentioned
2. The trade-offs that are often needed between requirements for individual privacy, fraud mitigation, and security are not mentioned

For non-citizens interactimng digitally with federal agencies there is an even more complex interaction with privacy legislation enacted elsewhere in the world

Perhaps a separate piece of guidance should address that and cover how legal requirements like CCPA and GDPR might be taken into account.

There also seems to be less focus on the data minimisation topic that would be desirable. There are places in these documents where it is assumed data will be shared when in fact there are use cases whe specific attributes are not needed (like 1st name and last name). It would be good to add some guidance about the fact that it is the RP that understands the data it needs and it therefore should be the RP that describes the attriutes needed. Other data beyond that should not be transferred minimizing privacy risks to the individual, reducing risks to the RP relating to handling and holding PII.

There is standards based and international treaty derived materials that are applicable (ISO and OECD) and those should be re-used as much as possible, both to reduce the workload on NIST and to have these concerns covered in a consistent fashion as far as possible.
48
Does the guidance sufficiently address equity?While equity is mentioned in the base document there seems to be little in the normative guidance that reflects that stated intent.
Suggest being much clearer about the expected outcomes (including equity for individuals from various communities) and threats to those outcomes
49
What equity assessment methods, impact evaluation models, or metrics could we reference to better support organizations in preventing or detecting disparate impacts that could arise as a result of identity verification technologies or processes?no response
50
What specific implementation guidance, reference architectures, metrics, or other supporting resources may enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?We would recommend the use of mature Open Standard interfaces as a critical component - this has been covered in the guidance to some degree. The reasons for this however are not really highlighted and we believeit would be useful to include those.
1. Increased interoperaility between IDPs and RPs
2. Well documented threat models and thorough security assessments of the standard interfaces
3. Commercial and Open Source software implementations
4. Pool of experienced suppliers in marketplace
5. Availaility of conformance and certification tools to measure and demonstrate conformance and to increase interoperaility
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100