didit is a placeholder name, sort of like rv2020 - it's vaguely mnemonic, but not so meaningful that it nails down the scope in a way that can't be refined as we go; it doesn't yet have any technical connection to W3C DID work, and the name doesn't force us to take it in that direction.

But I didn't use enough entropy when I made it up. We have a collision with https://didit.com/

some candidates:

• id19 grabbing some entropy from the calendar today
• id1235 grabbing more entropy from the clock just now
• idbdd0 grabbing some from uuidgen -r
• rdawg mixing in daw for digital attestation wallet, but risking a bit more on a marketable name that folks might become attached to

If the whole contents of the wallet is encrypted, how is rholang relevant?

The only cryptographic tools in rholang are signature checking and hashing.

What is a rholang contract expected to do with an encrypted blob?

possible answers:

• this wallet from a rholang perspective is a cell contract to get / set a big encrypted string.
  • the set method can be refined with an addAsset( REVAddr, encryptedPayload ) implemented in a Scala wallet API; see discussion below
• only the asset in each (addr, (label, asset)) entry is encrypted

While I welcome comment from the whole community, this issue can only be resolved to my satisfaction by an answer from @leithaus or some other authorized representative of the board; i.e from the folks setting requirements for the 1M REV .

What do we have to do such that it can be used by any other application similar to how google, facebook and similar ids are used to authenticate into various sites and apps that are not controlled by google, facebook etc.

The current market leaders are services such as sovrin. It's permissioned rather than decentralized, but at this point, so is RChain (cf rchain-community/rstake#6 ).

Common cases of writing to the Sovrin Public Ledger are free: DIDs for Individuals (Peer DIDs) and Credential Issuance. In RChain, every deploy costs REV. (There is discussion of sponsored data APIs but not much work has been done.)

sovrin uses technology from what seems to be the most popular self-sovreign identity API, hyperledger indy.

Zero Knowledge Proofs in the Sovrin Network are deployed in production. Perhaps the same essential design could work with RChain, but it's not clear what benefit justifies the effort / risk.

Hyperledger members and governance shows involvement of ConsenSys, IBM, Intel and so on; sidetree have has involvement from Microsoft.

RChain doesn't even get mentioned in the context of events such as IIW 31 Oct 2020.

RChain's architecture has advantages over these designs in that rholang supports scalable cooperation without vulnerability thru capability security. But the Digital Accreditation Wallet design presented Nov 18 makes no use of that. (See also rchain-community/liquid-democracy)

The value proposition of this design is entirely unclear, to me.

So far, this exploration is using a @ts-check dialect of js that supports static analysis with the typescript compiler. I find it to be a pretty good compromise between a type system to support correct-by-construction and the actual runtime environments in the web.

But collaboration with @leithaus (for example, using types to capture requirements) might be smoother using reasoml, i.e. ocaml compiled to js. During a brief time when I had an ocaml project set up well, it was really a blast and reasonml has long been on my list of things I'd like to try out.

cc @fabcotech @9rb @tgrospic @jimscarver