The authenticated request identity is the only user buildbucket knows about and it sets swarming's Authenticated field to that user. There is no other user. If swarming needs specifically User field to be equal to Authenticated in this case, I think swarming should default User field to Authenticated.

stepping back, buildbucket does not have a separate field for "actual user". Buildbucket clients are encouraged to use user impersonation, such that "Authenticated" and "User" are the same thing for buildbucket. The reason why CQ jobs are authenticated with CQ service account is because CQ does not use user impersonation.

So I am not sure what needs to be done on the buildbucket side for this bug.

Filed issue 878942 for automatic task tag for authenticated user.

The "user" field is meant to be "on behalf of" so it is a free form field. This is useful when a process (the CQ) triggers tasks on behalf of a non-committer. Otherwise there will be no way to know how much load a non-committer generates.

to be clear: the identity of the request is the only user buildbucket knows about, i.e. buildbucket does not have a concept of "on behalf of" because this use case is handled by the underlying user impersonation: buildbucket always sees "on behalf of" user as the requester identity and sets swarming's Authenticated to it. For example, in the past, when Rietveld server scheduled a build on buildbucket, it did so on behalf of the rietveld user, bulidbucket treated the request as coming from the end user and set Authenticated field to the end user. I'd prefer CQ to start using user impersonation aka delegation so that Authenticated is set to the end user, as opposed to introducing a new concept to buildbucket API.