WORK ITEM: NIST Digital Identity Guidelines Community Comments

[wyc]

New Work Item Proposal:

This is a new Work Item Proposal in response to the Digital Identity Guidelines as published under NIST 800-63-3, mentioned by Nader Helmy to the mailing list on July 22nd:

Hi all,

It came to my attention that NIST is currently in an open review period on their Digital Identity Guidelines as published under NIST 800-63-3.

https://csrc.nist.gov/publications/detail/sp/800-63/4/draft Deadline: August 10

They're seeking feedback on a wide variety of topics to improve the standard, including remote identity proofing, mitigating correlation, and biometric verification. The scope of these regulations is very broad and the open review period seems like a substantial opportunity to provide our input as a community on some practical, real-world identity regulations. I'm sure some of us have already started thinking about this, how might we get organized?

Thanks, Nader

It's important to engage governments to help them understand how technology based on our standards can help protect their citizens and to ensure that recommendations/regulatory requirements make room for or even encourage the adoption of global standards that are inclusively designed. When we don't do this, we run into difficult situations: for example, that the secp256k1 curve is not a NIST curve has caused a divide between enterprise and government usage of smart contract infrastructure. We have a chance to bridge chasms now.

The deadline is coming soon, only 17 days from now on August 10th, 2020. We should begin working sessions next week to:

1. Boil down the text into discussable topics and concerns relevant to VCs + DIDs
2. Solicit further review and involvement from the community
3. Package into a final response to NIST

If we cannot meet the deadline, then we should withdraw any response as opposed to submitting a half-baked one.

See W3C-CCG New Work Item Process.

Include Link to Abstract or Draft

e.g. google doc or your github repo TBD

List Owners

Identify 1 lead (person responsible for advancing the work item) and at least 1 other owner. Ideally, include their github usernames

• Nader Helmy (@creatornader)
• [LEAD] Wayne Chang (@wyc)
• Ken Huang (@kenhuangus)
• Christopher Allen (@ChristopherA)

[ChristopherA]

I am interested in this work item. I presented on this topic before the IESG CFRG of the IETF (I know, a handful of acronyms, but basically the subgroup that evaluates cryptography in the IETF standards org) https://www.ietf.org/proceedings/interim-2017-cfrg-01/agenda/agenda-interim-2017-cfrg-01-cfrg-01-02

I now longer have access to those google slides (former company), but the a copy is at https://www.scribd.com/document/368847599/Slides-Interim-2017-Cfrg-01-Sessa-Secp256k1-00

I'm interested in participating in this work item, especially if we can focus on shipping something soon rather than some long-term agenda.

-- Christopher Allen

[creatornader]

I’m willing to take this on as co-owner with you, @wyc.

@ChristopherA agreed, the deadline for this round of reviews is August 10 so I think we ought to focus on the highest-priority concerns in a practical, succinct way.

[ChristopherA]

I found a better link for my sec256k1 slides. I believe this could be a great place to start.

https://www.ietf.org/proceedings/interim-2017-cfrg-01/slides/slides-interim-2017-cfrg-01-sessa-secp256k1-00

[ChristopherA]

Some of what is missing from these slides is that secp256k1 is a prime order curve, which has some strengths for things like bulletproofs and multisig. To do this with 25519 have to deviate from that standard to make them prime order with techniques like Ristretto, which cause other complexities. We are not suggesting secp256k1 as an replacement for 25519 or Ristretto, but as an mature alternative with mature cryptoanalysis and code base.

[wyc]

@creatornader because you brought this issue to the group in the first place, would you also like to assume Lead of this proposed work item, responsible for pushing it forward?

@ChristopherA would you like to be an owner of this as well?

@kenhuangus can you confirm that you want to be an owner?

probably will cut off at 4 owners for sake of timelines and coordination costs. we should plan the work item and follow-on work sessions sometime early next week.

[kenhuangus]

@wyc Yes， I confirm.

[wyc]

Great, JFYI, owners are responsible for putting time into moving this effort forward and contributing directly to the output. If anyone's schedule no longer allows for time commitment, it's totally understandable but please communicate that immediately.

