Re: Use of cryptography with W3C VCs and DIDs released

> I feel its recommendations are largely bad long-term decisions.

Christopher, originally I read your message as being against all of the recommendations. Personally, I find at least the first couple recommendations fairly reasonable. Would you be willing to be more explicit about which recommendations, if any, you don’t find to be largely bad long-term decisions? Is there any common ground?

Sent from my iPhone

> On Apr 22, 2022, at 12:30 AM, Christopher Allen <ChristopherA@lifewithalacrity.com> wrote:
> 
> 
>> On Thu, Apr 21, 2022 at 10:54 AM Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
>> SRI International has publicly released their independent review on the use of
>> cryptography in W3C VCs and DIDs and made some recommendations:
>> 
>> Cryptography Review of W3C Verifiable Credentials Data Model (VCDM) and
>> Decentralized Identifiers (DIDs) Standards and Cryptography Implementation
>> Recommendations by David Balenson & Nick Genise
>> 
>> http://www.csl.sri.com/papers/vcdm-did-crypto-recs/
>> 
>> It's largely a view from the US NIST cybersecurity standards, which are used
>> through most of the world, but not everywhere. In any case, it's a valuable
>> perspective that I hope the VC2WG and DIDWG takes into the next stage of the work.
> 
> Though I appreciate the hard work that went into this document (including some support from our community) I ended up having a strong visceral reaction to it as I feel its recommendations are largely bad long-term decisions. If you want to do business with the US Government and its allies (aka LESS "Legally Enabled Self-Sovereign" Identity), you will have to use them. However, about the only thing I agree with is that we should start to transition away from SHA-256, initially maybe to SHAKE256 (though I have other nuances not considered by this report given VRFs, Schnorr and ZK-proofs opportunities).
> 
> I feel there is some urgency here because I have colleagues in both Ukraine & Russia that are effectively out of business, and I fear for others in Taiwan. I fear for progressive countries changing their rules, especially given the re-election of Orban in Hungary, continued leadership by Morawiecki in Poland & Bolsonaro in Brazil (among many others), possible election of LePen in France or Trump (or a Trump ally) in the United States. Many other authoritarian threats are rising around the world.
> 
> Recently even in more progressive countries there is evidence and movement toward using digital technologies to control people that I feel risk human rights or violate human dignity. Canada closed protestors bank accounts (and thus their ability to make a living) without using court hearings, state-controlled central-bank cryptocurrencies are being proposed around the world with high coercion risks, and public acceptance of Covid inspired initiatives for legitimate public-health purposes are inspiring similar approaches for more questionable purposes.
> 
> This means that we must fight harder for more decentralized, more correlation & coercion resistant digital identity technologies. I don't believe we can do this with an incremental upgrade of our current digital infrastructure — there are too many "invisible architectures" (see http://www.astrodigital.org/space/stshorse.html for an example) from early choices made during the 80s (X.509, expense computationally to make and secure key on 1990s CPUs, etc.) that make the cryptographic choices today in DID 1.0, VC 1.1, technologies like JOSE/JWT/JSON-LD, and systems like OIDC problematic. I helped architect and have actively supported the basic design concepts behind DIDs & VCs for the last 6 years, but I don't support their current cryptographic implementation practices.
> 
> None of my diatribe here is to say that working toward government-focused LESS Identity solutions are a waste of effort. They just are not sufficient for the long-term — being pragmatic today is not good enough.
> 
> I personally am forking from DID 1.0, with a hope that maybe someday we can merge these concepts back into DID 2.0 someday. Here are some of my early ideal design thoughts & principles:
> 
> * Architect proactively for user independence (aka self-sovereign), privacy focused on correlation-resistance & coercion resistance, use cases to support human rights and dignity, AND support user resilience and reliability.
> * Multikey first. This means Distributed Key Generation (DKG), aggregatable threshold signing & proofs, collaborative identifier and key rotation, and collaborative identity recovery (not just social network key recovery, but also recovery facilitated by personal IoT devices, cloud services, and a personal choice of other responsible entities) using technologies like VSS, Music2, FROST, ZK-STARKS, etc.
> * All identifiers must have rotable key material, and such key material should be minimally used (say an KERI-style inception key that is immediately used to rotate, or a blockchain UTXO that is immediately spent).
> * Minimize key reuse, avoid using keys for multiple purposes, separate derived keys from the sources, support punctuated perfect forward secrecy, 
> * ECDSA , AES and SHA-2 should largely be transitioned out and retired.
> * By default all public keys should be considered to to represent multisig collaborative controllers, whether that is a key created in a VSS or Musig2 or FROST collaborate ceremony between multiple devices held by a single individual (say a mobile phone, smart ring or watch, and a cloud service), or by a dyad for P2P (Adam and Bart have a single public key that can only be used in signing when they cooperative), or triads and up (some form of aggregatable threshold quorum, such as 2 of 3, 4 of 9, 50+1 of many, supermajority, consensus but not unanimity, etc.)
> * Signatures and proofs should largely use aggregatable multisign Schnorr, which currently only can be done safely on secp256k1 or ristretto255 style curves (not NIST r1 or 25519).
> * Leverage the possibilities of Schnorr for atomic operations, adapter signatures, blind signatures, scriptless scripts, smart signatures, etc. as well as leverage the DKG & VSS pre-cursors to group Schnorr.
> * Don't allow public keys, signatures, and other proofs to be correlatable — leverage VRFs and related commitment schemes, or Schnorr adapter signatures and scriptless scripts to make even the ability to verify a signature require some process of consent.
> * All key-value assertions signed by default are redactable by the presenter, using a hash tree or certificate transparency-style VRF hash-tree mechanism. Integrate the default redactable support with other forms of selective disclosure (BBS+, etc.).
> * All secrets should be multisig centric, with no Single Points of Failure (SPOF), Single Points of Compromise (SPOC), or Single Points of Denial (SPOD). This means we don't have to rely on a single chip (FIDO), personal device (mobile phone), or service (personal cloud), or ecoystem (Apple, Google), to be able to leverage our secrets, either as individuals or as groups.
> * No single source of authority or vendor lock-in — start with P2P web-of-trust, but anything greater than that is explicitly user choice with multiple options.
> * Trust must be granular - not black or white.  Create Progressive Trust architectures http://www.lifewithalacrity.com/2004/08/progressive_tru.html that may require  require many steps and round-trips, and less risky early trust testing before establishment of long-term trust.
> * Personal choices of roots of trust must not be just acceptable, but preferable. Design to avoid dark patterns of one-time or default trust acceptance (design for modest and safe choices first, educate, request confirmation over time, review periodically, etc.). Avoid risks of process fatigue and desire convenience with cognitive design.
> * Rethink architectures of dedicated cryptographic hardware. Work with silicon vendors so that we don't have to solely rely on single-keys on hardened chips, using legacy cryptography, and address the larger need to avoid supply chain threats.
> * All data is by default encrypted at rest, and encryption may be nested with multiple "permits" to reliably support decryption under different scenarios.
> * Focus on personal trust (aka P2P) first, group aggregated trust (more like key transparency) second, before leveraging blockchain tech. Time-related proofs and commitments are more useful than immutability.
> * Minimize biometrics to their sole use by devices under users control (for instance iPhone-style biometrics).
> * Where human secrets are required (aka "passwords") focus them solely as one factor of many, and leverage more modern techniques OPAQUE rather than the more long-term vulnerable approaches of bcrypt/scrypt-style PAKE. When personal secret is required, leverage psychology of memory and spaced repetition to support greater personal secret entropy.
> * Largely leverage CBOR (but not COSE) for self-describing data, torgaps transports (Tor or I2P - not https), and design for separation of keys and trust services using airgapped and other segregated approaches.
> * Support multiple testing of sources of truth. Ask 3 servers, not one. Support reliability & resilience.
> * Firmly separate authentication from authorization.
> * Leverage cryptographic o-cap for delegatable and attenuable authorization.
> 
> All of my wish list is quite ambitious, but some of them are distinctly possible to start developing now. Blockchain Commons already is beginning to address some of them for use cases in the emerging Bitcoin multisig community, and we now have support from patrons who can implement what we need in silicon or dedicated hardware (such as secp256k1, ristretto255, and Schnorr support in a secure enclave). We have begun to ship reviewed source code (SSKR for social key recovery) for some of the above, have numerous specs, code libraries and POC reference code available, and we have begun creation of methodologies to evaluate the SPOCs and SPOFs for multisig scenarios (see drafs at https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Scenario-Multisig.md and https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Multisig.md )
> 
> Given the current rising community spread of Covid I unfortunately will not be attending IIW next week, however, I am open to discussion with others interested in supporting this more evolved (and radical) approach to decentralized identity. So if you are in the area, I welcome invites to lunch at some convenient outdoor location, and anytime via Zoom. I plan that by September we can try to meet in person at the next Rebooting Web of Trust in the Hague on September 26-30th https://www.weboftrust.info/next-event-page.html.
> 
> I welcome your participation in development of these technologies and tools,  and of course your monthly financial patronage (even if a small $20 a month, your social proof of support is valuable!) at https://github.com/support/BlockchainCommons.
> 
> Offered with hope & optimism that we can do this…
> 
> -- Christopher Allen
>