Hi,

(follow-up of #42650)

I believe our main goal for the new "security system" was to have always authenticated tokens, isnt it? As such i feel like make TokenInterface::getUser() nullable swaps a technical issue for a (severe) semantical one, defeating our initial goal. I want to verify it's 100% intentional.

I'd be able to bypass the passport user, and provide an unauthenticated token isnt it? Meaning i'm effectively re-introducing a AnonymousToken. But anonymous means token=null 🤔

So, IIUC, we're now back to $loggedIn = $token && $token->getUser(), rather than our initial intention $loggedIn = !!$token :) It looks like we're back at sqaure 1.

Confirmed here:

I dont think the check itself should require a service layer. Meaning we probably need better semantics for AuthenticationTrustResolver::isAuthenticated as well, or remove it. (btw calling it without args to me implies "the current token")

Now, to get back to "tokens are always authenticated" AND fix our technical issue in the voter subsystem i'd like to propose these alternative maybe-possible solutions;

1. explore eg. AnonymousUser / NullUser
2. introduce some signaling exception from getUser
3. leverage some role name
4. vote(?TokenInterface $token) one way, or another :}

More side-related questions:

• how do we explain TokenInterface::getRoleNames vs UserInterface::getRoles, in both the current and previous architecture? What if i have a token with roles but no user currently?
• is CredentialsInterface a pre-mature abstraction? Do we have another sementical issue given i could do the same using SelfValidatingPassport + badges?
• Do we really need AuthenticationTrustResolverInterface? rather than some static api.

Thanks :)

cc @chalasr, @nicolas-grekas , @wouterj also