[creatornader]

@wyc happy to be an owner of this item but I'm not very familiar with the CCG new work item process. Perhaps you can serve as lead while I learn the ropes, especially since this is such a quick turnaround? I can definitely put time into this and contribute to the output. Lmk, I'm open to suggestions

[tkendal]

Thx @wyc ...interested in watching (closely). This looks to be directly aligned with a pilot/network I'm managing in CO -- Colorado Cybersecurity Opportunity Coalition (CO3).

[ChristopherA]

+1 to being a co-owner.

[wyc]

Sure, I'll take lead on this. Will schedule a time to sync for early next week. I've sent owners an email containing a Doodle scheduling link to take your preference.

[kenhuangus]

There are four documents in scope for the comments: SP 800-63-3 SP 800-63A SP 800-63B SP 800-63C

I had the opportunity to skim through them today and here are my initial thoughts

1: The “Digital Identity Guidelines” focus on centralized identity. 2: There is NIST’s white paper entitled “A Taxonomic Approach to Understanding Emerging Blockchain Identity Management Systems” on decentralized identity summarize W3C’s DID work, we can find the document here: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01142020.pdf 3: The comments we can provide can start from “Note for Reviewer”. Specifically, the following notes （from： https://csrc.nist.gov/publications/detail/sp/800-63/4/draft）：

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.

[creatornader]

We've started gathering notes in this document: https://docs.google.com/document/d/1kk8SRKp9Zb7-QwDVpqcebH_2navTU8jnnM215iOgbTE/edit?usp=sharing

[wyc]

Next steps after meeting for owners:

• Go through documents A, B, C, D and identify specific sections that could benefit from changes.
• Classes of changes TBD, but may include verbiage, referencing our work with IETF, OpenID, Kantara, etc. and more categories TBD
• Come up with rubric of changes that a reviewer familiar with W3C VC + DIDs can use to evaluate these sections.

[kenhuangus]

For Document 800-63A: 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, ...."

W3C CCG Group Comments:

_The DID identifier or the hash of the identifier can be used as a unique alternative identifier to the SSN. For further privacy, the pairwise DID identifier can be used. The DID identifier is meaningless by itself, but globally unique;it does not leak PII or any sensitive data. Public exposure of the DID identifier does not allow for it to be used as an authenticator or shared secret without a digital signature and DID Auth process. Verifiable Confidential and DID document can be constructed using context property to allow use the same DID identifier within same context. For example, for any government service, under user’s consent, the same DID identifier can be used across systems, agencies and organizations without compromising its security and privacy properties.

As reference, we would like to refer to the following two items:

1)DHS RFP: Preventing Forgery & Counterfeiting of Certificates and Licenses (Release 2) SVIP OTS Call 70RSAT19R0000002/0001 Scenario I: Alternative Identifier to the Social Security number. This RFP is seeking alternative identifier to SSN.

2)In the “ Note for Reviewer” NIST is also particularly interested in comments and recommendations for the following topic: “Privacy enhancements and considerations for identity proofing, authentication, and federation, including new developments in techniques to limit linkability and observability for federation”_

[wyc]

Great find Ken!! That DHS is specifically funding projects working on this problem is really relevant. I feel that there are two categories of comments we can leave:

General observations and relevance Opining on sections on how they are related to our work. This category seems most relevant to the community to learn its relationship to the problems that NIST and other government bodies are working on/interested in.

Potential changes or additions to the current text This seems to be what they're really after. If we can somehow turn comments of the previous category into material changes to the text, I think it would be most likely to make lasting impact. From the Note to Reviewers in the prompt:

This request for review presents several topics for which NIST is requesting federal agency and industry review and comment for potential changes or additions to the current text.

[David-Chadwick]

On 29/07/2020 18:03, Ken Huang wrote:

For Document 800-63A: 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, ...."

W3C CCG Group Comments:

