Keychain - Standardization (AEIP 6)

[samuelmanzanera]

This is discussion for the AEIP6 located at: https://github.com/archethic-foundation/aeip/blob/main/AEIP-6.md

[samuelmanzanera]

First, thanks @redDwarf03, for the proposal and the interesting ideas.

About personalization

what would be the use case to have public information, while the protected approach will ensure a better privacy in terms of choices ?

To be more compliant with the W3C DID specification, we should also implement a resolver (an API) to get the DID's document of a given Keychain's address, as the content would not be explanatory enough after this change.

About the scope of the personalization, we should take inspiration of the W3C DID, which define the set of verifications or information related to several DIDs, by using an id. For example: "id": "did:archethic:keychainAddress#serviceId". This would simplify the notion of scope (whole keychain or service focused) and use the same semantic.

About archiving

For smart contract, they would have been on another chain, maybe located in one of the keychain's service.
Hence, we could just determine point to the DID: did:archethic:keychainAddress#smartContractChainID.
By adding a smart contract archive, this will not remove from the keychain, but only on the display of the keychain (as being part of the services).

About blacklisting

If we want to let the validations prevent sending of transactions while being mentioned in the blacklist, the protected list would need to be encrypted with the shared key of the nodes. In that, the case, the validation nodes would be able to decrypt it and prevent the token transfers for instance.
Without this encryption, the blacklist would need to be public.

About the contacts

There is a patent which describes the behavior to attach a digital ID to a directory or to external identifiers such as phone numbers, mails, etc. Furthermore, it describes a way to create contract with a dedicated transaction linking digital IDs and create the contacts with shared encrypted knowledge.
We might explore this lead to provide an on-chain version of contact's management while being compliant with the patents.