Excerpts from the MIT Kyber patent license: https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf — What do you think @kemitchell @lifeext @brianbehlendorf?

Fri Dec 02 04:32:24 +0000 2022

It looks like NIST has selected Kyber https://pq-crystals.org/kyber/index.shtml for post-quantum encryption, and has negotiated a royalty-free patent license by the parties if usage conforms to the standard (ala ECDSA in the 90s). But I doubt it will pass muster with the open source community.

Fri Dec 02 04:32:24 +0000 2022

We have submitted “The Envelope Structured Data Format” to the IETF as an Internet-Draft, and it is now available at https://datatracker.ietf.org/doc/draft-mcnally-envelope/

ABSTRACT: The envelope protocol specifies a structured format for hierarchical binary data…

Fri Dec 02 21:14:05 +0000 2022

…focused on the ability to transmit it in a privacy-focused way. Envelopes are designed to facilitate “smart documents” and have a number of unique features including easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, …

Fri Dec 02 21:14:07 +0000 2022

…deterministic representation using CBOR, and the ability for the holder of a document to selectively encrypt or elide specific parts of a document without invalidating the document structure including the digest tree, or any cryptographic signatures that rely on it.

Fri Dec 02 21:14:08 +0000 2022

Replying to @BitMEXResearch

You might also want to look at Gordian Envelope, which also uses hash trees for privacy. https://twitter.com/ChristopherA/status/1598787610805436416

Sat Dec 03 22:52:55 +0000 2022

RT @317070: Did you know, that you can build a virtual machine inside ChatGPT? And that you can use this machine to create files, program a…

Sun Dec 04 00:49:09 +0000 2022

RT @btnaughton: @317070 this is mind-bending

Sun Dec 04 00:49:19 +0000 2022

Trust Architecture is one of my major goals at @BlockchainComns. I want to develop systems that help people to create trust on the internet. I’ve started a new series of articles on the topic called “Musings of a Trust Architect”. [1/8] https://www.blockchaincommons.com/musings.html

Wed Dec 14 01:00:47 +0000 2022

My first Musings article talks about Progressive Trust. How do we make online trust match real-world experiences, where we gradually get to know someone and expose little bits of knowledge about ourselves as we do? [2/8] https://www.blockchaincommons.com/musings/musings-progressive-trust/

Wed Dec 14 01:00:48 +0000 2022

This is very different from traditional trust mechanisms on the internet, which depend on authentication or require that you be in a trusted zone. Generations of hackers have shown these defenses are easily defeated. [3/8]

Wed Dec 14 01:00:50 +0000 2022

Progressive trust is going to require technologies like data minimization, elision/redaction, escrowed encryption, and various cryptographic selective disclosure techniques. Cryptography can support how we really grow trust over time! [6/8] https://www.blockchaincommons.com/introduction/Envelope-Intro/

Wed Dec 14 01:00:51 +0000 2022

Real trust requires support for the autonomy and agency of all parties. That’s where Progressive Trust comes in: trust as we experience in real life. Read my article for why. [5/8] https://www.blockchaincommons.com/musings/musings-progressive-trust/

Wed Dec 14 01:00:51 +0000 2022

Newer zero-trust mechanisms have come to depend on trust frameworks or trust registries. They have many problems, including centralization, inconsistent updates, and the possibility of third-party bias. [4/8]

Wed Dec 14 01:00:51 +0000 2022

To support this type of work at Blockchain Commons, please become a sponsor. [8/8] https://github.com/sponsors/BlockchainCommons

Wed Dec 14 01:00:52 +0000 2022

How else do online models fail real-life models of trust? What other technologies can help them to succeed? I’d love to hear your feedback too! Trust architectures are ever-evolving! [7/8]

Wed Dec 14 01:00:52 +0000 2022

Replying to @rot13maxi, @geyserfund and @BtcpayServer

We do accept bitcoin at https://btcpay.BlockchainCommons.com — Thanks! 🙏

Wed Dec 14 03:51:20 +0000 2022

Replying to @rot13maxi, @geyserfund and @BtcpayServer

I don’t know if you’ve seen our Bitcoin projects, like Learning Bitcoin from the Command Line, our #SmartCustody book for self-sovereign assets, and our work towards better multisig wallets. All available on Github.

Wed Dec 14 03:53:22 +0000 2022

Replying to @mbrandolph