_The DID identifier or the hash of the identifier can be used as a unique alternative identifier to the SSN. For further privacy, the pairwise DID identifier can be used. The DID identifier is meaningless by itself, but globally unique;it does not leak PII or any sensitive data.

I think that you will find that according to GDPR, a DID is PII. It uniquely identifies the subject. Furthermore it can be used as a correlating handle if it is not a pairwise one.

Kind regards

David

Public exposure of the DID identifier does not allow for it to be used as an authenticator or shared secret without a digital signature and DID Auth process. Verifiable Confidential and DID document can be constructed using context property to allow use the same DID identifier within same context. For example, for any government service, under user’s consent, the same DID identifier can be used across systems, agencies and organizations without compromising its security and privacy properties.

As reference, we would like to refer to the following two items:

1)DHS RFP: Preventing Forgery & Counterfeiting of Certificates and Licenses (Release 2) SVIP OTS Call 70RSAT19R0000002/0001 Scenario I: Alternative Identifier to the Social Security number. This RFP is seeking alternative identifier to SSN.

2)In the “ Note for Reviewer” NIST is also particularly interested in comments and recommendations for the following topic: “Privacy enhancements and considerations for identity proofing, authentication, and federation, including new developments in techniques to limit linkability and observability for federation”_

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/145#issuecomment-665785629, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA33R76YGJQF62ZIPNYT7BTR6BI6RANCNFSM4PG4ILHA.

[kenhuangus]

@David-Chadwick Good point. In some use cases, one-time use DID Identifier or Pairwise DID identifier can be used.

[kenhuangus]

for 800-63 B Section 9.3: Use Limitation

"...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. CSPs can determine appropriate measures commensurate with the privacy risk arising from the additional processing. For example, absent applicable law, regulation or policy, it may not be necessary to get consent when processing attributes to provide non-identity services requested by subscribers, although notices may help subscribers maintain reliable assumptions about the processing (predictability). Other processing of attributes may carry different privacy risks that call for obtaining consent or allowing subscribers more control over the use or disclosure of specific attributes (manageability). Subscriber consent needs to be meaningful; therefore, as stated in Section 4.4, when CSPs use consent measures, acceptance by the subscriber of additional uses SHALL NOT be a condition of providing authentication services."

Potential W3C CCG comments：

In some use cases, Selective Disclosure and Zero-Knowledge Proof in Verifiable Claim can be leveraged when individuals are not expecting or comfortable with the additional processing of identity attributes.

[vsnt]

+1 this is a great new work item.

[EmilyFry]

This is great work. I have reviewed parts of the guidelines separately which I will add into the google doc. Perhaps we could structure our feedback according to the topics provided by NIST (below), and any feedback not relevant to one of those topics we put under the topic 'other'.

• 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._

[wyc]

@EmilyFry great suggestion, thanks for your additions! Ultimately we should put this into a repository, which I can make tomorrow, to adhere to the community group's IPR procedures for Work Items. I should also be able to send an email out to invite some comments from the mailing list on each of those points, for which I'm sure the community would have interesting thoughts. I believe we can think of some relevant discussions that we've had in our community for just about each of those points, and it would be a matter of providing summary and reference.

[agropper]

I think that you will find that according to GDPR, a DID is PII. It uniquely identifies the subject. Furthermore it can be used as a correlating handle if it is not a pairwise one. Kind regards David

I don't think the GDPR definition of PII is relevant in this NIST context. The choice of correlation risk is always in the hands of the subject with DID and a DID is itself opaque as long as the service endpoints, if any, do not introduce a point of correlation.

[agropper]

short comments inline...

This is great work. I have reviewed parts of the guidelines separately which I will add into the google doc. Perhaps we could structure our feedback according to the topics provided by NIST (below), and any feedback not relevant to one of those topics we put under the topic 'other'.

* Privacy enhancements and considerations for identity proofing, authentication, and federation, including new developments in techniques to limit linkability and observability for federation.

Point to DHS SVIP SSN replacement by DID with a few specific details / examples.

* Continued use of short message service (SMS) and public switched telephone networks (PSTN) as restricted authentication channels for out-of-band authenticators.

