ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
OIDF NIST 800-63-4 Feedback collection
2
3
Main NIST Publicationhttps://csrc.nist.gov/pubs/sp/800/63/4/2pd
4
5
Proposed dates for OIDF feedback:
6
Circulation to Working Group Co-Chairs26th August
7
NIST Webinar28th August
8
OIDF NIST 800-63-4 Workshops19-20th September
9
Deadline for OIDF feedback collection27th September
10
Deadline for collated feedback7th October
11
12
13
Note there is a statement in the NIST 800-63-4 2nd draft based document "Notes to reviewers" as follows:
14
15
800-63-4 Base
16
NIST is specifically interested in comments and recommendations on the following topics:
17
18
1. Risk Management and Identity Models
19
• Is the “user controlled” wallet model sufficiently described to allow entities to understand its alignment to real-world implementations of wallet-based solutions such as mobile driver’s licenses and verifiable credentials?
20
• Is the updated risk management process sufficiently well-defined to support an effective, repeatable, real-world process for organizations seeking to implement digital identity system solutions to protect online services and systems?
21
22
2. Identity Proofing and Enrollment
23
• Is the updated structure of the requirements around defined types of proofing sufficiently clear? Are the types sufficiently described?They are clear and the OIDF is pleased to see that clarity emerging. As a next step there will be a need to standardise the representation and have very specific definitions of the types of proofing. This is something that the eKYC & IDA Working group of the OIDF has in their roadmap.
24
• Are there additional fraud program requirements that need to be introduced as a common baseline for CSPs and other organizations?standardisation of the fraud event types and their representations would be a highly valuable next step to allow easier and cheaper integration and increased liklihood of interoperability.
25
• Are the fraud requirements sufficiently described to allow for appropriate balancing of fraud, privacy, and usability trade-offs?
26
• Are the added identity evidence validation and authenticity requirements and performance metrics realistic and achievable with existing technology capabilities?
27
28
3. Authentication and Authenticator Management
29
• Are the syncable authenticator requirements sufficiently defined to allow for reasonable risk-based acceptance of syncable authenticators for public and enterprise-facing uses?
30
• Are there additional recommended controls that should be applied?
31
• Are there specific implementation recommendations or considerations that should be captured?
32
• Are wallet-based authentication mechanisms and “attribute bundles” sufficiently described as authenticators?
33
• Are there additional requirements that need to be added or clarified?
34
35
4. Federation and Assertions
36
• Is the concept of user-controlled wallets and attribute bundles sufficiently and clearly described to support real-world implementations?As stated in feedback to 800-63-C-4 the term "user-controlled" (or "subscriber-controlled") gives the impression that the user is 100% in control of that wallet which is not really the case. The devices that wallets are deployed on and the software stack are controlled by various corporations that deploy layers of the system and have policies that are implemented. This naming should be changed to something that does not imply that the user "controls" the wallet.
37
 Are there additional requirements or considerations that should be added to improve the security, usability, and privacy of these technologies?
