On-chain formats for secondary and tertiary roots of trust

[iFergal]

There are certain disadvantages of using a ledger over a witness pool, namely interoperability outside of the eco-system. However, while witness pools are very well suited to enterprise use cases, for me there is still an open question on how the average user in the Cardano ecosystem selects witnesses in a reliable but simple manner. (in absence of being able to run their own witness networks)

I am still trying to think of a nice way to create an incentive-based eco-system of witnesses and watchers over the Cardano eco-system and stake pools but until then the CF wallet probably needs to use the ledger as a secondary root of trust to buy time and grow adoption of KERI in our eco-system. Even when witness pools pop up in our eco-system, there would be a time period where there aren't enough witnesses, or watchers with reputation etc so this could serve as a base while transitioning.

Hence, I'd like to open a discussion on this topic for those interested.

---

There needs to be an on-chain standard (CIP-10, and CIP-???? for KERI) that supports both secondary and tertiary roots of trust:

• Secondary coming directly from wallets in the ecosystem holding funds.
• Tertiary both as a witness backup mechanism and possibly for a watcher reputation checkpoint.

WebOfTrust/keripy#90 defines a method of marking an AID as backed by a ledger and using a ledger registrar as a hook. Since Cardano uses Ed25519 keys which is a public key primitive in CESR, we can directly convert a ledger registrar AID to an "enterprise" Cardano address only containing a payment part and not a staking part - see CIP-19.

Secondary root of trust: Firstly considering this alone. As a verifier or watcher indexing the chain, I may find:

• a KEL from the registrar address
• a KEL from another address
• a KERL (receipted by the ledger registrar) from the registrar address
• a KERL (receipted by the ledger registrar) from another address

Limiting to just the registrar address is problematic in case the controller needs to rotate ledger registrars is problematic for a verifier if they were only indexing KELs from a pool of Cardano addresses (or a single one), assuming notifying out of band of the registrar address is infeasible for all interactions. I think it's better to allow it to come from any address and globally index the chain:

• This still allows sub eco-systems to restrict to a set of addresses (and not necessary the same as the registrar) as business logic for performance gains while indexing the chain - and it's up to that sub eco-system to remain up to date with the address changes.
• It also allows for use of normal, staked Cardano addresses. This is important as the more ADA staked, the better for decentralisation.

Secondary, the secondary root of trust is the ledger itself. It's up to verifiers and watchers to make sure they are only retrieving key events from the chain, so I don't see the added value of a ledger registrar receipt in the transaction. Receipts means more signatures which means higher tx fees and more chain bloat.

Simply getting a receipt from a ledger registrar API and not the ledger would be wrong so it almost feels like the Cardano transaction itself is the "receipt". (though you need to verify the history of the chain to know the receipt was valid)

This is why I would propose simply: a watcher should index the chain on all addresses for normal KELs and build up an database of AID -> KEL mappings. There could exist an eco-system of global watchers that index the entire chain and provide watcher receipts on their result, which opens the door to reputable watchers of Cardano-backed (secondary root of trust) KELs (with judges etc). If there exists a particular sub eco-system within Cardano, their verifiers/watchers could index a set of predefined addresses that the AIDs of the sub eco-system will use - while still being picked up by global watchers for others outside that sub eco-system.

The caveat here is that if there is no registrar backer, there is simply a seal with e.g. CARDANO_MAINNET and an empty backer list. Further investigation needed if this is problematic to support.

Tertiary root of trust: I've thought less on this and maybe @rodolfomiranda can weigh in but this could include KERLs witnessed by witnesses (as a form of backup) or by watchers as a form of reputable watchers (different to the reputable watchers I described in the last paragraphs).

I think just a KERL is enough to differentiate from secondary root of trust. A judge or watcher that is reading from the ledger the tertiary root of trust receipts from a particular witness/watcher will be looking for a particular AID for that witness/watcher so I don't think there is a need to differentiate between a witness receipt and a watcher receipt.

Duplicitous event log: This should be considered too if it makes sense to also go on-chain. (maybe not necessary for secondary root of trust KELs on Cardano, since the duplicity is already evident - but useful for a tertiary root of trust scenarios to post duplicity from a witness backed KEL)

[rodolfomiranda]

@iFergal , I like the idea of having Cardano as a secondary root of trust for the Cardano community. Submitting the transactions directly to the ledger instead of the Cardano-backer seems to be a good approach. We'll need to standardize that mechanism and detail how they should be validated when reading the chain. The watcher will play a fundamental role to validate the minted KEL.

