Per the conversation in the sprint, I believe this is not a task for the /v2/users or /v2/create-user endpoints. The first one is so far mainly oriented towards management of users, while the latter is an endpoint for creating system users, which we don’t want to do in this case. Also, neither of those return a macaroon to the caller, and we probably don’t want to change that.
I think the proper place for this is the /v2/login endpoint, which is the only that returns a macaroon today, I think? The semantics also feel right: if you are obtaining a macaroon for someone, you haven’t just created that user. You are that user and may perform arbitrary actions as that user.
We’ll need a hint that /v2/login shouldn’t go to the store. Perhaps a detached: true parameter? Although we’ve been using the local terminology so far, it feels wrong because in all cases there is actually a local user component being created. It’s the remote component that is associated with it or not in certain cases.
Finally, we need to define what data we require for that kind of user. At the very least, I think we want a username associated with it for now. We may find use cases that require us to ignore the parameter in the future, but feels good to start with it assuming we have the information available.