docs(anoncomms): add identity track

[jm-clius]

Introduces a minimal roadmap for Identity based on the work already proposed (and in-flight) by @jazzz and the Chat Team.

The aim is to have for mainnet:

• a simple accounts model with VLAD-like addresses mapping to an operation log of credential changes
• support for key addition and revocation (account holder only, for now)
• support for multiple devices

[jazzz]

[Pebble] Installation keys is a concept specifically tied to DR (The "device" specific asymmetric private key), who's relevance is in question with DeMLS.

I'd suggest focusing on Ed25519 VerifyingKeys for now which is the requirement for DeMLS.

[jm-clius]

My understanding for our proposed mainnet scope is as simple as:

1. VLAD-style address
2. Active key(s) can be looked up from a (preferably on-chain) registry
3. Keys can be revoked (by account holder)
4. Multi-device support

The FURPS are designed around this end-goal, with intermediate deliverables in mind.

My use of "installation key" was meant to cover (4) in a generic way without precluding (2) and (3) - how would you suggest we include multi-device support in the requirements without pre-designing a solution, or do you suggest we don't include it in our requirements for now?

[jazzz]

how would you suggest we include multi-device support in the requirements without pre-designing a solution

1. An Account has an append-only operation log of credential changes.
2. An Account can have multiple active credentials simultaneously.

or

An identity can hold one or more ~~installation~~ keys.

This is just a naming issue - InstallationKey has a specific meaning. Generallize to all 'keys' or explicitly reference the signature public keys that are needed.

[jazzz]

As features this makes sense for V0.2. It Adds flexibility that any member of the group can keep editing it. However breaks the security model for future visions. Specifically around revocation.

[Sand] F1 says thats there is a private key bound to the account. Simplify and say that the Account key holder can change the account. (Sacrifice Functionality for simplicity)

or

Ensure that the Address is clearly bound to this validation model, so there is no ambiguity in the future.

[jm-clius]

Ah, the main point was meant to be that only keys associated with the account can revoke and add more keys ("authorised current installation" would more clearly have been "installation key held be the account holder"). Thanks - will go with your suggestions below.

F1 is meant to capture the absolute minimum requirement for Testnet v0.2 (which is just a key-pair), but that will also in a generic way be true for the more sophisticated accounts model. I've added more in my reply here.

[jazzz]

I'm suggesting a subtle change here.

1. If any "valid" key can make changes; Then it allows us to simulate social recovery as a feature which is beneficial.
2. If any "valid" key can make changes; Then revocation doesn't really exist in an adversarial model. An attacker that gets a key could remove the other sessions and retain access to the account forever.

From a security focused perspective; The easiest feature would be to use the F1 Key pair for operations.. The Account "RootKey" MUST be used to change an account. This is then a delegate key signing model (with revocation), and advanced features are added latter. This is a known model, with defined properties.

From a developer focused perspective; Approving changes with delegate keys is helpful feature. This would be a unique feature, that makes lives easier as the root key does not need to be maintained. This either comes at the cost of operational security now, or an increase in effort to define the security requirements for this novel approach.

My suggests lean towards adopting the security focused perspective.

[jm-clius]

