Today resto generate its own internal user IDs (big integers).
Users have to "remember" these ID when using the API, which is not the best experience.
The ID could be a username choosen by the users at account creation (like in most social network platform for example).
It makes even more sense when using resto with an external Identity Provider (IdP), where users already have username/IDs provided by the Identity and Access Management system.
In that case, the users have to "remember" central IAM ID/username in additional to resto internal user ID.
This issue is specifically for these use case: allow, when using an IdP, to indicated what user field resto must use as unique IDs for the users. Hence, in this case, resto is not managing internal IDs anymore.
Today resto generate its own internal user IDs (big integers). Users have to "remember" these ID when using the API, which is not the best experience. The ID could be a username choosen by the users at account creation (like in most social network platform for example).
It makes even more sense when using resto with an external Identity Provider (IdP), where users already have username/IDs provided by the Identity and Access Management system. In that case, the users have to "remember" central IAM ID/username in additional to resto internal user ID. This issue is specifically for these use case: allow, when using an IdP, to indicated what user field resto must use as unique IDs for the users. Hence, in this case, resto is not managing internal IDs anymore.