ZenithVal Before entertaining the idea of allowing creators to upload for others, let's consider the options. I'll also explain why these requested session tokens may be unintuitive for users, and not in the best interest of users for their account security or convenience in the big picture. The pipeline you're hoping (and what I imagine) would be an ambitious, epic task requiring large bodies of work broken down into multiple tasks to implement correctly and somewhat securely (assuming a shared responsibility model). There are also other tangential unsolved problems.

There are currently (at the time of writing this) two existing ways to share avatars with other users, which are user-intuitive and secure: The avatar marketplace, and public avatars. Neither requires any setup for the user, doesn't require sharing login sessions or information with third parties. Additionally, any updates to the avatar will be done by their uploaders with no interaction required to be taken by the user. This is generally a win-win for the average user who may be disinterested or unable to become or learn how to become a VRChat Creator or Unity user at this time, or an average user willing to manage and secure account/session token permissions.

The avatar marketplace also has some binding rules for the uploader, meaning a purchased avatar cannot substantially change to a different avatar once sold. Public avatars are at the mercy of their uploader (and their account status), of course.

I could entertain the idea of transferring private avatars between users, but that could also compete with the avatar marketplace (and not be in the best interest of Creators for user support or the VRChat platform for longetivity). Transferring "ownership" of a third-party marketplace / customized avatar to another user commonly has prohibitive license restrictions on transfers; this tangential social / legal factor may also coerce non-creator users to have others upload to the user's account instead.

So let's return to entertaining the original proposal of allowing others to upload to your account, because some of you are going to inevitably do it anyway. How can you create an equally good user-friendly experience, which:

Managing least privilege permissions for tokens may be notoriously difficult and not very intuitive to manage or setup from an average user.

Ideally, such tokens would be short-lived, e.g. 1 hour long (but configurable to be valid for up to 24 hours). I believe the session token by itself can't be entirely single-use, because an avatar upload to all platforms (Windows, Android, iOS) is three uploads (three version increments), so a short-lived token seems to be required. Plus, the session needs to make a bunch of GET calls to the API before uploading. You could argue "well, let's invalidate the session token after the uploads!" to have a single-use token, but this doesn't take into consideration of potential security implications of what that token can already do (and needs to do with multiple API calls), or how should errors in the upload process be handled for session tokens.

For the sake of argument, let's say we now need a short-lived token. Ideally, the session assumed by the token has least privilege permissions for the task.

In theory, at this time anyone with the ability to create sessions may also be able to maliciously hit the user session limit with repeated session requests, which could lock the owner out of their account.

So how do you get an attacker out of your account, if they've gained malicious access to your token?

There's no way to currently for users to audit recent activity (sessions) or to invalidate them.

Changing a password also does not currently invalidate existing sessions?

At this time, using session tokens instead of usernames/passwords would not increase security much unless the tangential problems above are also solved.

I could also remind that session tokens inherently bypass multi-factor authentication, and open the plausibility of adversary-in-the-middle attacks (e.g. the session token is captured via phishing). There are ways to detect or mitigate AiTM, such as monitoring for multiple login sessions from the same token.

How about the scale of managing permissions and accommodating the needs of different users. You may have an user who wants a trusted friend to upload avatars and update them without interaction from the user, or without a short-lived token every hour; are you going to give them long-lived tokens that don't expire (not recommended), or setup a theoretical organization/group with delegated permissions (non-intuitive)? A VRChat Creator may not want to ask the user for a token every hour to update avatars for one or hundred users of that avatar.

If an user wants to approve the actions made by delegated third parties, that'd also be its own feature request.

Then, what if you have 100 avatars with 105 authorized uploaders, are you ready to manage permissions individually for all of them, or learn how to use Unity instead? (These are all ideas.)

I imagine avatar backups and restoration could be a paid option or a VRChat+ feature.

The existing VRChat Creator documentation caters to advanced users uploading avatars from scratch (Creating Your First Avatar), but not premade Unity packages.

P.S.: At least old revisions of worlds may exist.

> Who's going to manage the permissions for that token?

To restrict actions, VRChat could add VRChat managed policies, which are permission sets that allow only specific actions to be taken. E.g. VRCFullAccess, or VRCAvatarsFullAccess. These are not (and won't ever be) least privilege permissions due to being managed for the general public, without an intuitive UI to allow/deny resources and principals. If the goal is to restrict principal use to a single authenticated user (e.g. your uploader's VRChat account) and a single resource, such customization would require the user to also write custom rules. It then also becomes a shared responsibility of the user to follow best practices to manage least privilege permissions for tokens, which may be something an user may not be willing to learn to do (and give full permissions instead). I argue this approach is not very user intuitive; the focus shifts from learning Unity to learning IAM roles/permissions (but can now be done on the website, instead of on a Windows computer with Unity).