initial todo on more flexible credentials management mechanism

doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism.mdwn

@@ -0,0 +1,13 @@
+ATM git-annex heavily relies on credentials needed by special remote(s) (S3, WEBDAV) to be passed via environment variables. 
+
+- main shortcoming: those environment variables (e.g. AWS_ACCESS_KEY_ID) do not allow for different set of credentials to be provided to be used e.g. by multiple special remotes of the same `type` and would require multiple git-annex invocations to get through all of them
+- user experience:
+  - there is no UI to prompt user to enter needed/desired secrets.  That also relates to software relying on git-annex, such as datalad, as it somehow needs to know/discover that underlying call to `git-annex` apparently needs some credentials to be passed via env vars
+  - users then (typically)  need to hardcode values of those secrets verbatim in their scripts (instead of using some more secure credentials store)
+
+Given those (and possibly other) shortcomings, I thought it would have been great if git-annex supported some "credentials" storage/prompting/querying mechanism which would address main shortcoming and improve user experience. May be git-annex could use [git-credential](https://git-scm.com/docs/git-credential) mechanism. If not, then may be have some protocol created to allow for external git-annex-credential-* helpers?
+
+For reference, here is a PR in DataLad [https://github.com/datalad/datalad/pull/5796](https://github.com/datalad/datalad/pull/5796) to provide `git-credential-datalad` helper so `git` could query our (datalad) credentials store.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]