Open nitesh7sid opened 4 years ago
Hmmm - what is to stop a "malicious" node from spamming lots of requests by name. This could potentially lead to situations where data is leaked.
The purpose of using the UUID was to make it impossible to guess names.
I'm not sure we should add this as a standard feature as it potentially leaks info about account holders. I think it's OK to look-up account holders by hash / UUID but by name is probably too much. Imagine a node being spammed with requests to figure out if some person/entity has an account there. I guess this depends actually how the account name property is used but we cannot assume it won't be a company or person name as the property is just a String
. Edit: Ah just seen @roastario got here first!
Hmm that makes sense.. Just thinking out loud here slightly on a diff context- a node can be even spammed and attacked with requests to provide new public key(s) for an account by invoking RequestKeyForAccountFlow
, right? Probably there wont be any leakage issue here but the host will keep generating new keys, register into vault and probably waste its resources? Correct me if I am wrong, thanks!
As a CorDapp developer I would like to use a built-in flow from the library that can help me to fetch account details from a particular host by name and not by UUID. If that particular host doesn't have an account created then it should return null.
Use-case: In some situations a node might have obtained
account name
(may be from front-end app or some offline channel) and wishes to fetch account Info details by passing that name to the host. If the account exists on that host then it should return the accountInfo else return null. e.g. a company creates account of its employee by using SSN/NIN or employee_id as account name and another company can request for accountInfo by passing account name for background-check.