I think that a trait telling that the AID is backed in Cardano Mainnet should suffice, since they are meaningful for the Cardano Community that should be aware of the corresponding CIP. However we should also leave the possibility to move out of Cardano in an future rotation event by adding witnesses (or other trait)

I'll be happy to collaborate on the CIP and work on a watcher that can read and validate KELs submitted as metadata into the blockchain.

[SmithSamuelM]

@rodolfomiranda @iFergal

However we should also leave the possibility to move out of Cardano in an future rotation event by adding witnesses (or other trait)

Version 2.0 of KERI adds the config trait field, c to rotation and delegated rotation events so that you can change to/from registrar (cardano) backers to regular witness pools with a rotation. Not merely setup at inception.

[iFergal]

Thanks both; and apologies for more delayed response.

@SmithSamuelM Would the idea of having an identifier with the RB config trait (and a seal containing CARDANO_MAINNET for example) but no registrar backer identifier work for a KERI agent? (b=[], bt=0) So if an agent understood how to securely read from CARDANO_MAINNET, they would fetch KELs from there and not care about the Cardano address that created the transaction. (maybe the config trait would be LB for ledger backed then... as there's no "registrar")

If we need to keep the registrar backer identifier in line with WebOfTrust/keripy#90 (and possibly for some keripy code reasons) - no issues! Only curious in case we can reduce the footprint on-chain, and set the rules for what to expect in Cardano watcher code. If this is the case @rodolfomiranda I would probably explicitly say that a watcher must expect KERLs (receipted from registrar) and ignore KELs.

[SmithSamuelM]

@iFergal The point of using a registrar backer identifier was to leverage and repurpose the built in witness identifier list. This provides a public duplicity evident declaration (commitment) to an identifier. What we want to avoid is creating some other mechanism instead of repurposing an existing one. But If there is no utility to such a commitment you don't have to use it. Since any data can be anchored to the KEL via a seal which includes a digest of that data, one can propose a seal format and just use a seal for whatever.

[iFergal]

@SmithSamuelM Thanks, I would first make sure I understand fully the utility in this context before closing the door to it. :) In this scenario (public permissionless blockchain), we will have public access to KELs protected by the ledger. So I'm curious of there is utility of a declaration made by a registrar that I'm missing.

I guess if the registrar is the entrypoint to a ledger (posts transactions), then it could provide a receipt to the controller that it has seen the KEL, and as such a controller would expect it must be on the ledger after a certain period of time. Not sure if this is a strong enough utility. Mostly because I think we'll have hybrid SSI/crypto wallets that can submit the KEL on-chain without an intermediary registrar - since transactions cost money. And enterprise use cases can run witness pools instead.

[SmithSamuelM]

It depends on how transactions are entered on the ledger. It may be that the same key pair for KEL's Contoller AID is the "address" used to enter transactions on the ledger, but then that would only work if the AID was single Sig since most ledgers do not support multisig and even in the single sig case one woukd have to enter rotation events twice once for the key pair before the rotation and one after which is entirely problematic. So in general the "address" the enters transactions on the ledger has a different key state than the KELs AID. Alternatively one could let any address work but then in the case of key compromise there could be multiple inconsistent (duplicitous) copies of the KEL on the ledger at the same time. So one approach would be to have multiple ledger registrars declared like witness pool with a threshold and now each registrar is itself highly available because its transactions are backed by the ledger. This protects in case one of the registrars addresses gets compromised which can be recovered from by rotating in a replacement registrar. So when you consider that any address on a ledger might have its private keys compromised and any AID controller might have its private keys compromised at some time in the past then you start to have to consider how to either recover or protect against duplicity. As you know were there a surprise quantum attack on key pairs almost no ledger would be safe they would almost all fail catastrophically. So the only thing you can depend on with a ledger is a type of high availability given there is no key compromise ever. Unlike KERI which is duplicity evident by design, Ledgers are duplicity hiding by design. If the private key of a ledger address are compromised there is no way for a verifier to detect it because whatever is written to the ledger is absolute truth.

[iFergal]

Alternatively one could let any address work but then in the case of key compromise there could be multiple inconsistent (duplicitous) copies of the KEL on the ledger at the same time.

Any address was the plan I was considering, but only in absence of registrar identifiers. However I understand your point. In case of key compromise of an old rotation key (since current is protected by pre-rotation), the ledger could have duplicitous KELs.

Though I had also intended to have the same "first seen" rule witnesses have, when using a ledger in this setup. First seen next event (on any address) in the order of the ledger wins, others thereafter are discarded and considered to be from old compromised keys.

Not sure if there are any recovery or timing (w/ ledger delay) issues with this approach though. So if there is I would for sure opt to keep registrar identifiers.