I wrote in 2006 an article on my adventures on being an angel investor. Like you, I was good at identifying good startups. The challenge is that when they are successful, the deck is stacked against the angel. http://www.lifewithalacrity.com/2006/01/on_being_an_ang.html

Wed Dec 14 04:02:59 +0000 2022

But the newest RWOT paper talks about more than that. How do we manage cross-border, multi-jurisdictional usage, especially with modern data protection laws such as the GDPR? [3/9]

Fri Dec 16 21:58:46 +0000 2022

Prescriptions have always been a great use case for self-sovereign identity. You should be able to control your prescriptions. You should be able to move them without being beholden to pharmacists and corps. We published this at #RWOT2 in 2016 [2/9]. https://github.com/WebOfTrustInfo/rwot2-id2020/blob/master/final-documents/physician-patient-relationship.pdf

Fri Dec 16 21:58:46 +0000 2022

I am pleased to see the second paper from our #RWOT11 The Hague today: “Linking Credentials with Data Exchange Agreements through Secured Inclusive Interfaces,” by a team led by @philippePage1 & @lalchandran 🧵[1/9]. https://twitter.com/RWOTEvents/status/1603840047559475200

Fri Dec 16 21:58:46 +0000 2022

It’s an interesting paper! Take a look! [8/9] The pdf at https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/data-exchange-agreements-with-oca.pdf or markdown https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/data-exchange-agreements-with-oca.md

Fri Dec 16 21:58:47 +0000 2022

Also, that VERIFIABLE CREDENTIALS might be less relevant than VERIFIABLE INFORMATION [7/9]

Fri Dec 16 21:58:47 +0000 2022

The paper’s conclusions: Naked VCs do not scale, they must be dressed! [6/9]

Fri Dec 16 21:58:47 +0000 2022

Fortunately, we’ve also seen lots of technical development since 2016. The RWOT paper talks about that with Data Exchange Agreements (DEXA) and introduces an Overlay Capture Architecture (OCA). [5/9]

Fri Dec 16 21:58:47 +0000 2022

How do we ensure that prescriptions (and other data) remains accessible to all people? [4/9]

Fri Dec 16 21:58:47 +0000 2022

Sign up to get notification of future Rebooting Web of Trust Events at our web page! [9/9] https://www.weboftrust.info/subscribe/

Fri Dec 16 21:58:48 +0000 2022

There is new functionality available now for Gordian Envelopes to support the ability to produce a set of edits (a “diff”) that will transform one Envelope’s graph data into another Envelope. 🧵[1/8]

Mon Dec 19 22:27:40 +0000 2022

In addition, every Envelope diff is also itself an Envelope. Thus the edits can be authenticated by signing, encrypted, or anything else that Envelopes can do. [4/8] https://youtu.be/3G70mUYQB18

Mon Dec 19 22:27:41 +0000 2022

This diffs function offers support for both semantic equivalence and structural identicality and supports diffs between Gordian Envelopes that contain elided and encrypted data. Docs: [3/8] https://github.com/BlockchainCommons/BCSwiftSecureComponents/blob/master/Docs/11-DIFFING.md

Mon Dec 19 22:27:41 +0000 2022

Gordian Envelopes are a new type of “smart document” to support the storage, backup, encryption & authentication of data, with explicit support for Merkle-based selective disclosure. Here is a high-level introduction: [2/8] https://www.blockchaincommons.com/introduction/Envelope-Intro/

Mon Dec 19 22:27:41 +0000 2022

Contact me if you’d like to become involved in the future of Gordian Envelopes. You can also support the future development of interoperable specs like these by becoming a Blockchain Commons supporter! [8/8] https://github.com/sponsors/blockchaincommons

Mon Dec 19 22:27:42 +0000 2022

We’d like to be able to offer both state-based “convergent replicate states” or non-state-based “commutative replicated” CRDTs. This is a 2023 stretch goal for Blockchain Commons. [7/8]

Mon Dec 19 22:27:42 +0000 2022

By itself, Envelope Diff is most useful for debugging & docs; but it also demonstrates the plausibility of future support of more complex functionality for Gordian Envelopes, such as use in CRDT (Conflict-Free Replicated Data Type) scenarios. [6/8] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

Mon Dec 19 22:27:42 +0000 2022

We also support Envelope diff in the latest version of the Envelope-CLI reference implementation: [5/8] https://github.com/BlockchainCommons/envelope-cli-swift/blob/master/Docs/9-DIFFING.md