Verification is always a good thing. Another important case, in healthcare, is verifying an insurance ID where the incentive is getting paid. There may be a subtle difference between verification of the identifier and authentication of the identity thay might be worth addressing in SSI terms.

* 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.

It would be good to describe how photos and other biometrics can be used with DIDs.

* 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.

KBA is a huge problem for society as a whole because it encourages widespread surveillance for profit. It will further drive us in the direction of Chinese Social Credit Scores. We need to offer SSI as part of the solution to making KBA illegal.

* 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._

[David-Chadwick]

I think that you will find that according to GDPR, a DID is PII. It uniquely identifies the subject. Furthermore it can be used as a correlating handle if it is not a pairwise one. Kind regards David

I don't think the GDPR definition of PII is relevant in this NIST context. The choice of correlation risk is always in the hands of the subject with DID and a DID is itself opaque as long as the service endpoints, if any, do not introduce a point of correlation.

Why do you say that GDPR is not relevant for the NIST guidelines? I know that the US does not have a national equivalent of GDPR, but GDPR is international and will affect any US organisation that handles PII in Europe or the PII of Europeans outside of Europe. So my view is that replacing the SSN with a DID is equivalent in terms of it being a unique identifier of the individual. Whether that individual has one or many unique identifiers is irrelevant if they all uniquely identify that individual. Remember that the IP address that you are using is regarded as PII in GDPR.

[David-Chadwick]

@David-Chadwick Good point. In some use cases, one-time use DID Identifier or Pairwise DID identifier can be used.

One time use DIDs are certainly the best from a privacy perspective, since you wont be able to use them subsequently to contact the user again (although via audit trails you should still be able to use them to identify the user at the time the DID was used). Pairwise DIDs can be used in perpetuity to identify and contact the user so are persistent PII.

[creatornader]

A new repository has been set up for this work item here: https://github.com/w3c-ccg/nist-dig-comments

[David-Chadwick]

I have added a comment to it, which I will repeat below

Replace

The DID identifier is meaningless by itself, but globally unique;it does not leak PII or any sensitive data

with

Whilst the DID identifier is a globally unique identifier, and thus is PII, nevertheless it is meaningless by itself. It does not leak any additional PII or sensitive data.

Kind regards

David

On 10/08/2020 03:43, Nader Helmy wrote:

A new repository has been set up for this work item here: https://github.com/w3c-ccg/nist-dig-comments

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/145#issuecomment-671139989, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA33R74S462TEQA2DUI7JXLR75NGHANCNFSM4PG4ILHA.

[wyc]

@EmilyFry I have added your comments into the main work item via this commit: https://github.com/w3c-ccg/nist-dig-comments/pull/4/commits/311f548b6a427b935f60529c0a3485a1a5d59ba7

I've also listed you as an Editor due to the substantial nature of your additions--please reach out directly if this is problematic. Thank you so much for your contributions; our response is far more complete for it.

[kenhuangus]

I reviewed @EmilyFry https://github.com/EmilyFry , excellent additions. Thank you!

On Mon, Aug 10, 2020 at 8:41 PM wyc notifications@github.com wrote:

@EmilyFry https://github.com/EmilyFry I have added your comments into the main work item via this commit: w3c-ccg/nist-dig-comments@311f548 https://github.com/w3c-ccg/nist-dig-comments/commit/311f548b6a427b935f60529c0a3485a1a5d59ba7

I've also listed you as an Editor due to the substantial nature of your additions--please reach out directly if this is problematic. Thank you so much for your contributions; our response is far more complete for it.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/145#issuecomment-671658987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOIPWIIIHUVN46EW4VVS6TSACHS7ANCNFSM4PG4ILHA .

[wyc]

To do:

• Make work item entry
• Close this issue

Please make future contributions as PRs to https://github.com/w3c-ccg/nist-dig-comments from now on.

[kimdhamilton]

TODO: https://w3c-ccg.github.io/create_work_item.html

[kimdhamilton]

Ok to close