Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WORK ITEM: NIST Digital Identity Guidelines Community Comments #145

Closed
wyc opened this issue Jul 24, 2020 · 33 comments
Closed

WORK ITEM: NIST Digital Identity Guidelines Community Comments #145

wyc opened this issue Jul 24, 2020 · 33 comments
Assignees
@ChristopherA @wyc @kenhuangus @creatornader
Labels
accepted Accepted work items/registries proposed work items Abstracts for potential work for approval by the community group

Comments

@wyc
Copy link
Contributor

wyc commented Jul 24, 2020 •
edited
Loading

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
@wyc wyc added the proposed work items Abstracts for potential work for approval by the community group label Jul 24, 2020
@wyc wyc changed the title [PROPOSED WORK ITEM] NIST Digital Identity Guidelines Community Feedback [PROPOSED WORK ITEM] NIST Digital Identity Guidelines Community Comments Jul 24, 2020
@ChristopherA
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

wyc commented Jul 24, 2020

@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
Copy link

@wyc Yes， I confirm.

@wyc
Copy link
Contributor Author

wyc commented Jul 24, 2020

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
Copy link

creatornader commented Jul 24, 2020 •
edited
Loading

@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
Copy link

tkendal commented Jul 24, 2020

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
Copy link
Contributor

+1 to being a co-owner.

@wyc
Copy link
Contributor Author

wyc commented Jul 24, 2020

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
Copy link

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
Copy link

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

@wyc
Copy link
Contributor Author

wyc commented Jul 28, 2020 •
edited
Loading

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
Copy link

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
Copy link
Contributor Author

wyc commented Jul 29, 2020

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
Copy link

David-Chadwick commented Jul 29, 2020 via email

@kenhuangus
Copy link

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

@kenhuangus
Copy link

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
Copy link
Contributor

vsnt commented Jul 30, 2020

+1 this is a great new work item.

@EmilyFry
Copy link

EmilyFry commented Aug 4, 2020 •
edited
Loading

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
Copy link
Contributor Author

wyc commented Aug 4, 2020

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

@wyc wyc changed the title [PROPOSED WORK ITEM] NIST Digital Identity Guidelines Community Comments WORK ITEM: NIST Digital Identity Guidelines Community Comments Aug 4, 2020
@agropper
Copy link

agropper commented Aug 5, 2020

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
Copy link

agropper commented Aug 5, 2020

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
Copy link

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
Copy link

@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
Copy link

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

@David-Chadwick
Copy link

David-Chadwick commented Aug 10, 2020 via email

@wyc
Copy link
Contributor Author

wyc commented Aug 11, 2020

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

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
Copy link

kenhuangus commented Aug 11, 2020 via email

@wyc
Copy link
Contributor Author

wyc commented Aug 13, 2020

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 kimdhamilton added the accepted Accepted work items/registries label Aug 20, 2020
@kimdhamilton
Copy link
Contributor

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

@kimdhamilton
Copy link
Contributor

Ok to close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ChristopherA ChristopherA

@wyc wyc

@kenhuangus kenhuangus

@creatornader creatornader

Labels
accepted Accepted work items/registries proposed work items Abstracts for potential work for approval by the community group
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@ChristopherA @agropper @wyc @kenhuangus @David-Chadwick @kimdhamilton @vsnt @creatornader @tkendal @EmilyFry