Mon Dec 19 22:27:42 +0000 2022

I have been worried for some time that the plans to reorganize the W3C international standards org, which has a very weird legal 3-party setup, would go awry. It looks like the reorg may be failing, as MIT is not cooperating. https://twitter.com/robinberjon/status/1603834995830816769

Mon Dec 19 23:32:47 +0000 2022

RT @kanzure: “Towards a more open secure element chip”

1) blag https://www.bunniestudios.com/blog/?p=6606
2) discuss https://news.ycombinator.com/item?id=34061511
3) join workshop…

Wed Dec 21 02:41:52 +0000 2022

Replying to @HirokiSayama

Feels like some organizational principles are missing, from the human side (like Ostrom’s Commons, participatory orgs, group size issues) to the computer side (such as decentralization, computer consensus, incentive design, etc)

Wed Dec 21 23:57:31 +0000 2022

Replying to @HirokiSayama


Wed Dec 21 23:58:15 +0000 2022

Replying to @HirokiSayama


Thu Dec 22 00:00:47 +0000 2022

Replying to @HirokiSayama

Lots more links available, not so organized.

Thu Dec 22 00:01:14 +0000 2022

Replying to @VictorTaelin

Have you reached out to Russell O’Connor of @Blockstream? His Simplicity language is also based on a lambda calculus.

Thu Dec 22 00:13:39 +0000 2022

Replying to @cronokirby and @MarciIlunga

We do that on our submission of Gordian Envelope to IETF. Instead of specifying a particular AEAD, we specify an AEAD in general first. Then we show us cha-cha poly. See section 3.2.3 of https://www.ietf.org/id/draft-mcnally-envelope-00.html#section-3.2.3

Thu Dec 22 00:26:47 +0000 2022

Another collaborative paper has been published by @RWOTEvents from this fall’s #RWOT11 event in The Hague: “Verifiable Issuers & Verifiers” from a team led by @manusporny [1/7] https://twitter.com/RWOTEvents/status/1605020738431291392

Fri Dec 23 00:01:17 +0000 2022

But it turns out there is a real need for Verifiable Verifier lists too. Who is allowed to see what credentials? How can we automatically minimize what any person can see? There are use cases for that too! [4/7]

Fri Dec 23 00:01:18 +0000 2022

To explain the need, the paper outlines medical, employment, financial, and (yes) educational use cases for Verifiable Issuer lists. They support accreditation, certification, supply-chain issues and more. [3/7]

Fri Dec 23 00:01:18 +0000 2022

The need for Verifiable Issuers is old. In the past, governments and other agencies have kept lists of Trusted Registries that could issue credentials — such as universities, who can issue diplomas. However, digitally sharing lists of Verifiable Issuers is quite new. [2/7]

Fri Dec 23 00:01:18 +0000 2022

If you’d like to be part of the discussion, take a look at the full paper. [7/7] https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/verifiable-issuers-and-verifiers.pdf

Fri Dec 23 00:01:19 +0000 2022

After being incubated at RWOT11, “Verifiable Issuers & Verifiers” was introduced for discussion at the 35th #IIW, and the authors suggest that future technical specs could be overseen by the W3C CCG [6/7] https://w3c-ccg.github.io

Fri Dec 23 00:01:19 +0000 2022

The “Verifiable Issuers & Verifiers” paper also covers prior art and unified requirements and offers a concrete data model and plenty of examples. It’s an impressively comprehensive overview of the topic! [5/7]

Fri Dec 23 00:01:19 +0000 2022

We learned over 20 years ago to minimize the reuse of keys, and Bitcoin perfected this. Thus I’m quite concerned that new projects have lost site of this design principle. Same with ENS names and other protocols that don’t support key rotation (or at least ratcheting). https://twitter.com/pippellia/status/1605970280580632578

Fri Dec 23 19:24:03 +0000 2022

RT @pippellia: Using simple public keys like your identity is not a new idea, but it doesn’t work.

Or rather, it works until it doesn’t wo…

Fri Dec 30 23:44:13 +0000 2022

RT @pippellia: Encrypting every message with the same private key for a lifetime is not a good idea.

Thus, this 👇 is the paradox of #Nostr

Fri Dec 30 23:44:23 +0000 2022

RT @pippellia: In Keet, the process of mapping a peer to its public key is done through a Distributed Hash Table (DHT).

In this table, It…

Fri Dec 30 23:45:23 +0000 2022