Right, I see your point. Would you be happy with a formulation that states something "...can be revoked by the account holder"? IMO this could actually match either design choice (i.e., it doesn't preclude us from a design where other valid keys can also make changes, if we add that as a requirement) but doesn't commit to the exact delegation model that allows for "the account holder" to sign changes to the account. I'm trying to state the root functional requirement without prohibiting us from making subtle design changes at a later stage. :)

[jazzz]

Would you be happy with a formulation that states something "...can be revoked by the account holder"?

No blocker. Though, I was using the term "account holder" based the model that account holders held the signing key. That term may confuse people, if not the case.

I'm trying to state the root functional requirement without prohibiting us from making subtle design changes at a later stage. :)

Heard. My proposed changes were specifically with an opposite goal in mind - clearly defining a early/MVP v0.X version which would be altered in the future. Focus was on defining a clear security model which all the consumers can use in planning - while leaving it open as possible.

[Dust] If wanting to have a more generic set of FURPS and then specifying in deliverables, I'd remove the account holder aspects.

e.g. F6: A new installation can be added to an account.
F7: An installation can be revoked

[igor-sirotin]

using the term "account holder" based the model that account holders held the signing key

This is actually how I was reading it, but it seems it wasn't the intention?

I think it's fine to defer the choice of security model from FURPS to spec and keep it generic:
An installation can be revoked.

But then I'd add a +Security section (as @jazzz shows in #444 (comment)):
1. Single-installation compromise must not permit irreversible account takeover.

[jm-clius]

Thanks both! I agree with the suggested changes and implemented here: 2a9f359 This allows us to iterate on a minimal design/security model in the spec without having to update the roadmap.

[jazzz]

There are two "registries".

• There is the location of the Accounts OpLog (Indexed by AccountAddress)
• There is a location where DeMLS publishes KeyPackages. ( Indexed by Installation)

This appears to be solving both?

[jm-clius]

I mostly just attempted to capture both requirements as distinct - whichever architecture we end up using to solve this, we need:

1. Anyone to be able to look up an identity account based on the address
2. De-MLS users to be able to find published key packages (presumably with information retrieved in (1)).

IIUC you're saying that (2) is a de-MLS concern so shouldn't be addressed here?

[jazzz]

Its less about isolating concerns. The problems are just very different yet sound the same.

The storage of Accounts:

• Indexed by Account ID
• Updated when new devices are added, or rotated "rarely"
• Needs be have consensus on the current state. Participants MUST be able to see all op log entries.
• Inherently a Application level concern
• Primary requirement is durability

KeyPacakages Registry

• Indexed by associated signer/installation id
• Updated whenever this installation is added to a conversation; Used once.
• No concensus needed; Group administrators MUST be able to find 'A' keypackage for a signer.
• Direct protocol interaction.
• Primary requirement is Availablity.

They COULD use the same mechanism, however depending on costs that might become COST prohibitive. For V0.2 there is no Blocker.

[jm-clius]

Agree with your analysis above. I'll try to add more functional requirements (perhaps in a follow-up) for key package retrieval. Would you agree though that:

Anyone to be able to look up an identity account based on the address
De-MLS users to be able to find published key packages (presumably with information retrieved in (1)).

would cover in simple form the diverse requirements, while still allowing us to design different (or the same) mechanisms for these two retrieval use cases?

[jazzz]

Anyone to be able to look up an identity account based on the address

Yes. Given an AccountAddress everyone MUST be able to fetch the installations associated with that Account.

De-MLS users to be able to find published key packages (presumably with information retrieved in (1)).

Yes. However there is a privacy implication forming here. Individual KeyPackages and signers SHOULD not be linked to an account if possible. In MLS we specifically treat each member/Keypacakge as a separate isolatable Identity. Credential binding is something that would be Ok for an early MVP but not for a later mainnet release.

[jazzz]

[Dust] My FURPS would look closer to:

Suggested change

	# Identity FURPS
	## Functionality
	1. An identity is bound to at least one cryptographic key whose private part is controlled by the holder.
	2. An identity has a stable, long-lived address that does not change when keys rotate or are revoked.
	3. An identity carries an append-only operation log of credential changes.
	4. An identity can be created without permission from any third party.
	5. An identity can hold one or more installation keys.
	6. A new installation can be added to an identity by an authorised current installation.
	7. An installation can be revoked by an authorised current installation.
	8. An identity is consumable by de-MLS to retrieve the key package for an active installation.
	9. Identity creation is resistant to trivial Sybil attacks.
	10. An identity can be discovered by contacts via address share and registry lookup.
	<!-- ──────── post-mainnet ──────── -->
	11. An identity can hold one or more associations to externally owned identifiers (EoIs).
	12. An identity holder controls which EoIs are disclosed to which counterparty.
	13. An identity can be used to sign in to Logos services using CAIP-122.
	14. An identity supports holder-defined recovery policies (e.g. social recovery).
	15. An identity's operation log supports programmable validation policies, defined by the holder, that govern which mutations are accepted (i.e., full provenance log implementation).
	## Usability
	1. The basic identity protocol (address format, operation log, contact discovery flow) is published in a specification.
	2. The registry interface (lookup, write authorisation) is published in a specification.
	3. The identity library is implemented in Rust.
	4. The identity library is available via C-bindings.
	5. The identity library is integrated into a working Logos Chat module deployed to Logos Core.
	6. The registry is implemented on the Logos Blockchain (as an LEZ program or as a dedicated Identity Zone).
	7. The registry backend choice on the Logos Blockchain (LEZ program vs dedicated Identity Zone) is evaluated and documented.
	<!-- ──────── post-mainnet ──────── -->
	8. The EoI format and disclosure model is published in a specification.
	9. The CAIP-122 binding for Logos identities is published in a specification.
	10. Holder-defined identity recovery policies are published in a specification.
	11. The provenance log protocol is published in a specification.
	## Reliability
	## Performance
	1. A registry lookup of an identity's current state completes within a bounded time under typical network conditions.
	2. Identity creation completes within a few seconds on a typical client.
	## Supportability
	## Miscellaneous dependencies
	1. Dependency on a performant Logos Blockchain backend for the V1 registry.
	# Identity FURPS
	## Functionality
	1. An Account can be created without permission from any third party.
	1. An Account has a stable, long-lived address that does not change when keys rotate or are revoked.
	1. An Account has an append-only operation log of credential changes.
	1. Ed25519 SigningKeys can be added to an account which authorizes them to act on the Accounts behalf.
	1. Entries in the Account can be revoked by a 'soft-delete'.
	1. Given an Account address, applications can query for the associated SigningKeys.
	<!-- ──────── post-mainnet ──────── -->
	1. An Account allows for associating externally owned identifiers (EoIs) to be used as alternative addresses.
	1. An Account supports programmable validation policies, defined by the holder, that govern which mutations are accepted (i.
	## Usability
	1. Applications can access Account operation log, even if the account holder is offline.
	1. Anyone can query the Accounts operation log.
	## Reliability
	1. Account operation logs are durably stored forever
	## Performance
	1. A lookup of an identity's current state completes within a bounded time under typical network conditions.
	2. Identity creation completes within a few seconds on a typical client.
	## Supportability
	1. The identity library is implemented in Rust.
	1. The identity library is available via C-bindings.
	1. The identity library is integrated into a working Logos Chat module deployed to Logos Core.
	## +Security
	1. All changes to an account are signed by the account.
	<-- -─ post-mainnet ──────── -->
	1. Account creation is resistant to trivial Sybil attacks.
	## +Privacy
	1. [MainNet] An identity holder controls which EoIs are disclosed to which counterparty.
	1. [MainNet] AntiScrapping: There is no mapping from an Accounts operation log to AccountAddress
	## +Specs
	1. (address format, operation log, contact discovery flow) is published in a specification.
	2. The registry interface (lookup, write authorisation) is published in a specification.
	<-- -─ post-mainnet ──────── -->
	3. The EoI format and disclosure model is published in a specification.
	4. The CAIP-122 binding for Logos identities is published in a specification.
	5. Holder-defined identity recovery policies are published in a specification.
	6. The provenance log protocol is published in a specification.

[jm-clius]

Thanks! This is super helpful. I will focus most of my questions/comments here, as I think your suggestion incorporates most of your other comments as well:

1. My F1 ("An identity account is bound to at least one cryptographic key whose private part is controlled by the holder.") encapsulates only what is strictly necessary for the Testnet v0.2 deliverables, hence it being very generic and minimal. Since we define the deliverables from the FURPS, I'd suggest leaving it in in order to define the work for Testnet v0.2 (i.e. by then we must have done F1, which is all but implemented already).

2. Ed25519 SigningKeys can be added to an account which authorizes them to act on the Accounts behalf.

Presumably added by the holder of an existing active signing key for the account? And once added, that key can be used to change the account? Just checking my understanding here.

3. Entries in the Account can be revoked by a 'soft-delete'.

Same question as above - I think the feature should say something like: "Entries in the account can be revoked by the holder of an account key" or WDYT?

4. I think we should also state the requirement that de-MLS can retrieve the necessary key packages without necessarily embedding an architectural decision in to the requirements (e.g. without mentioning two registries, or subdomains within the registry - which could be subject to architectural changes without changing the requirement). WDYT?

5. Account operation logs are durably stored forever

Checking my understanding - this is the requirement that triggers the deliverables for implementing the registry in LEZ? Since we will have specific deliverables related to evaluating LEZ-as-backend or, now suggested by Ksr, implementing a new zone on Logos Blockchain, I'll bring these in as requirements as well.

[jazzz]

1. .... I'd suggest leaving it in in order to define the work for Testnet v0.2
   👍

2... Presumably added by the holder of an existing active signing key for the account?

This is where I am suggesting a change for ease; #444 (comment); No strong feelings.

3
Same as above.

4... WDYT?

The access pattern of keyPackages doesn't seem to align with a consensus based mechanism; But no blockers from me. A Blockchain would be sufficient and cover the required properties [ Async Availability ], however curious about Costs: On registration of a new installation/device there are ~500(+/- 1 order of magnitude) single use KeyPackages published.

[jazzz]

Re: 4. My default approach would be to build a Keybundle caching service nodes that runs on LogosDelivery for submission.

KeyPackage Registry:

F1 Stores keybundles for a maximum of 1 month.
F2 Only Stores valid keybundles; other payloads are dropped.
F3 Registries listen for keybundles published to /waku/2/demls-reg/proto
F4 Users can remove bundles by passing a signed drop request
F5 Users can fetch bundles from registry nodes.
F6 Registry nodes can be run permissionlessly.
F7 Some official Registry nodes are published via bootstrap.

[jm-clius]

@jazzz thanks for all your input! I've marked this now as ready for review after addressing your suggestions:

• changed "identity" to "account" throughout, where it made sense
• generalised description to "keys" rather than committing to specific type of signing key or installation keys
• removed de-mls key package lookups, as I agree with you that this is a separate problem (that probably needs its own set of FURPS in a separate track)
• added the FURPS you have in your proposal that was missing from mine

[igor-sirotin]

using the term "account holder" based the model that account holders held the signing key

This is actually how I was reading it, but it seems it wasn't the intention?

I think it's fine to defer the choice of security model from FURPS to spec and keep it generic:
An installation can be revoked.

But then I'd add a +Security section (as @jazzz shows in #444 (comment)):
1. Single-installation compromise must not permit irreversible account takeover.

[kaiserd]

LGTM 🙏 thank you

[kaiserd]

note: In the future (not launch critical) this should be a separate module(, or part of a more general module)