With the current documentation it is hard to grasp of the EmailAccountKey is implemented internally. The EmailAccountKey is highly dynamic (e.g., falling back to the userId key if the user id is configured to be an email, otherwise it's a regularly stored Account Key). This behavior is not really documented and only visible when looking into the implementation. Further, this behavior depends on the specific Account Service implementation.
Similarly, the PasswordKey is usually not meant to be specified by the user directly (rather it is implicitly specified for Account Services that require password input as a credential).
Solution
This behavior needs to be explicitly documented. Further, it might make sense to explain it with the example of our Firebase Account Service implementation (what most people would be working with initially).
For the password key, it might make sense to add a hint that you most likely won't need to specify that or make it only visible for the documentation that is gathered towards Account Service implementors.
Additional context
No response
Code of Conduct
[X] I agree to follow this project's Code of Conduct and Contributing Guidelines
Problem
With the current documentation it is hard to grasp of the
EmailAccountKeyis implemented internally. TheEmailAccountKeyis highly dynamic (e.g., falling back to the userId key if the user id is configured to be an email, otherwise it's a regularly stored Account Key). This behavior is not really documented and only visible when looking into the implementation. Further, this behavior depends on the specific Account Service implementation.Similarly, the
PasswordKeyis usually not meant to be specified by the user directly (rather it is implicitly specified for Account Services that require password input as a credential).Solution
This behavior needs to be explicitly documented. Further, it might make sense to explain it with the example of our Firebase Account Service implementation (what most people would be working with initially).
For the password key, it might make sense to add a hint that you most likely won't need to specify that or make it only visible for the documentation that is gathered towards Account Service implementors.
Additional context
No response
Code of Conduct