Ok, I probably misunderstood you when you said:
This is why we believe we need an authenticator which can manage the credentials, and apps only connect to the network after credentials were provided by this authenticator, thus apps never get the account’s credentials but just their own and the fixed set of permissions.
But the best solution is to provide both possibilities: a direct access API and another one via the authenticator.
Right, what I was trying to say is that having an authenticator is probably the safest approach for users, since all auth goes thru it and account secret/password is not exposed to apps when they embed an authenticator in it. E.g. if I see in a forum someone saying that he created a SAFE app, I download it and when I run it it asks for my SAFE secret/pwd, I’ll doubt a lot and I’d personally prefer to only give a set of clear and specific permissions to that app thru my trusted Authenticator app (regardless if it’s an authenticator app with GUI or CLI UI). Now, this cannot be a reason to not expose an API from the auhthenticator library in SCL.
Bumped this to mention that Algorand had submitted a paper to this journal in February of 2018 and is open access and available since February 2019, it looks like PARSEC in March 2019 so still a bit of a wait it looks like. Any requests for revision from the maidsafe team as of yet?
Assuming a similar time scale that might mean April of 2020 for PARSEC to be published. Fully asynchronous with the common coin and DKG stuff