search

corda / accounts

Accounts on Corda
Other
36 stars 38 forks source link

How to extend AccountInfo ContractState #77

Open cmaliwal opened 5 years ago

cmaliwal commented 5 years ago

I have a use case where each account would have some extra details like First Name, Last Name, Email etc. I noticed that your library creates AccountInfo State which is accessible by all accounts on the same node. So, can we extend AccountInfo such it can store custom fields along with name, host and identifier? Also, is it wise to create another State to store user information and share it with all the other accounts on the same node?

roger-that-dev commented 5 years ago

AccountInfo is not currently extendable but perhaps it could be in the future. Reason being is that it's usually not a good idea to put personal information about account holders on the ledger. There are a number of options you have:

  1. Store the user information off-ledger in a series of Hibernate entities. You can join this data to the associated account using the account ID (externalId)
  2. Create a series of state objects for holding this data (name, email, etc.) and link them to the account info by including the AccountInfo as a reference state in the transactions which create the data states.
manjeet-thadani commented 4 years ago

How Accounts authenticate a request i.e. how to ensure that the user that is invoking the Flow is a correct person? In the current implementation, this library just requires UUID of account to perform the transaction. So, if any other account has my accountId then he can perform operations on my behalf?. Also, I noticed that AccountInfo (name, host, accountId) is/should be public at the network level (to know all available accounts across nodes).

So, How this implementation ensures that the invoker of the Flow is an authenticated account?

manosbatsis commented 3 years ago

@roger3cev this is what we're after as well in a project currently, but the CreateAccount flow doesn't allow setting an (optional) externalId. Also the field is not available for queries in PersistentAccountInfo. Does it make sense for me to make a (backwards compatible) PR for this?

mevir commented 3 years ago

@manosbatsis I use the name property of the AccountInfo state each time I need an external identifier for the account (actually I couldn't find any other utility for this property :D ) - maybe it fits your use case also ...

manosbatsis commented 3 years ago

@mevir that won't work for me - need the name for a human-readable handle, which is why i'm after a more accessible externalId as a business key.

mevir commented 3 years ago

@manosbatsis well, the name must be unique at the node level. If you want to use something like firstName lastName as a human-readable handle the probability of collisions is high. Also take care of personal data - if the owner of the account is a EU citizen he has the right to be forgotten under GDPR - I don't know how this can be handled as long as the AccountInfo state can be shared freely with other nodes - is there is a tracking for this?

manosbatsis commented 3 years ago

@mevir our use-cases are more about agents like services or legal entities VS persons, where having both an external business key as externalId along with a (unique) human readable name is very convenient. PR https://github.com/corda/accounts/pull/105 allows the typical LinearState.linearId.externalId approach with AccountInfo.

Indeed user accounts need more careful consideration; i believe even usernames are borderline GDPR-wise.