38
39
5. General
40
• What specific implementation guidance, reference architectures, metrics, or other supporting resources could enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?Clearer separation of roles through the document set and greater clarity that the roles (CSP, Verifier, IDP, RP, and federation authority) can be performed by various entities and that implementations often have more than one of these roles performed by the same entity. This is not covered explicitly and in some parts of the document the roles and the entities that provide them are conflated.
Highly specific profiles of technical specifications could be developed and given some sort of recognition by NIST - specific examples of this will be added into the answeres given to this question for the A, B & C documents.
41
• What applied research and measurement efforts would provide the greatest impacts on the identity market and advancement of these guidelines?
42
43
800-63A-4
44
NIST is specifically interested in comments and recommendations on the following topics:
45
46
1. Identity Proofing and Enrolment
47
• Is the updated structure of the requirements around defined types of proofing sufficiently clear? Are the types sufficiently described?Further elaboration of the types should be undertaken but from the perspective of the OIDF this would be better delivered as part of an international standards effort so that the standard type definitions and representations thereof can be delivered to an international community and international interoperability is more likely
48
• Are there additional fraud program requirements that need to be introduced as a common baseline for CSPs and other organizations?
49
• Are the fraud requirements sufficiently described to allow for appropriate balancing of fraud, privacy, and usability trade-offs?- a standard or best practices framework balancing the needs of fraud mitigation and privacy should be developed
50
• Are the added identity evidence validation and authenticity requirements and performance metrics realistic and achievable with existing technology capabilities?
51
52
2. General
53
• What specific implementation guidance, reference architectures, metrics, or other supporting resources could enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?Highly specific profiles of technical specifications could be developed. In the context of 800-63A-4 the following would be highly beneficial in enabling more rapid adoption:
- A profile of OpenID for Identity Assurance that defines the proofing types, document validation processes, evidence verification process and defines a standard representation of these elements. The OIDF eKYC & IDA Work Group already has that in their roadmap in a way that is re-usable across protocols, and NIST collaboration on that would be mutually beneficial.
- For fraud management a standardised definition of fraud signals should be defined between NIST, the fraud practitioners and the OIDF Shared Signals Work Group enabling quicker cheaper delivery of interoperability
- For the "Identity Proofing Roles" it would be very useful to standardise the representation of the relationships described. The OpenID Foundation has a draft spec called OpenID for Authority within the eKYC & IDA Work Group that may be a good fit for that and would welcome contribution to that discussion from NIST - if this were to become a suitable standard in this space it would simplify the implementation and help with more rapid adoption
54
• What applied research and measurement efforts would provide the greatest impacts on the identity market and advancement of these guidelines?
55
56
800-63B-4
57
NIST is specifically interested in comments and recommendations on the following topics:
58
59
1. Authentication and Authenticator Management
60
• Are the syncable authenticator requirements sufficiently defined to allow for reasonable risk-based acceptance of syncable authenticators for public and enterprise-facing uses?
61
• Are there additional recommended controls that should be applied? Are there specific implementation recommendations or considerations that should be captured?
62
• Are wallet-based authentication mechanisms and “attribute bundles” sufficiently described as authenticators? Are there additional requirements that need to be added or clarified?
63
2. General
64
• What specific implementation guidance, reference architectures, metrics, or other supporting resources could enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?
65
• What applied research and measurement efforts would provide the greatest impacts on the identity market and advancement of these guidelines?
66
67
800-63C-4
68
NIST is specifically interested in comments and recommendations on the following topics:
69
70
1. Federation and Assertions
71
Is the concept of user-controlled wallets and attribute bundles sufficiently and clearly described to support real-world implementations?As stated in feedback to 800-63-C-4 the term "user-controlled" (or "subscriber-controlled") gives the impression that the user is 100% in control of that wallet which is not really the case. The devices that wallets are deployed on and the software stack are controlled by various corporations that deploy layers of the system and have policies that are implemented. This naming should be changed to something that does not imply that the user "controls" the wallet.
72
• Are there additional requirements or considerations that should be added to improve the security, usability, and privacy of these technologies?Guidance on the the behaviour of wallet applications and the metadata they handle should be developed. The current requirements impose restrictions on the sharing of identity attributes but there is little mention given to the use of metadata derived form the use of the attribute bundles. This is highly valuable metadata and is the very data that ad-tech uses to deliver targeting of ads. If there are not requirements and controls around the use of bundle, wallet and assertion metadata then there may be significant leakage of sensitive information and significant commercial gain to be derived from providing wallet services at the cost of end-user expectations of privacy.
73
2. General
74
• What specific implementation guidance, reference architectures, metrics, or other supporting resources could enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?Highly specific profiles of technical specifications could be developed. In the context of 800-63C-4 the following would be highly beneficial in enabling more rapid adoption:
- Profiles of the specifications being developed by the OpenID Foundation DCP working group specifically for use by US Government agencies at each FAL would be a very valuable enabler for more rapid adoption especially if these profiles could be recognised in some way by NIST
- For fraud management a standardised definition of fraud signals should be defined between NIST, the fraud practitioners and the OIDF Shared Signals Work Group enabling quicker cheaper delivery of interoperability, again aided if there is some ability for NIST recognition
75
• What applied research and measurement efforts would provide the greatest impacts on the identity market and advancement of these guidelines?
76
77
Other Comments
78
79
The glossaries are inconsistent with some terms appearing the glossary appendix of some documentsSuggest separating out the glossary for 800-63 into a separate companion document and doing a consistency check
80
Quite a lot of the feedback for Base, A, and B is editorial so well done for that
81
The C document is clearly less mature than the others and has some significant issues that need to be resoved
82
There is an issue particularly in the C document where entities that deliver components and the capabilities are conflated leading to inaccurate and confusing descriptions and requirements. CSP, Verifier, Federation authority, IDP and RP are all capabilities not entities. One entity could provide more than one of those capabilities.
83
"Intended FAL" seems a flawed concept as it is the "eventual FAL "that matters. Who would use an "intended FAL" that is baked in to an assertion and what for?
84
The requirement for static identifier and key establishment in FAL3 is misleading as there will need to be some level of change to keys over time. The reality is that these clauses mean that it is not possible to register identifiers and keys using a technical protocol and so they will be registered using a human process of some sort and will simply be vulnerable to risks associated with human processes rather than vulnerable to risks in a given technical protocol.
85
For a document that has normative sections there is a great deal of language that is open to interpretation and non-specific. Partly due to the language used but also in part due to some terms being defined in a non-specific fashion or not being defined directly at all. 
One example of a requirement that is not specific and will depend on interpretation yet is in a "normative" section says "IdPs and RPs SHALL employ appropriately tailored security control" - How can "appropriately tailored" be quantified?		Recommendation - Ensure that the normative requirements are specific and measurable and readily identifiable and that there are very clear SHALL statements and SHALL NOT statements in order to reduce optionality. Other phraseology that is not specific and measurable should be avoided
86
Expansion of the guidance on how agencies should handle cases where a person is not able to act for themselves for some reason and as a result needs a delegate to act for them would be valuable. This would not be the same role as "Applicant Reference" or "Process Assistant" and would cover cases where a person is unable to act for themselves for whatever reason. Examples of this might inclide the elderly, young children or people with particular disabilities or health conditions.
87
If there are federal agencies that have age restricted services of any sort then it would seem appropriate to make allowance for some of the particular challenges related to age assurance in the digital identity guidelines.
88
89
90
91
92
93
94
95
96
97
98
99
100