The first paragram reads as a closed system. Consider replacing “the organization’s system” to be more inclusive. Also consider adding more to explaining more about federated/SSO/SSI systems. IAM systems include open, federated, or self-sovereign identities. It is a very large tent. It’s anything that handles individual identity should be privacy-enhancing to the extent it can in the context it has.
What about the other entities involved such as the providers and the relying parties? Does this paragraph need to be here at all? It is generically true that all IAM actions require collecting information and acting on that data. What information is collected depends on the use case. If we expand the definition of IAM to include the other parties, this can work. (See revision in Chris' working copy)
is it true that the use of credentials always leaves digital trails? Perhaps well-designed solutions do not. If the wallet logs the events it engages in, that’s a digital data trail. Also, the verifier would have a log of events. Even if they are well-held and designed, there is always a trail. Is keeping a log on the wallet only an option? Likewise, an RP chooses to keep that information, but use of a digital credential doesn’t guarantee a data trail. It may be highly probable or likely, but not ensured. Consider using “can lead digital data trails”.
We need to expand “builders and implementers” - is this the provider and issuer? Should it also include holder/consumer?
Consider using the language of the diagram to be consistent throughout the charter.
Suggest changing the language from “not captured” to “not addressed.”
re: legal authority of the holder noted on page 3, the “or” in that sentence is an inclusive or, not an exclusive or.
The privacy principles are not actually included here. Maybe remove the words “the following” For the three bullets, the first needs to be moved to a trailing justification, and the remaining bullets need to be the in-scope and out of scope. For out of scope, decisions made by an issuer could be set by regulation of policy regarding what information they collect for the credential itself.
the content of a credential and the purpose of the credential are out of scope, that is an issuers decision. But is this covered by data minimization? The data minimization here only applies to the provisioning from the the leg of the triangle when the issuer issues the credential to the holder’s wallet, because there maybe information information that’s associated with the credential that this NOT issued with the mobile credential.
We have a statement that says what’s in the credential and what the use of the credential is out of scope is out of consistent that you include as many minimized data elements as possible.
Discussing the comment from last week, we are not excluding private-sector implementations that are acting on behalf of the issuer. Maybe this shouldn’t be “on behalf of” but instead should be “dealing with”. A private-sector implementation might sell their product to more entities. The document is definitely biased more towards government credentials; suggestion is that we make this explicit for the reader
There needs to be UC 4, 5, and 6 that Loffie added to Issuers that we’ll need to add to the other sections as well and whether they are in or out of scope for each section. At the start of information for Verifiers, could say “use cases considered for verifiers are UC 1, 2, and 3”, For Issuers say “use cases considered for issuers are UC 4, 5, and 6”
Saving a named copy of the doc, then accepting all suggestions (this will leave the comments alone and let us react more cleanly to the changes.
Concern that Notice is buried under Consent in the Consent & Choice section; Notice has it’s own section (Principle 7). It’s hard to disentangle these related concepts.
Group to go through the document, close out any comments you feel are resolved, and suggest final changes (do not edit)
Join us for our New Three-Part Webinar Series and Share your Input on Draft NIST SP 800-63-4, Digital Identity Guidelines! NIST is hosting a new webinar series to gain critical input on Draft NIST Special Publication 800-63 Revision 4, Digital Identity Guidelines. During these three separate virtual events, NIST moderators will explore different aspects of the guidance with expert panelists and seek additional input from the public via a moderated Slack discussion and extended Q&A. Webinar #1: Digital Identity Risk Management and Assurance Level Selection Details: Thursday, March 02, 2023 1:30–3:00pm ET This webinar will feature a discussion about digital identity risks. Panelists will explore the various lenses through which digital identity can be viewed, the variety and breadth of associated risks, and how those risks might be considered in organizational, societal, and individual contexts. Register Webinar #2: Innovating Identity Proofing Details: Thursday, March 09, 2023 1:30–3:00pm ET This webinar will focus on the changes NIST has made to identity proofing guidance and illicit inputs on how the government and industry can continue to innovate on identity proofing technology and services. Panelists will discuss leading practices in commercial and public sector use cases, emerging trends, areas of continued improvement, and techniques that may provide additional optionality and choice for end users. Register Webinar #3: The Future of Authentication Details: Thursday, March 16, 2023 1:30–3:00pm ET This webinar will focus on the evolving nature of authentication technology and how organizations and NIST are addressing new innovations in the space. Panelists will explore phishing resistant authentication, trends in multifactor authentication, and the challenges with moving on from SMS authentication. Learn More NIST Cybersecurity and Privacy Program Email Questions: dig-comments@nist.gov NCCoE Website questions: nccoe@nist.gov